On Wed, 08 Jul 2026 08:11:29 +0200, =?utf-8?B?T25kxZllaiBTdXLDvQ==?= wrote: > >> On 7. 7. 2026, at 20:11, Wes Hardaker <[email protected]> wrote: >> >> Ondřej Surý <[email protected]> writes: >... >I don't think it is that easy and I would like the cryptographers to provide us >with more support for smaller signature sizes. > >>> The fact is that we either need a PQC algorithm that will be >>> size-suitable for DNS or we will have to brace for the impact of >>> completely switching to TCP. >> >> The top of my document lays out an argument that: >> >> 1. we better accept TCP is coming > >I am starting to tend to agree, but I have some more measurements on my >mind to do. > >> 2. but we may try to reduce the amount of traffic we do send to mitigate >> some of that impact. > > >I this that it doesn't matter that much and we should rather focus on making >the TCP work just fine for DNS than. (E.g. I agree with what Joe said.)
The cryptographers are very smart, and I'm sure they would make the keys and signatures smaller if they could. But math is unforgiving. I think we are all a bit spoiled from the RSA->elliptic curve conversion where everything got tiny all the sudden. :-) I'm not a cryptographer, but I have done a couple of things with TCP and DNS. My experience is that TCP is not nearly as bad as people often think. The pieces we need to "make TCP work just fine for DNS" are already here if we are careful to turn them on. Specifically, we looked at TCP and DNS when we were looking at DNS-over-TLS for privacy. There a bunch of options you want to use if you want to go fast and avoid overhead, but they exist and can be turned on fairly easily. We summarized these options section III-A of the paper: "Connection-Oriented DNS to Improve Privacy and Security." at IEEE S&P 2015, <http://dx.doi.org/10.1109/SP.2015.18>, or <https://ant.isi.edu/%7ejohnh/PAPERS/Zhu15b.pdf>, and the that paper used trace replay and analysis to look at client latency and server memory are not bad with TCP over UDP. To confirm *actual* server performance (CPU and memory) took more work. We reported on that work in "LDplayer: DNS Experimentation at Scale" at ACM IMC 2018 <https://doi.org/10.1145/3278532.3278544> and <https://ant.isi.edu/%7ejohnh/PAPERS/Zhu18b.pdf>. The TL;DR version is: a very reasonable amount of memory (~32GB) can handle root server traffic from that era (~43k q/s) 100% over TCP. CPU was about equal with UDP vs. TCP. This result is because we are benefiting from the years of optimizations the web folks have put into TCP. IMHO DNS operators need not fear the connection, and we do not need to demand a single-UDP-packet request/response. -John _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
