This is a discussion on Re: Turned recursion off and now lookups not working - DNS ; 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 ...
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,
>> control queries and/or recursion via allow-query and/or
>> Note that BIND 9.4.0 just came out with an "allow-query-cache" option,
>> which makes allow-recursion a little more palatable -- previously,
>> answers from the cache do not require recursion, this data was
>> 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
> 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.