BIND View Option
list at jth.net
Thu Nov 11 18:22:35 UTC 2010
> From a nameserver implementation and maintenance perspective, it's even
>simpler for the data to already be present in the first view that
>matches. Why complicate things more than that?
Because there is a need for it especially in large installations with a large number of
>Different people have
>different definitions of what "not found" means, so you're never going
>to get a solid consensus on when searches should stop, and when they
>should keep on going to the next view.
At the zone level, which is what we need, there cannot be any doubt.
Once a zonefile of the zone is found, the searching stops.
>If by "not found" you mean "anything and/or everything that a stub
>resolver would pass back to its invoker without an answer", then that
>includes not only NXDOMAIN, but also NODATA, referrals, CNAME-only
>responses, etc. Should *all* of those results cause this searching
>algorithm to continue to the next view?
At the record level there might be different opinions, but basically my opinion is,
that a response should be returned as soon as it can be based on data/rules positively
found. Absent data would then only be covered by a NXDOMAIN rule when the search is
exhausted without anything found.
I do not see any big can of worms here.
- Jørgen Thomsen
More information about the bind-users