Please let me enumerate the cases we're observing in more detail.
- TCP is still needed in zone transfers and XoT (AFAIK QUIC isn't used
in encrypted zone transfers, I might be wrong)
- TC=1 triggered by big TXT's or DNSSEC and would fallback to TCP
- DoH will use HTTPS protocol. If alpn=3 is negotiated , it will use
HTTP/3 over QUIC (UDP+TLS), if alpn=2 is negotiated it'll use HTTP/2
(TCP/TLS). The hypothethical presence of an HTTPS RR would facilitate
things, encrypt SNI with ECH, etc ... but it doesn't add to the TCP vs
UDP discussion
- several customers changed their DKIM from 1024 to 2048 bits keys as
recommended by big e-mail providers, which triggers TC=1 more often and
increasing the need for TCP
- an EDNS of 4096 can cause fragmentation because of a 1500 MTU. If
you're over the MTU size, in the wild a NAT/Firewall/DPI box might drop
the second fragment or fail to reassemble it properly. So our practical
approach (and probably others') has been to limit EDNS size to 1232.
Hence TC=1 is more often being triggered. I'd use EDNS-4096 inside a
fully controlled LAN, but not in the wild Internet.
I must say I’m not particularly sympathetic to DNS over TCP. While it’s
a necessary fallback in some cases, it slows things down due to
handshake overhead, increased latency from retries, and the need to
maintain state per connection.
From an operational standpoint, especially in high-QPS environments,
TCP adds complexity and resource pressure — and it’s not uncommon to see
it exploited in abuse scenarios as well (e.g., intentional TC=1
triggering or TCP floods).In our logs, we often see slip being triggered
as part of rate-limiting, which confirms TCP isn’t just a fallback but
maybe part of the threat surface.
My 0.2 cents, not mean to complicate the discussion, only to share
real-world observations from our operations.
Carlos Horowicz
Planisys
On 08/07/2025 08:16, Tommy Jensen wrote:
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 [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
