Bind doesn't look up past its own Domains

[Kevin Darcy]

aklist_bind at enigmedia.com wrote:

>  
>
>>>// -------------------
>>>// OPTIONS
>>>// -------------------
>>>
>>>options {
>>>       directory "/var/named";
>>>       dump-file "/var/named/data/cache_dump.db";
>>>       statistics-file "/var/named/data/named_stats.txt";
>>>       query-source address * port 53;
>>>       recursion no;
>>>};
>>>
>>>Doesn't one want to have recursion set to NO to keep others from using 
>>>your
>>>DNS server for lookups or should the restrictions be set elsewhere for 
>>>that.
>>>In otherwords, I want the local network to use the nameservers for 
>>>lookups,
>>>but I don't want the outside to.  Restrict by IP?
>>>
>>>      
>>>
>>You could do that, via "allow-recursion". That gives a "friendly"
>>response to queries outside of your hosted zones, a referral to the
>>closest information in the hierarchy that your server knows about.
>>Trouble is, it may give out *too*much* information for some of the more
>>security-minded types -- if the answer to the query is in your cache, it
>>will be returned, since no recursion is necessary to fetch it. Allowing
>>arbitrary Internet clients to get query answers from your cache could
>>theoretically allow them to do forensics on what sites your clients are
>>visiting, etc. so it may be undesirable to give access to that data.
>>Also, answering from cache may attract some "mooches" who think they can
>>use you as a pseudo-resolver (you're likely to have the answer to
>>popular queries in your cache at all times).
>>
>>A more stark approach, to which Mark alluded indirectly, is to use a
>>restrictive "allow-query" globally, with liberalized overrides for all
>>of the zones you host. So if an external client queries outside of your
>>hosted zones they get an unfriendly REFUSED response, instead of
>>whatever cached data you might happen to have.
>>
>>A more sophisticated approach would involve having separate views for
>>internal and external clients, with recursion turned off in the external
>>view. In that case, queries outside of hosted zones would return an
>>"upwards referral" to the root zone. Since this is hardly more useful to
>>resolvers than a REFUSED response, the views approach might be overkill
>>if all you're trying to do is restrict access. There are other
>>architectural reasons why you might want to implement such a
>>view-separation though...
>>    
>>
>
>I'd just like to double-check that I have my recursive options set 
>correctly.
>
>I have a public and private view, with the private view defined as an ACL 
>"localsubnet" with my local subnet IPs in it.
>
>In my options I don't have any recursion statements.
>
>My internal view comes first, with the following setting:
>
>view "internal" {
>    match-clients {"localsubnet"; };
>    recursion yes;
>//zone info here
>};
>
>then the external view:
>
>view "external" {
>    match-clients {any;};
>    recursion no;
>//zone data here
>};
>
>Is that OK, or do I also need an "allow-recursion" statement in my options?
>
That should be fine. Technically, one never needs "recursion yes", since 
that's the default setting, so it's really just a matter of personal 
preference whether to be explicit about it or not.

                                                                         
                     - Kevin