Re: Bind doesn't look up past its own Domains

2 msg	Cannot resolve name - seems like propagation is...
5 msg	Question about internet ethics? and how DNS is ...
2 msg	MySQL BIND
2 msg	Multiple nameservers
1 msg	Difference between worker threads and general t...
7 msg	Problem with domain on local network
2 msg	dhclient complains Can't update forward map no ...
4 msg	Recursion question + trust?

Bind doesn't look up past its own Domains
\ Sir Galahad (27 Mar 2006)
. \ Mark Andrews (27 Mar 2006)
. . \ Sir Galahad (27 Mar 2006)
. . . \ Kevin Darcy (28 Mar 2006)
. . . \ aklist_bind (28 Mar 2006)
. . . . \ Kevin Darcy (29 Mar 2006)
. \ Mark Andrews (27 Mar 2006)

2 msg	Microsoft clients SECURE DYNAMIC UPDATES
4 msg	Does BIND always query the other authorative na...
3 msg	Dig options?
6 msg	how was bind compiled/configured?
2 msg	Bulding BIND9.3.1
3 msg	RE: Forward zone problem: Forward query vs Dire...
3 msg	Bind 9.3.1 master with 'stub' in-addr-arpa zone...
3 msg	How to perform IP address management and how to...
2 msg	Zonetransfers
8 msg	failed while receiving responses and jnl touching
4 msg	dhcp client and dns bind question

Subject:	Re: Bind doesn't look up past its own Domains
Group:	Bind-users
From:	Kevin Darcy
Date:	29 Mar 2006

aklist_bind 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