Turned recursion off and now lookups not working

Kevin Darcy kcd at daimlerchrysler.com
Wed Oct 11 20:45:16 UTC 2006

Steve Ingraham wrote:
> Kevin Darcey wrote:
>> It's only the *external* clients you don't want to recurse for. You
> still >may need to recurse for your *internal* clients, unless they
> don't require >resolvability of Internet names (e.g. if everything is
> behind application->level proxies), or, alternatively, you intend to
> host the whole Internet >DNS namespace on your computer (biiiiiig box).
>> Options: run separate boxes for hosting versus recursion, separate BIND
>> instances on the same box, separate "view"s within the same instance,
> or 
>> control queries and/or recursion via allow-query and/or
> allow-recursion. 
>> Note that BIND 9.4.0 just came out with an "allow-query-cache" option, 
>> which makes allow-recursion a little more palatable -- previously,
> since 
>> answers from the cache do not require recursion, this data was
> available 
>> to external clients regardless of the allow-recursion settings, which 
>> was arguably  "information leakage" that might not make one's security 
>> administrators/auditors very happy.
>> There was recently a thread here on a very similar topic. See the posts
>> with the subject line "recursion question" at 
>> http://marc.theaimsgroup.com/?l=bind-users&w=2&r=1&s=recursion+question
> &q=b
> I am the person who originated that original question you are referring
> to.  I am still somewhat fuzzy on the recursion thing.  I have set up
> the named.conf file with the option line also:
> {
> recursion no;
> };
> I have not seen any problems with user access to the internet.  I do
> have an internal DNS server inside the firewall running Windows 2000 as
> an internal DNS server.  In my ignorance of much of the issues
> associated with DNS I have concluded that this internal DNS is allowing
> our client machines to resolve names.  Is this a correct assumption on
> my part?
Think of "recursion no" as an evil shrink ray that turns your mighty 
superhero resolver into a meek little non-recursive nameserver, 
basically little more than a specialized database server. Once 
diminished like that, it can *only* answer from its own authoritative 
data (i.e. data in zones that are defined as type master or type slave), 
and won't lift a finger to query other nameservers on a client's behalf. 
But, at least with its recursive capabilities wing-clipped, its 
query-answering powers can only be used for good :-)

If a nameserver has "recursion no", therefore, I think reasonable to 
conclude that the internal stub resolvers (e.g. end-user clients) 
pointed to that nameserver, if any, don't actually need to resolve 
Internet names. Presumably this is because all of their interaction with 
the Internet is done through application-level proxies (e.g. web 
proxies, mail gateways, etc.), and it's the *proxies*, not the end-user 
clients, that are doing the Internet name resolution, using their own 

As for resolving internal names, "recursion no" imposes the burdensome 
requirement that every internal zone needed by a given community of stub 
resolvers be defined as master or slave on the nameserver (or view) 
which serves those stub resolvers. This doesn't scale very well, 
especially if you have diverse business units which need to co-ordinate 
the setup and ongoing maintenance of multiple master/slave relationships 
between each other's servers. It can also be viewed as overkill to slave 
a zone for which queries are infrequent (how _much_ overkill depends on 
a variety of factors, e.g. REFRESH setting relative to the TTLs of the 
more-popular RRsets, frequency of changes to the zone, size of the zone, 
whether the master and slave both support IXFR, etc.). Regardless of 
those considerations, sometimes it's necessary to slave a zone, just to 
provide maximum redundancy/availability.

Just because you slave a zone, of course, doesn't mean you attract query 
traffic for that zone from foreign resolvers. You can be a "stealth 
slave", which doesn't appear in the NS records of the zone.

For the foregoing reasons, I only define "recursion no" on our primary 
master server for the internal DNS (which is only supposed to 
communicate to other DNS programs via non-recursive transactions, 
including zone transfers), and in one of the views of our 
Internet-facing boxes. Everything else has recursion enabled.

- Kevin

More information about the bind-users mailing list