So I agree with the general approach of using "SHOULD (unless _____)"
requirements when an unforgivable MUST isn't warranted. I was trying to
express that UDP can still be accounted for, it just requires the author
to explain why deferring to TCP shouldn't happen, with this text in the
normative:
"... without sufficient explaination [sic] for why UDP is a preferable
transport to TCP ..."
My intent is to shift the burden from accommodating UDP to justifying
why UDP is still required. In other words, making TCP the default absent
other scenario information. This gets awfully close to Tobias'
suggestion of just sunsetting Classic DNS over UDP.
On 7/6/25 14:51, John Levine wrote:
It appears that Paul Wouters<[email protected]> said:
This is not how protocols using DNS work. You can� t say � new� protocols must
use only a specific flavour of DNS
transport as it� s mostly not up to the new protocol or application how DNS is
resolved.
I am reminded of RFC 8689, REQUIRETLS, which lets a sending mail client pass a
flag telling the server
that the message must only be relayed over a TLS encrypted session. My MTA
implements it by carefully
checking the syntax and then ignoring it. If you're going to send me mail,
you'll have to live with whatever
I do with it.
Why would this be different? Maybe I'm on a network with jumbo frames and big
IP queries work well, or maybe
you think your traffic is big enough to need TCP, but you're just wrong.
R's,
John
_______________________________________________
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]
