On 28 Nov 2025, at 15:52, Ralf Weber <[email protected]> wrote:

> On 28 Nov 2025, at 15:41, Joe Abley wrote:
>> We are calling out TCP in this document (for example, here) as if it's the 
>> only alternative to UDP. RFC 9539 opens the door to alternatives that could 
>> also be used to avoid fragmentation problems, I think.
>> 
>> Rather than explicitly calling out TCP, is it perhaps worthwhile being more 
>> open in the language to other alternatives to UDP?
> 
> As you may know I think that probing in DNS is a bad idea, but even then I’m 
> not sure what RFC9539 has to do with it when it comes to this document which 
> focuses on the relationship between network protocol families and DNS.

I am also not a great fan of opportunistic probing, but we have other work in 
progress relating to the application of DoT and friends between recursive and 
authoritative. RFC 9539 simply says out loud that such transports can be used.

The point I am trying to make is that in this document weare making a 
distinction beween DNS transport protocols which are susceptible to 
fragmentation problems and those that are not. We are naming the first category 
"UDP" and the second "TCP". Since the second category includes more transport 
protocols than simply TCP, I am suggesting we consider referring to that 
category differently.

> All currently know current and future transports for DNS (some of which are 
> called out in RFC9539) rely on either UDP (Do53, DoQ, DoH3) or TCP (Do53, 
> DoT, DoH2) as lower level transports so I don’t think there is a reason to 
> call them out as the network problems will be the same.

TCP, DoQ, DoT and DoH are all DNS transport protocols that do not suffer from 
the same impact from fragmentation as UDP. The fact that DoQ does in fact 
include a UDP header I think strengthens the idea that we should be more 
careful about how we refer to the various options.


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

Reply via email to