why setting view with recursion option is invalid in BIND 9.5.0-P1

[Kevin Darcy]

Chris Buxton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sep 8, 2008, at 8:11 PM, Kevin Darcy wrote:
>   
>> zq wrote:
>>     
>>> Hi,
>>>
>>> I have a problem about view {} with recursion option.I want the  
>>> server query
>>> all the domains in the internal.But it can't.
>>> The configuration file as follows:
>>> {
>>>        /* make named use port 53 for the source of all queries, to  
>>> allow
>>>         * firewalls to block all ports except 53:
>>>         */
>>>        query-source    port 53;
>>>        query-source-v6 port 53;
>>>
>>>        // Put files that named is allowed to write in the data/  
>>> directory:
>>>        directory "/var/named"; // the default
>>>        dump-file               "data/cache_dump.db";
>>>        statistics-file         "data/named_stats.txt";
>>>        memstatistics-file      "data/named_mem_stats.txt";
>>>        allow-recursion { any; };
>>>        recursive-clients 1500;
>>>        recursion true;
>>>
>>> };
>>> logging
>>> {
>>> /*      If you want to enable debugging, eg. using the 'rndc trace'  
>>> command,
>>> *      named will try to write the 'named.run' file in the $directory
>>> (/var/named).
>>> *      By default, SELinux policy does not allow named to modify the
>>> /var/named directory,
>>> *      so put the default debug log file in data/ :
>>> */
>>>        channel default_debug {
>>>                file "data/named.run";
>>>                severity dynamic;
>>>        };
>>> };
>>>
>>> view "view_0cnc"
>>> {
>>> match-clients  { any; };
>>> allow-recursion { any; };
>>> recursion true;
>>> zone "." {
>>> type hint;
>>> file "named.root";};
>>>
>>> zone "xxxxxx.com" {
>>> type master;
>>> file "named.xxxxxx.com";
>>> allow-update { 127.0.0.1; };
>>> };
>>> };
>>>
>>> I try dig the master zone from the server ,it works fine.And I do  
>>> named
>>> -unamed -g ,it seems everything works well.Who can tell me the  
>>> reason and
>>> how can I fix it?
>>> Thank you.
>>>
>>> Gelenbertang
>>> DATE
>>> 2008.9.9
>>>
>>>       
>> First of all, "recursion true" is invalid syntax.
>>     
>
> No, it's valid. It is equivalent to "recursion yes" or "recursion 1".
>
>   
>> Secondly, having only 1 view with "any" for match-clients, and no  
>> other
>> view-selection criteria, is completely useless and pointless. All of  
>> the
>> clients will get matched to that view, regardless of who/what/where  
>> they
>> are. You might as well have no views at all.
>>
>> Are you actually *hosting* any zones to the Internet? If not, then you
>> don't really need a view. Just set the appropriate
>> allow-query/allow-recursion/allow-query-cache for your clients'  
>> address
>> ranges, and define whatever internal zones you wish as authoritative.
>>
>> If you are hosting zones to the Internet, then create a separate view
>> for that (call it e.g. "hosting" or "external"), with a "match- 
>> clients {
>> any; };" and "recursion no", and then place that view *after* the one
>> which has a "match-clients" for your clients' address ranges, and  
>> which
>> they use for resolution.
>>     
>
>
>
> It would be simpler, if the BIND version in use is 9.4.1-P1 or later,  
> to not use views at all. Just use allow-recursion, which also implies  
> the behavior of allow-query-cache (assuming the latter is not  
> otherwise set), to control access to the cache.
>
> Views should only be used when necessary, and with full understanding  
> of their ups and downs.
>
>   
If one is able to convince one's users to use a totally different domain 
(or subdomain) for internal devices, than is visible from the Internet, 
then yes, I suppose one could get away with not using views.

But, users being users, chances are one is going to have at least two 
different versions of one's "main" zone (e.g. chrysler.com), i.e. an 
"internal" versus an "external" version, and that requires views, 
separate named instances, or separate boxes. Of the 3 choices there, 
views tend to have the best balance of (hardware-cost) economy and 
maintainability. Running multiple named instances on the same box is 
messy, I did it for years before views existed, and was glad to finally 
get rid of that kludge.

Another benefit of views is that if something happens to one's 
delegations, e.g. hosting of a domain gets outsourced and no-one 
bothered to tell you (such things happen in large bloated corporations), 
you're not stuck serving obsolete, stale zone data to your own users. 
With views, your resolver sees what a "normal" Internet resolver sees, 
and you host whatever you happen to host, and the two have nothing 
logically to do with one another. Architecturally, it's a nice neat 
separation.

- Kevin