> 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
