recursion control clarification request
Barry Margolin
barmar at bbnplanet.com
Mon Feb 28 15:29:33 UTC 2000
In article <2.2.32.20000228080133.008ddbd8 at dbtech.net>,
Dave <dave at dbtech.net> wrote:
>In order to stop this using 8.2.2-P5, Can I simply do the following:
>
>(examples taken from the archive, thanks Barry)
>
>allow-recursion { x.x.x.x; x.x.x.x; };
>fetch-glue no;
>
>or would this be better:
>
>acl my-users { 192.168.10.0/24; 172.18.0.0/16; };
>
> options {
> allow-query { my-users; };
> ...
> };
>
> zone "something.com" {
> ...
> allow-query { any; };
> };
>
> zone "someone-else.org" {
> ...
> allow-query { any; };
> };
>
>Sorry for my confusion, but I am not quite clear on the pros/cons of the two
>approaches.
Either approach should work. The advantage of using "allow-recursion" is
that you don't have to have all those repetitive "allow-query" statements
in every zone.
I'm not sure, but I think if you use "allow-recursion", a non-customer will
be able to look up things that happen to be in your cache (because a
customer looked it up earlier). But "allow-query" will prevent them from
looking up anything outside your zones.
An even better solution is to run separate servers: a caching-only server
that uses "allow-query", and an authoritative-only server that uses
"recursion no". If you don't have multiple physical servers, you can do it
with virtual servers: configure two IP addresses on the NIC and run
multiple named processes with different configuration files that use
"listen-on" to bind to a specific address.
--
Barry Margolin, barmar at bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
More information about the bind-users
mailing list