[dns-operations] How many kinds of DNS DoS attacks are we trying to stop ?

[Tony Finch]

Phil Pennock <dnsop+phil at spodhuis.org> wrote:
>
>   DNS DDoS amplifier resistance: as a thought, would it be a reasonable
>   step, not hurting interop, to have an authoritative DNS server process
>   a UDP-based ANY query by including, at most, an MX and any A responses
>   in the ANSWER section and setting the TrunCated bit of the response if
>   there were any other records skipped?
>
>   So someone debugging will likely see the full response as their client
>   switches to TCP; someone using broken old mail-servers (that don't
>   understand recursive cache behaviour as different QTYPE cached entries
>   expire at different times) still gets an MX response, and things
>   generally work, but the opportunities for amplification over UDP are
>   reduced.

You're making this more complicated than it needs to be. qmail is the only
widespread software that erroneously relies on ANY queries. It uses the
standard resolver library, so it falls back to TCP if the TC bit is set
(and so does its upstream recursive DNS cache), and it only cares if the
result is a CNAME or not, so partial responses to ANY don't bother it.

You might as well minimally truncate the response, as in RRL "slip"
responses.

http://fanf.livejournal.com/122220.html - qmail ANY query bugs

>   The most notable change would be that the ANY response with the MX
>   would not include in-bailiwick A records for the hosts pointed to by
>   the MX records in the ADDITIONAL section, because some clients assume
>   that only the last section received could have been truncated, so an
>   ADDITIONAL section can't be included.

Note that a mail server can't rely on MX additional section processing,
because the TC bit isn't set if RRsets are dropped from the additional
section. This means it has to make separate queries for A and AAAA if they
aren't present in the server's response - it can't tell the difference
between nonexistent and missing. Missing address records can happen
even if both mx owner and targets are all in the same zone, if the
authoritative server has minimal-responses turned on and the cache hasn't
been primed with the addres records.

Also, in-bailiwick is the wrong term since it includes sub-zones which
might be hosted elsewhere. Additional section processing doesn't require a
server to retrieve data it doesn't already have.

Clients are allowed to assume that records are not dropped from the middle
of truncated responses, because that is forbidden by section 6.2 of RFC
1035.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at
first. Rough, becoming slight or moderate. Showers, rain at first.
Moderate or good, occasionally poor at first.