[dns-operations] query dropping vs. returning nxdomain

David Ulevitch davidu at everydns.net
Wed Mar 15 19:41:55 UTC 2006

On Mar 15, 2006, at 9:17 AM, Jim Reid wrote:

> 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.
> Declining to respond to queries -- even to say "I don't want to
> answer" or "ask someone else" -- is very bad operationally.

YES.  Authoritative servers which are reachable have a responsibility  
to give you an answer.  One will note that TinyDNS does *not* do  
this, it drops connections rather than providing NXDOMAIN.  We took  
steps at EveryDNS to make sure our authoritative servers did not  
simply drop connections.  We opted to provide a referral instead of  
NXDOMAIN for secret and abuse related reasons.  Either way, we while  
we probably aren't perfect, we try to cover the important things and  
we're working on the rest. (5 years and counting... heh).

> It's probably OK to remain silent when queries originate from stub
> resolvers on external or unapproved IP addresses.

External IP addresses?  Sounds like you are talking about a caching  
nameserver, especially when you mention stub's.  Stubs don't talk to  
AA nameservers.  And yes, I think stubs that are talking to the wrong  
caching nameserver deserve to be dropped on the floor.  In fact,  
that'd help solve parts of these problems in that open nameservers  
don't need to actually care where the src's are from (since they can  
be udp spoofed trivially) but they can care about who they answer  
to.  I prefer this route, in the short term.

> Stub resolvers usually don't track RTTs. Besides, those resolvers  
> should be querying
> their own local resolving server.

I am going to be lazy and not pull out my RFCs but don't stub  
resolvers, by definition, talk to their local caching nameserver?  
Otherwise they wouldn't be stub resolvers, they'd be resolvers or  
recursive nameservers or something else. right?


More information about the dns-operations mailing list