pros/cons of stub zones vs delegations.

[Kevin Darcy]

Jason Price wrote:

> First off, thanks for your time and expertise you put into this
> list/group.
>
> Kevin Darcy <kcd at daimlerchrysler.com> writes:
> > (Note that there is a difference between (sub)zones and (sub)domains. I
> > wouldn't necessarily recommend delegating every *subdomain*. That would
> > probably be wasteful.)
>
> Ok... I thought they were 2 words for the same thing...  In reading
> further I'm still slightly confused.  It seems that 'zone' is defined as
> 'what I (the nameserver) have explicit knowledge of'.  Subsets of what I
> have authority for, where I just point to other nameservers are not in
> my zone.

Anything delegated underneath a given zone is a separate zone (or
"subzone"), whether you happen to host it or not. Like the DNS namespace
itself, delegation is a *hierarchical* concept. Anything that is delegated
*out* of a zone is no longer *in* that zone. The subzone is an entity unto
itself, and may delegate below itself, and so on and so forth. You
*could* delegate every subdomain in your namespace if you wanted to, but it
may not be necessary to do that. You could even delegate every *name* in
your namespace -- 39.3.3.10.in-addr.arpa, mentioned below, could be a zone
with a single PTR as its only "leaf" record. But delegating every name in
one's namespace would be overkill in the vast majority of situations. I only
mention it as a way of highlighting the difference between subdomains and
subzones.

> If that's the case, does 'subzone' have any real meaning?  Or in my 10.*
> case, are 'subdomains' (say 10.22.25.*) that I delegate to myself
> 'subzones'?

Any subdomain that you delegate, and which has its own NS records and an
SOA record (at a minimum) is a subzone.

> And to be clear (in my mind), by delegation I mean in the 10.* top level
> zone file, I would have the following lines:
>
> -----
> 3.3.10.in-addr.arpa.      IN NS    some.name.server.
> 39.3.3.10.in-addr.arpa.   IN PTR   some.name.server.
> -----
>
> in order to delegate 10.3.3.* to some.name.server.

The first line delegates 3.3.10.in-addr.arpa to "some.name.server". Assuming
that 3.3.10.in-addr.arpa is configured properly on some.name.server, then it
is a zone, separate and apart from the 10.in-addr.arpa zone. In relative
terms, we would call it a "subzone" of 10.in-addr.arpa, but that only
describes the relationship between two distinct databases.

The second line is in error. Since you've now delegated 3.3.10.in-addr.arpa,
any names _underneath_ 3.3.10.in-addr.arpa, now belong in the child zone,
not in the parent. Again, there is an underlying hierarchy here that needs
to be observed and respected.

> And by 'stub' or 'slave' or 'forward', we mean new entries in the
> named.conf file:
>
> -----
> zone "3.3.10.in-addr.arpa" {
>         type stub;
>         masters { 10.3.3.39; };
> };
> -----
>
> And these would accomplish the same things?

Assuming that 10.3.3.39 is the address of "some.name.server", you mean?
Sure, in very rough terms this accomplishes "the same things", i.e. enables
this particular nameserver to resolve names in that zone. But delegating the
zone achieves *globally* what you have hardwired only locally here. From a
maintenance perspective, it's usually best to make a configuration change in
*one* place, instead of in every server config. Gerry-rigging your namespace
together with stub zones is not a very scalable approach to DNS maintenance.
Delegation should be the default way to connect zones, with
"hardwired" methods being reserved for the exceptions like 10.in-addr.arpa
or other miscellaneous exceptions (e.g. you want redundancy (type slave), or
you don't have direct connectivity to the nameservers for the zone (type
forward)).

> But the delegation approach
> would be better (more lightweight, and less maintance)?

Like I said, delegate wherever you can delegate, so that you don't have to
"hardwire" the zones into your configs. 10.in-addr.arpa is probably not
something you can delegate (unless you have a private root), so you're stuck
with "hardwiring" that, but once you've bitten that bullet, you can delegate
anything and everything you want, underneath it...


- Kevin