secondary not returning external addresses or returning root servers

Kevin Darcy kcd at daimlerchrysler.com
Fri Feb 10 22:24:10 UTC 2006


rsesnaski at yahoo.com wrote:

>Just a quick note in case someone picks up the this problem via a
>google.
>I just tracked down a problem where my secondary was returning data
>on the local domain but not any external addresses. From a windows box
>it returned a list of the root servers.
>
>I tracked it down to a "recursion no;" statement which now makes senses
>but there are a few docs out there that list an example secondary with
>"recursion no;" in the example. Not fully sure of the implications as I
>still need to read more but commenting that out allowed external
>look ups.
>
The prevailing recommendation is to segregate your *resolving* service 
(which is used by your own clients and for which recursion is necessary 
and turned on) from your *hosting* service (used by Internet clients, 
for which recursion is unnecessary and turned off). If you allow 
arbitrary Internet clients to recurse, then you can find they are 
"lunching" off you, DoS'ing you, trying to poison your cache, etc., but 
yet you need to allow those same Internet clients to resolve the domains 
you host, hence the segregation. You can implement this segregation with 
separate boxes, separate instances on the same box, listening to 
different interfaces, or by separate views (which are typically 
configured to differentiate by the source of the client) within the same 
instance.

If you really *must* use the same instance, without views, for both 
hosting and resolving, then at least you can use "allow-recursion" to 
provide some fine-grained control over who can recurse and who can't, 
and/or "allow-query" in a default/selective-override mode, which more 
forcefully determines who can query what, including stuff that doesn't 
require recursion, like cached answers, information which miscreants 
could otherwise use to track your users' surfing habits or whatnot.

                                                                         
                                             - Kevin




More information about the bind-users mailing list