[dns-operations] query dropping vs. returning nxdomain

Jim Reid jim at rfc1035.com
Wed Mar 15 17:17:05 UTC 2006


On Mar 15, 2006, at 16:31, Edward Lewis wrote:

> At 20:14 -0800 3/6/06, Matt Ghali wrote:
>
>> Would it generally be considered poor form to drop queries you do
>> not want to answer? Perhaps not only queries that would return
>> NXDOMAIN, but also queries that maybe administratively you do not
>> wish to answer.
>
> There's a difference between "I can't reach you" and "You told me
> no."  The former leaves the situation in a state of uncertainty.
> Uncertain is not a good state for a protocol to be in.

Well said Ed!

Declining to respond to queries -- even to say "I don't want to  
answer" or "ask someone else" -- is very bad operationally. Most  
resolving servers keep track of round-trip times to the name servers  
they query. So if your server remains silent when it could have  
responded somehow, my resolving server will decide your name server  
is dead/unreachable even though it isn't. So for a while my name  
server won't query yours even when resolving domain names that your  
name server would be prepared to answer for. The DoS implications  
from that should be obvious.

IMO regular queries from a resolving server must always get exactly  
one of the five answers below:

[1] Here's the data you asked for. Or that data doesn't exist.	 
[NOERROR or NXDOMAIN]
[2] Don't ask me, ask somebody else.				[referral]
[3] I might or might not know, but I don't want to tell you.	[REFUSED]
[4] Something bad happened that can't be explained easily.	[SERVFAIL]
[5] I don't understand the question.				[FORMERR or NOTIMPL]

It's probably OK to remain silent when queries originate from stub  
resolvers on external or unapproved IP addresses. Stub resolvers  
usually don't track RTTs. Besides, those resolvers should be querying  
their own local resolving server. And anyway traffic from alien stub  
resolvers might well be getting thrown away at the firewall so it  
never reaches the name server.



More information about the dns-operations mailing list