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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
