Hey Joe,
I agree with your standpoint on the advantages and reliability of
TCP. I’m also a bit puzzled by QUIC being built on top of UDP, and I
realize I still need to study the protocol more deeply — especially
given the jungle of middleboxes, firewalls, and DPI appliances we
encounter in various customers’ cloud environments.
For now, staying under the 1500-byte MTU is the only thing that
keeps me calm.
That said, a simple A record lookup typically involves multiple
sessions to different authoritative servers if you follow the chain
from the root — not one long session. In contrast, sessions where
large responses are expected (like NSEC or NSEC3 proofs) will almost
certainly happen over TCP.
Just sharing some field thoughts — thanks for your insight.
Carlos
On 08/07/2025 10:57, Joe Abley wrote:
On 8 Jul 2025, at 10:18, Carlos Horowicz<[email protected]>
wrote:
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.
I agree that TCP transport has a different set of trade-offs from UDP
transport, but different does not always mean worse. Being able to pass large
DNS messages more reliably and having greater trust that the address of the
other participant in a session is not spoofed are examples of advantages.
Note also that the setup and teardown handshake overhead is in principle able
to be amortised over the many messages that might be exchanged over a single
session, so over a busy session the aggregate cost tends towards zero and the
cost for a message over a session that is already established is as close to
zero as makes no odds.
The ability to handle large aggregate session state is something that has
turned out to be manageable for HTTP and many other protocols. I don't know why
we would assume that it's an insurmountable problem.
There were times in the past where groups of DNS operators in metaphorically
smoke-filled rooms said out loud that making TCP the primary mechanism was a
sensible thing to do. Since this seems not to have happened you might
reasonable speculate about the precise nature of the smoke, but the idea is not
necessarily outlandish as you might imagine.
Joe
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
