BIND View Option

[Kevin Darcy]

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