Delegations

[WBr...@e1b.org]

I have a zone file for example.org that has entries for a subdomain
l2.example.org like this:

vpn.l2 IN A 10.1.2.3

Now they want to add a subdomain below l2, ie. ad.l2.eboces.org with hosts
such as dc.ad.l2.eboces.org

In the zone file for example.org, I can add NS and glue records for
ad.l2.example.org as this:
dc.ad.l2 IN A 10.2.3.4
dr.ad.l2 IN A 10.4.5.6
ad.l2 IN NS dc.ad.l2.example.org.
ad.l2 IN NS dr.ad.l2.eboces.org.

Will this work, or do I need to delegate l2.example.org before I can
delegate ad.l2.example.org?


--

William Brown
Core Hosted Application Technical Team and Messaging Team
Technology Services, WNYRIC, Erie 1 BOCES





Confidentiality Notice:
This electronic message and any attachments may contain confidential or
privileged information, and is intended only for the individual or entity
identified above as the addressee. If you are not the addressee (or the
employee or agent responsible to deliver it to the addressee), or if this
message has been addressed to you in error, you are hereby notified that
you may not copy, forward, disclose or use any part of this message or any
attachments. Please notify the sender immediately by return e-mail or
telephone and delete this message from your system.

[Phil Mayers]

On 31/10/12 17:12, WBr...@e1b.org wrote:
> I have a zone file for example.org that has entries for a subdomain
> l2.example.org like this:
>
> vpn.l2 IN A 10.1.2.3
>
> Now they want to add a subdomain below l2, ie. ad.l2.eboces.org with hosts
> such as dc.ad.l2.eboces.org

You terminology is a bit confusing here. "subdomain" is imprecise.
Specify what *zones* you want, and where you want the delegations, and
it should be easy to see what will work and not.

example.org SOA
www.example.org A <- hostname, in example.org zone
vpn.l2.example.org A <- hostname, still in example.org zone

ad.l2.example.org NS <- delegation point in example.org zone
xx.ad.l2example.org A <- glue, *still* in example.org zone

...and of course then the SOA & zone contents for "ad.l2.example.org"

>
> In the zone file for example.org, I can add NS and glue records for
> ad.l2.example.org as this:
> dc.ad.l2 IN A 10.2.3.4
> dr.ad.l2 IN A 10.4.5.6
> ad.l2 IN NS dc.ad.l2.example.org.
> ad.l2 IN NS dr.ad.l2.eboces.org.
>
> Will this work,

Yes, if I've understood what you want.

> or do I need to delegate l2.example.org before I can delegate ad.l2.example.org?

No. Zone cuts can be at any label inside a zone.

[Tony Finch]

Phil Mayers <p.ma...@imperial.ac.uk> wrote:
>
> No. Zone cuts can be at any label inside a zone.

Provided "inside" does not include the zone apex :-)

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

[WBr...@e1b.org]

Phil wrote on 10/31/2012 02:15:16 PM:

> You terminology is a bit confusing here. "subdomain" is imprecise.

Sorry, I meant it as a piece of the FQDN.

> Specify what *zones* you want, and where you want the delegations, and
> it should be easy to see what will work and not.

> Yes, if I've understood what you want.

I think you got it.

> > or do I need to delegate l2.example.org before I can delegate
> ad.l2.example.org?
>

> No. Zone cuts can be at any label inside a zone.

Thanks. Waiting for firewall changes tonight to test.

[Doug Barton]

On 10/31/2012 10:12 AM, WBr...@e1b.org wrote:
> I have a zone file for example.org that has entries for a subdomain
> l2.example.org like this:
>
> vpn.l2 IN A 10.1.2.3
>
> Now they want to add a subdomain below l2, ie. ad.l2.eboces.org with hosts
> such as dc.ad.l2.eboces.org

As someone else pointed out, you're confusing different terms here. If
all you want is to add new host names that have "l2.eboces.org" in them,
you can do that without creating a zone cut.

OTOH, if what you want to do is create a new zone at ad.l2.eboces.org
because you want to delegate it to _different_ name servers than those
authoritative for eboces.org, then yes; your safest bet is to do proper
zone cuts at each level. It's perfectly Ok to have the name servers for
l2.eboces.org be the same as those for eboces.org, just make sure you
move any related records (such as your vpn.l2 above) into the new zone
file.

It may or may not be strictly necessary to do this depending on
everything else you have in the zone, but it's safer in the long term to
do it this way.

hope this helps,

Doug

> In the zone file for example.org, I can add NS and glue records for
> ad.l2.example.org as this:
> dc.ad.l2 IN A 10.2.3.4
> dr.ad.l2 IN A 10.4.5.6
> ad.l2 IN NS dc.ad.l2.example.org.
> ad.l2 IN NS dr.ad.l2.eboces.org.
>

