On 7/6/25 20:07, Mark Andrews wrote:

On 7 Jul 2025, at 09:27, Michael De Roover <[email protected]> wrote:

On Monday, July 7, 2025 12:56:18 AM CEST John R Levine wrote:
On Sun, 6 Jul 2025, Tommy Jensen wrote:

"... without sufficient explaination [sic] for why UDP is a preferable
transport to TCP ..."

I'm with Joe, "because it still works OK."  We all know how long the tail
is so it's going to be a very long time before anyone can turn off UDP.

I'd think that it'd be more effective to make authoritative DoT work since
that's always TCP.
Interesting. Combining this with Wes (and probably others, sorry) pointing out this draft does not differentiate different peer relationship uses of DNS (I'll avoid calling them different protocols, which was a fun side topic at the deleg side meeting recently), maybe "save future doc authors the need to accommodate Classic DNS over UDP" is "authoritative DNS should be moving to DoT" rather than "use TCP when you're not encrypting". I thought moving to TCP as a default would be an easier burden since no config other than an IP address is needed (though I suppose DELEG will solve the work needed to discover this), and TLS handshakes require extra compute versus TCP handshakes. I am pleasantly surprised to hear it may be feasible to simply move the recommendation to encrypted DNS altogether.

To the point that UDP ain't broke, don't fix it... yeah, I get that. It complicates other things, but as Andrew said on another thread, that can also lead to "stop using the DNS for stuff".
Would say so too, incumbents are one hell of a force to be reckoned with. In
addition, I am generally more convinced about wanting UDP to be available to
everyone using my servers, than I am about TCP being available like that. It's
one of those things where I might want to pay more attention to TCP at the
firewall level, because of zone transfers and whatnot. Probably unjustified, but
it is what it is.

Granted, there is also a very real security consideration with UDP... DNS
amplification attacks, as well as NTP amplification attacks that work in a
similar fashion. Both of them work because you can impersonate the source
address in UDP. So you can pretend to be the target of your amplification
attack, and the server will respond accordingly. Response is larger than
query, and that's your amplification factor.
We already have defences for DNS amplification over UDP.  DNS COOKIE and TC=1.
Saying don’t do UDP is blaming the wrong thing.  If your nameserver doesn’t
support DNS COOKIE you should replace it with one that does.
Definitely true. OTOH, TCP support is more readily assumable than cookies, and at runtime, choosing a new name server may not be an option.


So for that reason, I think I would want to prefer TCP, because it gets rid of
that underlying vulnerability entirely. Better yet if we can finally start
encrypting DNS too. But if the vast majority of applications still use and are
built with UDP in mind, then moving preference and getting rid of, are very
different things. Moving preference, sure use what works best for you. But get
rid of something entirely, and you'll really, /really/ need to justify it. I
don't see the latter happening anytime soon.
I wasn't intending to "get rid of" but rather "moving preference" in this parlance. However, the signal is pretty clear that Classic DNS over TCP doesn't seem to be the right move (I'm seeing either Classic DNS over UDP use should be left alone, or we should move preference directly to encrypted DNS).
--
Met vriendelijke groet,
Michael De Roover

Mail: [email protected]
Web: michael.de.roover.eu.org

Activisme is pas nuttig, wanneer het kan bereiken wat het wenst te bereiken,
binnen de limieten van het huidige systeem. De rest is geschiedenis.
-- [email protected]


_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to