[dns-operations] Questions on DNS Flag day 2020 proposal
paul at redbarn.org
Mon Jun 17 12:11:04 UTC 2019
Tony Finch wrote on 2019-06-17 04:05:
> Paul Vixie <paul at redbarn.org> wrote:
> There are two break points in "at scale" here: DNS servers have
> historically been (and often still are) terrible at handling TCP. This is
> an entirely userland problem, and there is a lot of scope (orders of
> magnitude) for DNS servers being less terrible by doing what web servers
to be clear, the poorness of tcp handling by dns servers has
_historically_ been due to userland issues, as well as to the definition
of tcp/53 connection handling in the dns protocol. DoT fixes the latter.
kevent() and similar will fix the former.
at which point the lack of kernel support on many existing dns
platforms, and the lack of kernel memory on many existing dns servers,
will become the new bottleneck. it is that limit that consensus was
"just do what web servers do".
> The other break point is the whole-system performance differences due to
> the extra state that TCP requires compared to UDP. This should not be
> ignored, even though that kind of performance problem is a long way out of
> reach for many systems :-)
tony, nothing which can be abused won't be. presume the worst case
attack, because it's coming, to every server, sooner or later. all
vulnerable systems take their turn in the barrel. no exceptions.
this is why RFC 6013 specifies compressed state (like for syn flood
protection, so having attack-scale capacity) for quiescent sessions.
i really needed to try harder to sell this. instead we got TFO, which
solves a different problem, and changes nothing in the attack scenario.
and on the basis of this unnec'y weakness, we're all going to get QUIC.
More information about the dns-operations