I think it could be interesting to have an informational draft that: 1. Documents "always send empty UDP responses with TC=1" as an allowed DNS server behavior. 2. Documents "start with TCP" as an allowed DNS client behavior. 3. Enumerates all the RFCs and hacks that can be skipped if you do this. (Maybe try deleting all that logic from BIND and report the code size savings?)
I don't think this is likely to lead to a big shift away from UDP, but if it makes simple implementations easier that's probably a good thing. --Ben ________________________________ From: Tommy Jensen <[email protected]> Sent: Tuesday, July 8, 2025 2:28 AM To: Wes Hardaker <[email protected]> Cc: [email protected] <[email protected]> Subject: [DNSOP] Re: DNSOPFwd: New Version Notification for draft-tojens-dnsop-do-not-accommodate-udp53-00.txt On 7/7/25 16:07, Wes Hardaker wrote: > Tommy Jensen <[email protected]> writes: > >> Happy Second to Last I-D Submission Day! > It always brings interesting discussions to dnsop (I can be the pot or > the kettle in this conversation -- you pick). I like making chai in a pot, so I call dibs on that. >> This draft is short and to the point: it's time to stop accommodating >> Classic DNS over UDP when writing new protocols that can use encrypted >> DNS or Classic DNS over TCP instead. This draft is super short, so >> please see it for my arguments. > As is, I think it will bring up an interesting discussion. However, I > think the end goal seems to be to remove proper engineering for each use > case and only provide just a hammer. I'm not sure the DNS is ready to > do that. Fair. It also seems like as it does become more ready to use UDP less, that going straight to encrypted DNS makes more sense (which I'm perfectly fine with). > Case in point: the draft seems to point to both stub->resolver and > resolver->authoritative as being the same and subject to the same > suggestion of "just assume TCP exists". I chose to avoid diving into the differences based on Section 5 of RFC 7766, which individually specifies that stubs, recursives, and authoritatives MUST support TCP. Based on that, I did indeed let the text assume TCP support is a given. > I'm not sure it's wise to lump > those two situations together in this document (let alone the other > combinations of implementation type labels that can be added to this > mix). I agree, with the benefit of this and other feedback. I will be separating different DNS peer relationships out in the next version, whether the recommendations end up being similar or different. _______________________________________________ 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]
