[dns-operations] Questions on DNS Flag day 2020 proposal
Paul Vixie
paul at redbarn.org
Mon Jun 17 10:34:51 UTC 2019
Davey Song wrote on 2019-06-16 23:12:
> Hi folks,
>
> ...
>
> 1) How to enhance and implement the idea of making DNS over TCP support
> mandatory. In 2019 flag day, I know the approach is to narrow the living
> space of authoritative servers to get a good performance from a updated
> resolver if they do not support EDNS. But as to TCP, how to enhance it?
i have much sadness that RFC 6013 was not adopted. it contains a
compressed endpoint state identical to that used for syn flood
protection (so, works at attack-scale), and allows a connection to go
quiescent, restartable at any time, preserving the old window size. this
means it can answer queries in a single round trip no matter whether
they fit in a single tcp segment. i guess we just did a bad job selling
it. see also <http://c59951.r51.cf2.rackcdn.com/5034-126-metzger.pdf>.
note, bill implemented this for bsd and linux. what was missing was a
code-point, since none remain after all the other tcp expansion.
> ...
>
> 2) No matter how to implement it, it definitely exerts a huge pressure
> on authoritative DNS operators (huge of them) due to the performance of
> DNS over TCP. Did the guys who proposed this ever ask the opinion from
> the circle of authoritative DNS operators? Is there any vote or rough
> consensus from majority of them? And where? ICANN GNSO TechOps? I heard
> this complain because some of DNS operators feel strongly that they have
> been bullied even not being asked.
the position i heard was, we know how to do tcp at scale, look at any
modern web server or load balancer -- so, just do what they do. i didn't
agree that we know how to do tcp at scale, or that web servers or load
balancers are good examples. however, that seems to have been consensus.
noting, such a web server can require tens of gigabytes of kernel memory
to hold all of the necessary connection state. not a design worthy of
emulation, according to me.
> I also suggest we should continue this discussion and invite more people
> to join in case of giving people a bad impression as a "tyranny by the
> few".
in dnsop there is no such thing as a bad idea, and whoever shows up or
writes a draft, can do pretty much whatever they want. i now realize
that we did still need dnsext, and should not have shut it down, because
it provided a gating function against added complexity in this protocol.
--
P Vixie
More information about the dns-operations
mailing list