> 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
zones.

>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



_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to