On 7/7/25 01:46, Carlos Horowicz wrote:
Hey there,
We still see TCP primarily in fallback scenarios triggered by TC=1
— often due to large TXT records or DNSSEC. That said, the real
shift in DNS transport is toward encrypted protocols like DoH and
DoQ, rather than increased reliance on TCP itself. We're observing
this trend across on-prem resolvers we manage that handle several
million QPS.
I'm excited by multiple responses and a presentation this week showing
that encrypted DNS (while still a minority use) is more common than DNS
over TCP. The draft had an underlying assumption that there was a need
to accommodate "I can handle connection-oriented transport, but not
encryption" at scale. Happy to be wrong.
Carlos Horowicz
Planisys
On 07/07/2025 05:11, Mukund Sivaraman wrote:
Hi Tommy
You have the right mind, but I don't know how this draft will fly in
today's world. If you routinely look at packet captures at ISP resolvers
(which handle some of the heaviest query rates of DNS outside CDNs), the
overwhelming majority of queries complete with DNS over UDP. Some
truncated responses cause TCP traffic, but it is the presence of DNS
over UDP that allow these resolvers to perform at the response rates
they do currently (and they still struggle sometimes). DNS over TCP
performance and scalability is still poor compared to DNS over UDP.
See, this struggle to scale statement brings up a question I probably
should have led with instead of making assumptions about: do resolver
implementors see their future as going to encrypted DNS by default
(separate questions for stub to recursive and recursive to
authoritative)? This draft assumed that a significant portion of
implementors would answer either "no" with some "yes, but not for many
years" mixed in, and that in the mean time we could move to TCP to
eliminate a class of considerations that moving to encrypted DNS would
also solve, but with less compute. If most implementors are in the "yes,
but not for many years" camp rather than never ever planning to deploy
encrypted DNS, then I would have written this draft very differently.
The considerations such as Kaminsky attack needing source port
randomization, fragmentation, etc. are already worked around in
implementation.
1. Introduction
Many uses of the DNS require message sizes larger than common path
MTUs. This poses problems for Classic DNS over UDP by requiring
It would be fairer to s/Many/Some/ here as the majority of DNS traffic
as seen in packet captures at ISPs complete (succeed) over UDP.
Fair. I was thinking in terms of proportion of use cases versus
proportion of traffic, but I can see how this is misleading. In whatever
form this draft ends up taking, I'll make note of this.
Mukund
_______________________________________________
DNSOP mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
DNSOP mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