> Will this work, or do I need to delegate l2.example.org before I can
> delegate ad.l2.example.org?
>
>

[Phil Mayers]

On 10/31/2012 06:51 PM, Doug Barton wrote:

> It may or may not be strictly necessary to do this depending on
> everything else you have in the zone, but it's safer in the long term to
> do it this way.

Are you suggesting it's best of the OP creates "l2.example.com" as a
sub-zone?

Why it this necessary / safer?

[Kevin Darcy]

I know of at least 2 commerically-available DNS maintenance systems
that, by default, do not allow what they call "dotted hostnames", by
which they mean a name which is at least 2 labels below a zone cut, e.g.
"foo.bar" in the "example.com" zone. Their underlying assumption seems
to be that *every* level of the hierarchy will, in the
usual/typical/default case, be delegated.

I don't agree with this assumption in the slightest, but some people are
afraid of changing default behaviors...

- Kevin

[Chris Thompson]

On Oct 31 2012, Phil Mayers wrote:

>On 10/31/2012 06:51 PM, Doug Barton wrote:
>
>> It may or may not be strictly necessary to do this depending on
>> everything else you have in the zone, but it's safer in the long term to
>> do it this way.
>
>Are you suggesting it's best of the OP creates "l2.example.com" as a
>sub-zone?
>
>Why it this necessary / safer?

It certainly isn't necessary. We have plenty of zone cuts more than one
label deep into the parent zone. And of course such delegations are
*extremely* common in the reverse lookup trees, with the IPv6 one
probably providing records for the number of labels between cuts.

I don't see how "safer" would apply, either.

--
Chris Thompson
Email: ce...@cam.ac.uk

[Chris Thompson]

On Oct 31 2012, Kevin Darcy wrote:

[...snip...]

>I know of at least 2 commerically-available DNS maintenance systems
>that, by default, do not allow what they call "dotted hostnames", by
>which they mean a name which is at least 2 labels below a zone cut, e.g.
>"foo.bar" in the "example.com" zone. Their underlying assumption seems
>to be that *every* level of the hierarchy will, in the
>usual/typical/default case, be delegated.
>
>I don't agree with this assumption in the slightest, but some people are
>afraid of changing default behaviors...

What "default behavior"? The default behavior of (seriously) defective
DNS maintenance systems? (You wouldn't like to name-and-shame, I suppose?)

The end-point of that sort of logic is that, for example, the SRV record
for _someservice._tcp.somename.example.com has to have separate zones
for somename.example.com and _tcp.somename.example.com, probably
containing nothing but the names mentioned. I've seen people actually
do this, and it's painful to watch.

We were never in that mess as regards the DNS itself, but we did have
an IP registration database that delegated control over names on the basis
of a "domain part" taken to be all but the first label. It was hard work
to change it to allow the "domain part" for authorisation purposes to be
any trailing set of labels, but by ${DEITY?} it was necessary!

[Doug Barton]

On 10/31/2012 03:22 PM, Chris Thompson wrote:
> On Oct 31 2012, Kevin Darcy wrote:
>
> [...snip...]
>> I know of at least 2 commerically-available DNS maintenance systems
>> that, by default, do not allow what they call "dotted hostnames", by
>> which they mean a name which is at least 2 labels below a zone cut, e.g.
>> "foo.bar" in the "example.com" zone. Their underlying assumption seems
>> to be that *every* level of the hierarchy will, in the
>> usual/typical/default case, be delegated.
>>
>> I don't agree with this assumption in the slightest, but some people are
>> afraid of changing default behaviors...
>
> What "default behavior"? The default behavior of (seriously) defective
> DNS maintenance systems? (You wouldn't like to name-and-shame, I suppose?)
>
> The end-point of that sort of logic is that, for example, the SRV record
> for _someservice._tcp.somename.example.com has to have separate zones
> for somename.example.com and _tcp.somename.example.com, probably
> containing nothing but the names mentioned. I've seen people actually
> do this, and it's painful to watch.

Chris, I specifically asked the OP if they wanted a zone cut at the
higher level, or if they were just looking for multi-dot names. So this
particular argumentum ad absurdum is particularly inappropriate.

We used to say that you didn't need to do a delegation if the subzone
was going to be hosted on the same auth. name server either, and then
along came DNSSEC and lots of people with systems that weren't breaking
any rules are suddenly dealing with strange error messages.

So sure, the OP could probably "get away with it" even without doing a
zone cut at the middle level. But I stand by my assertion that for
maximum future-proofing they're safer with it than without. Doing the
zone cut costs them almost nothing now, and may save time/effort/energy
down the road.

Doug

[Mark Andrews]

Adding a child zone without adding the delegating NS records was
always a bad idea. Such "instruction" also usually contained the
caveat "this is technically wrong and will cause issues if you ever
have machines that do not host both zones but you can get away with
it."

Nameserver also used to merge zone contents so that AXFR included
the NS records from the child zone.

> So sure, the OP could probably "get away with it" even without doing a
> zone cut at the middle level. But I stand by my assertion that for
> maximum future-proofing they're safer with it than without. Doing the
> zone cut costs them almost nothing now, and may save time/effort/energy
> down the road.

You are equating a practice that was techically wrong, and known
to be wrong from the get go, with one that has never been techically
wrong.

> Doug
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

[Doug Barton]

On 10/31/2012 03:56 PM, Mark Andrews wrote:
> You are equating a practice that was techically wrong, and known
> to be wrong from the get go, with one that has never been techically
> wrong.

Yes, I'm making exactly the same judgment that typical users make. "It
works, so it must be Ok."

The fact that we ("experts") can get away with something, whether it's
technically right/wrong/indifferent not withstanding, doesn't mean that
it's good advice for the average user.

Doug

[Mark Andrews]

Putting in delegations where they are not needed introduces additional
work and more places that can go wrong.

Mark

[Sam Wilson]

In article <mailman.564.1351726...@lists.isc.org>,

Mark Andrews <ma...@isc.org> wrote:

> In message <5091ADEF...@dougbarton.us>, Doug Barton writes:
> > On 10/31/2012 03:56 PM, Mark Andrews wrote:
> > > You are equating a practice that was techically wrong, and known
> > > to be wrong from the get go, with one that has never been techically
> > > wrong.
> >
> > Yes, I'm making exactly the same judgment that typical users make. "It
> > works, so it must be Ok."
> >
> > The fact that we ("experts") can get away with something, whether it's
> > technically right/wrong/indifferent not withstanding, doesn't mean that
> > it's good advice for the average user.
> >
> > Doug
>
> Putting in delegations where they are not needed introduces additional
> work and more places that can go wrong.

And also (he said very quietly indeed after delurking) increases the
granularity of management. Being able to reload or work on a small
(sub)zone rather than a large one can have advantages, which of course
have to be balanced with the extra effort involved in setting such a
system up. YPYMAYTYP.

Sam

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

[Jan-Piet Mens]

> YPYMAYTYP

Zero results from my favorite search engine -- congratulations. ;-)

-JP

[Sam Wilson]

In article <mailman.571.1351768...@lists.isc.org>,

Jan-Piet Mens <jpmen...@gmail.com> wrote:

> > YPYMAYTYP
>
> Zero results from my favorite search engine -- congratulations. ;-)

