Bind doesn't look up past its own Domains
aklist_bind at enigmedia.com
aklist_bind at enigmedia.com
Tue Mar 28 14:02:32 UTC 2006
>>
>>// -------------------
>>// 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?
TIA, Andrew
More information about the bind-users
mailing list