[dns-operations] Questions on DNS Flag day 2020 proposal

[Paul Vixie]

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

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.

-- 
P Vixie