pros/cons of stub zones vs delegations.

[Kevin Darcy]

Jason Price wrote:

> I'm trying to understand where one should use stub zones, and where one
> should use delegations.  The DNS_AND_BIND book has very little info on
> stub zones, and google searches show several uses, but not a 'in this
> situation, use stub, otherwise, delegate'.
>
> I have a set of bind servers that run internal, and are root for my
> 10.*.  I have a dmz set of bind servers that live in 10.30.*.* (NAT),
> and stub 10.* back to the internal set.  I also have a set of win2k DNS
> that will be delegated (should be stub'ed?) a subdomain, and delegated
> (stub'ed?) a bunch of subdomains of 10.*

You *should* delegate every zone that you *can* delegate. Every zone that
you delegate is one *less* zone that you have to explicitly define in
every one of your nameservers, which lessens your maintenance burden.

(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.)

10.in-addr.arpa is a special case, of course, if you're rooted in the
Internet DNS, since you don't control the parent zone (in-addr.arpa) and
thus cannot delegate it. For this domain, then, you have to fall back to
"hardwired" mechanisms like "type stub", "type forward" or "type slave" in
order for your nameservers to resolve names in the domain. Every
nameserver you have needs to define 10.in-addr.arpa (or some descendant
domain(s)/zone(s) thereof) as one of those 3 "hardwired" zone types. Each
of the zone types has pros and cons, but generally I'd lean towards
"stub", which is quite lightweight, unless I really needed the redundancy
of "slave".


- Kevin