recursion vs allow-recursion

recursion vs allow-recursion

Post by b1914 » Fri, 10 Mar 2006 01:10:20


I see in the "options" statement in the config file two items:

recursion yes_or_no;
allow-recursion { address_match_list };

I assume that the default for the first is yes. If I want to add the
second statement with an address_match_list, do I have to set

recursion no;

in addition? How do these two statements iteract? Thanks.
----------------------------------------------------------------------
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone: +1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 222, Room D209 Internet: XXXX@XXXXX.COM
Argonne, IL 60439-4828 IBMMAIL: I1004994
 
 
 

recursion vs allow-recursion

Post by Bil » Fri, 10 Mar 2006 01:49:36

Per the BIND ARM, the default is indeed yes. I've included that bit of
text from the ARM for convenience.

recursion
If yes, and a DNS query requests recursion, then the server will attempt
to do all the work required
to answer the query. If recursion is off and the server does not already
know the answer, it will
return a referral response. The default is yes. Note that setting
recursion no; does not prevent
clients from getting data from the server's cache; it only prevents new
data from being cached as an
effect of client queries. Caching may still occur as an effect the
server's internal operation, such as
NOTIFY address lookups. See also fetch-glue above.

As for the second question, I believe the answer is no -- you simply
don't include the recursion option in your named.conf, thus assuming the
default. If you enable it to no, I believe that trumps anything in
allow-recursion.

As for the interaction between the 2 options, the former controls
whether the server will perform recursive queries on behalf of clients
sending them while the latter restricts who can make said queries if
recursion is enabled.

If you have a copy of the BIND ARM handy, it does a pretty good job of
explaining things.

Bill Smith
<mailto: XXXX@XXXXX.COM >
ISS Server Systems Group
Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Road
Laurel, MD 20723
Phone: 443-778-5523
Web: http://www.yqcomputer.com/



-----Original Message-----
From: XXXX@XXXXX.COM [mailto: XXXX@XXXXX.COM ] On
Behalf Of Barry Finkel
Sent: Wednesday, March 08, 2006 11:10 AM
To: XXXX@XXXXX.COM
Subject: recursion vs allow-recursion

I see in the "options" statement in the config file two items:

recursion yes_or_no;
allow-recursion { address_match_list };

I assume that the default for the first is yes. If I want to add the
second statement with an address_match_list, do I have to set

recursion no;

in addition? How do these two statements iteract? Thanks.
----------------------------------------------------------------------
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone: +1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 222, Room D209 Internet: XXXX@XXXXX.COM
Argonne, IL 60439-4828 IBMMAIL: I1004994

 
 
 

recursion vs allow-recursion

Post by Chris Thom » Fri, 10 Mar 2006 04:30:18


[...]

Experiment indicates that is right, but the ARM isn't all that clear
on the subject.

Since BIND 9.2.4 or 9.3.0 (item 1533 in the change log), BIND issues a
warning if both "recursion no" and "allow-recursion ..." are specified;
e.g.

Mar 8 19:08:16 limpkin.csi.cam.ac.uk named[212]: [ID 866145 daemon.warning]
both "recursion no;" and "allow-recursion" active

Of course, that might be suppressed depending on logging options.
named-checkconf doesn't seem to care about this combination.

--
Chris Thompson
Email: XXXX@XXXXX.COM
 
 
 

recursion vs allow-recursion

Post by Mark Andre » Fri, 10 Mar 2006 07:24:05


If you set "recursion no;" then allow-recursion is effectively
ignored.
 
 
 

recursion vs allow-recursion

Post by Mark Andre » Fri, 10 Mar 2006 07:33:40


Up to date version specific copies of the ARM are available
from http://www.yqcomputer.com/
for the current releases.

Mark