Authoritative Server - Referrals to root

Kevin Darcy kcd at daimlerchrysler.com
Thu Apr 7 21:12:16 UTC 2005


Unlisted wrote:

>For security reasons we should not be serving authoritative data if the
>end user does not want it/approve of it.  This above domain was one
>example - but it happens quite often on others.  A customers dns will
>expire / be terminated / or whatever else and unless they are current
>customers we should not be serving anything for them.  Serving
>authoritative data for a customers zone without their permission could
>lead to legal problems (sitefinder revisited).
>
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40329
>
>Im curious - why would BIND 9 return a NOERROR on a zone thats not in
>named.conf?  I think the appropriate behaviour would be not to return
>the list of ROOT-SERVERS and return a SERVFAIL?  
>
No, that would not be appropriate. SERVFAIL is for operational issues 
encountered while trying to resolve the name, e.g. timing out trying to 
query the authoritative servers for the zone (if recursing), running out 
of memory, etc.

>Can we turn off
>referrals on unknown zones?  
>
The rule is, if you're not willing to recurse to get the answer, you 
should at least give the closest referral you have for the queried name. 
In the absence of anything else, that would be the root zone.

>Maybe just removing the root hints file
>does this?
>
Did you try it? It won't help, since all BIND nameservers need to have 
root-zone information, whether this comes from a "priming" query (based 
on the contents of a hints file, the compiled-in hints file, or 
forwarding) or from authoritative data (if the nameserver is master or 
slave for the root zone). There's no way to *not* have root-zone 
information.

If you want to *administratively* deny query access for a given zone, 
then define the zone as master or slave with an "allow-query { none; };" 
on it. Clients will get a REFUSED response.

                                                                         
                                                                        
- Kevin




More information about the bind-users mailing list