stub zones

[Cathy Almond]

On 02/06/2014 23:38, John Miller wrote:
> So... without stub zones, you know the drill: your local resolver
> follows delegation, starting from the root nameservers.  Delegation
> happens, and life is good.  If you're running views, then things work
> fine as well: your view just needs to be configured to allow queries
> from your local resolvers.
> 
> Let's say you're testing out a new set of authoritative DNS servers for
> your domain.  These are authoritative-only nameservers (not necessarily
> BIND, either: plenty of other software and cloud services out there). 
> You want your local resolvers to not follow the usual delegation
> process: you want them to begin delegation with your authoritative NSs.
> 
> From my experience, the biggest difference between stub zones and
> forward zones is that with stub zones, the RD bit is unset--it's up to
> the local resolver to follow delegation, starting with the nameservers
> configured in the stub zone, rather than starting with the root NS.
> 
> With forwarders, the RD bit is unchanged--you can easily end up sending
> recursive queries to a server that isn't set up to handle them.  You
> might also end up not getting a full answer to your query: the forwarder
> destination isn't doing recursion, so your answer will only be one level
> deep.
> 
> John

And not forgetting that with recent versions of BIND, you have 'stub'
and you have 'static-stub'.

The difference is that with static-stub, if the NS/A/AAAA records
returned by the authoritative server you've pointed your resolver at
don't match the addresses you want your server to query (e.g. for a
hidden master or an internal-only address that you access it by), they
don't get overwritten.

Cathy