How do Stub Zones work

[Kevin Darcy]

Kelly Scroggins wrote:

> Please tell me if understand this correctly?
>
> If I have a stub zone to another company, and a client on my network
> queries for a host on the stub zone, MY name server will the contact the
> authoritative name server for that zone and resolve the name FOR the
> client.
>
> In other words, the client on my network does not contact the name
> server on the 'other zone', but instead, my name server does the work
> FOR the client.

That has nothing to do with whether the zone is "stub" or not. That has to
do with the "allow-recursion" settings on the nameserver (the default is to
allow recursion for all clients and zones). With recursion enabled, your
nameserver will go and ask other nameservers about names in the zone,
regardless of whether the zone is defined as type "stub" or "forward", or
even if it isn't defined in your named.conf at all. If forwarding is used,
though, it'll only ask certain *specific* nameservers about the zone;
"stub" allows you a little more flexibility to ensure that it always asks
the *appropriate* nameservers about the zone.

A stub zone is just a way for the nameserver to replicate the nameserver
information about a zone. It's like being a slave, except you don't
replicate the *entire* zone, just the nameserver information, so you aren't
considered "authoritative" and you don't need "allow-transfer" authority.

Stub zones are useful in mainly 4 different ways:
1) as a more lightweight-but-less-redundant alternative to being a slave
2) to get around "allow-transfer" restrictions
3) because the zone being "stub"bed isn't actually delegated from its
parent -- here, you're basically using "stub" to "hardwire" the NS'es into
your nameserver
4) when you need _some_ sort of zone definition in your named.conf file in
order to turn off forwarding for a particular part of the namespace (via
"forwarders { }"). This use is especially common in "split
DNS" configurations.

These uses are not mutually-exclusive, of course...

- Kevin