cathya at isc.org
Fri Jun 6 10:50:18 UTC 2014
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
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.
More information about the bind-users