Thank you. Try YPYMAYTYC but I was thinking pick.

[WBr...@e1b.org]

Jan-Piet Mens <jpmen...@gmail.com> wrote on 11/01/2012 07:09:14 AM:

> > YPYMAYTYP
>
> Zero results from my favorite search engine -- congratulations. ;-)

Yeah, and bing didn't find it either! :)

[Chris Buxton]

On Oct 31, 2012, at 4:02 PM, Doug Barton wrote:
> On 10/31/2012 03:56 PM, Mark Andrews wrote:
>> You are equating a practice that was techically wrong, and known
>> to be wrong from the get go, with one that has never been techically
>> wrong.
>
> Yes, I'm making exactly the same judgment that typical users make. "It
> works, so it must be Ok."
>
> The fact that we ("experts") can get away with something, whether it's
> technically right/wrong/indifferent not withstanding, doesn't mean that
> it's good advice for the average user.

I must disagree with my learned colleague here.

Introducing the extra subzone for the current subdomain also introduces extra work if DNSSEC is later introduced. It can also cause as many problems as it solves even in the absence of DNSSEC.

As for the possibility of administrator error in the future, and making things futureproof, I would assert that stumbling when bad assumptions cause problems is the quickest way to learn the proper rules of DNS. Designing a system to match the possible wrong-headed assumptions of future admins results in a system akin to Microsoft's DNS snap-in for MMC, whereby users then develop mistakes in their thinking about how DNS works and therefore are unable to properly troubleshoot and fix real problems when they occur.

I would prefer to promote a correct understanding of the actual rules of DNS.

Chris Buxton
BlueCat Networks

[Chris Buxton]

On Oct 31, 2012, at 2:31 PM, Kevin Darcy wrote:
> I know of at least 2 commerically-available DNS maintenance systems that, by default, do not allow what they call "dotted hostnames", by which they mean a name which is at least 2 labels below a zone cut, e.g. "foo.bar" in the "example.com" zone. Their underlying assumption seems to be that *every* level of the hierarchy will, in the usual/typical/default case, be delegated.

As an employee of a company that makes a DNS management product, I can say that there is a strong temptation to think this way when designing such a product. We have mostly managed to avoid this type of stupidity, but I still get tripped up by it occasionally. When I find it, it gets logged as a bug report, of course, because we have plenty of customers who rely on "dotted records".

Chris Buxton
BlueCat Networks