[dns-operations] Recently closed open resolver and reflection attacks
roy at dnss.ec
Thu Mar 7 16:57:59 UTC 2013
On Mar 7, 2013, at 7:06 AM, Edward Lewis <ed.lewis at neustar.biz> wrote:
> On Mar 6, 2013, at 20:33, Paul Vixie wrote:
>> if the authority server in question is configured to be a primary or secondary server for a zone which is at or above the qname, then the correct answer is either authoritative-positive, authoritative-negative, or servfail.
> Or a non-authoritative referral but then again there's also FROMERR and come to think of it other results involving CNAME, DNAME and even a wildcard match.
> I have over time tried to come up with a state machine description of what DNS returns but never could complete the task. The protocol is too hap-hazzard in architecture to be nicely reverse engineered. Sigh.
>> if said authoritity server is not configured to be a primary or secondary for any zone at or above the qname, then the proper response is refused. (not an upward delegation as a i once had it in bind8 -- my apologies to all.)
> We chose SERVFAIL instead of REFUSED for that - in the sense that the service failed by sending the querier to the wrong place. I don't think either is better than the other, just saying this because it's not always clear what's the right RCODE.
We often see resolvers trying the next authoritative server for a domain when a server responds with SERVFAIL, and eventually comes back when all other servers respond with SERVFAIL, repeating the query over and over. When a server responds with REFUSED, we do not see that behaviour, and our expectation is that for the time being, the REFUSED issuing server is not consulted for a specific domain.
Requests to a server for a domain that it is not responsible for, should not return servfail, as that would cause well behaving resolvers to come back for requests for that domain, as SERVFAIL indicates (again, imho) a temporal failure.
To classify behaviour I often see, the bulk of well behaving resolvers behave in the following way:
SERVFAIL: Keep the server in the server selection set, try others first.
REFUSED, NOTIMP, FORMERR: Remove the server from the server selection set, try others.
I have not seen any real distinguishable different behaviours between refused, notimp and formerr, other than queries logged.
Hope this helps,
 BIND responds with SERVFAIL to a query where the QNAME is longer than 255 bytes. When all the servers for a domain are BIND, this often leads to a burst of requests, striped over all the authoritative servers for that domain. Naturally, a resolver should not emit a query with a QNAME longer than 255 bytes, however, we do not choose the resolvers we respond to, and thus simply deal with these bursts. A FORMERR would (imho) be the appropriate response.
More information about the dns-operations