Configuring stub zones

[Kevin Darcy]

Barry Margolin wrote:

> In article <9n5pst$k6p at pub3.rc.vix.com>,
>  <matthew.harding at hrdc-drhc.gc.ca> wrote:
> >Yes, this works fine and is a much more elegant scenario. I don't know why I
> >was thinking stub zones.
> >
> >When would type stub zones be appropriate?
>
> Stub zones are appropriate when it's likely that the nameservers for the
> subdomain will change and you don't want to have to update the delegation
> records manually every time.
>
> But IMHO, they're not really a good solution.  You need to configure all
> the authoritative servers for the parent zone as stubs for the subzone.
> This is because the parent's serial number won't change when the
> subdomain's NS records change, so slave servers won't automatically pull
> over the new parent zone with the updated delegation records.

Stub zones are often the most efficient way to "override" the normal delegation
chain, but when one doesn't want to incur the zone-transfer overhead of slaving
the zone or the non-robustness/non-scalability of defining the zone as "type
forward".

Also, if forwarding is in effect and you want to disable it for part of the
namespace, stub zones are the most lightweight way to do this -- define the apex
zone of the namespace as a stub zone with "forwarders { }".


- Kevin