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