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

[Phil Pennock]

On 2012-09-27 at 19:30 +0100, Tony Finch wrote:
> Phil Pennock <dnsop+phil at spodhuis.org> wrote:
> >   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,

Right; the difference is one of performance, with an additional query,
not one of outcome.

> 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.

>From the perspective of a client trying to decide whether to trust or
not, in-bailiwick is the only view they have; they won't probe to
distinguish if the ADDITIONAL section records are in a sub-zone.  I
could have written "any in-bailiwick answers which the server has
available", to include AA and glue entries (which can still be included
in the zone-file, although it obviously becomes a maintenance nightmare
to do that for anything more than NS glue records).

> 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.

And yet some do, which is why Bind is stricter than the RFC requires it
to be and will only truncate at the end.  Real world meets RFC and the
result is pragmatic software.

  http://bridge.grumpy-troll.org/2011/02/dns-dont-implement-edns0-to-bypass.html


Vernon Schryver wrote:
> Try some experiments to see if what kind of amplification you can get
> without ANY.  I see about 20X from `dig +dnssec asadfasdf.com`

A fair point, for which an approach only occurred to me after sending my
mail, so rather than reply in email to myself, I commented on my G+ post
(ah, netiquette):

  It's possible that this could be used to defer DNSSEC responses to
  non-ANY queries too, during DoS; the RRSIG belongs in the ANSWER
  section, but a TC response which skips the RRSIG and causes a TCP
  retry would:

  (1) return smaller results, turning off a large chunk of the
  amplification
  (2) with non-existent RR queries causing NSEC3 responses, defer the
  crypto work for NSEC3 until there's a TCP connection, which
  rate-limits the queries and reduces the CPU burden on the
  authoritative server

  All of this assumes that a modern server can be adequately tuned for
  TCP query volumes; for a dedicated DNS auth server, some very
  aggressive TCP state timeouts can be used (and can anyway, if the OS
  permits timeout tuning on a per-port/socket basis).


Yes, any response _can_ be large and be used, but for DDoS amplification
to spoofed source to be easy and useful, there needs to be something
_consistently_ large which can be sent back in a UDP response.  The main
candidates today are ANY and DNSSEC.  If we have a way to mitigate the
impact of those and can turn it on by default, we shrink the general
amplification ratio of the Internet's nameservers.  It's likely that in
future another RR type will result in similar amplificiation.  Perhaps
future RFCs for DNS should be required to tackle UDP amplification
attacks in their Security Considerations, forcing new RR type proposers
to make sure that the data they expect to insert into everyones' caches
is as small as possible, rather than whatever's most convenient for
their protocol.

As long as UDP is used and enough ISPs aren't using ingress filtering,
attacks will be possible; if we refuse to reduce the typical impact of
those attacks because the solution isn't perfect, we're left with
quixotic tilting at windmills, complaining about ISPs that don't filter.
It would be helpful to find ways to work within a reality of ISPs not
being willing to spend the money and engineering effort to be good
network neighbours, instead finding ways to make sure DNS isn't part of
the problem.

-Phil