On 11/11/2010 7:55 AM, J. Thomsen wrote:
If your main concern is resource consumption, maybe you should focus on
developing some clever algorithm by which named could keep track of
multiple references to the same data, without actually having to make
separate copies of the data. Kind of a specialized "compression"
algorithm. But, all of that could be done behind the scenes without
introducing a new layer of configuration complexity.
Well, there is a simple wellknown solution without thinking in duplicates.
That solution is called searching for the data.
It is even already partly implemented as views are searched for, so that
concept is known
within bind except that currently the search stops at the first matching view.
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? 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.
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? You're opening up a huge can of
worms there. You're going to have to carefully consider each one of the
cases to see if it does or does not qualify as a _bona_fide_ "not found".
There might be DNSSEC-validation repercussions too, but I'll let others
who are more versed in such things speak to those.
- Kevin
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
