After a recent-re-read of draft-ietf-dprive-unilateral-probing and its normative dependencies, I have a strong belief that the draft describes more of an experiment than a Proposed Standard. The reason we need "opportunistic" and "unilateral" actions is because there are gaps in specification, implementation, and deployment of services for recursive-authoritative encryption. Experimentation will help identify solutions to fill those gaps. Some examples:
We don't yet have a published standards track RFC that describes how an authoritative name server should publish capability information (draft-ietf-add-svcb-dns is still in the RFC Editor queue). It's not widely implemented or deployed. draft-ietf-dprive-unilateral-probing addresses this gap, describing how a recursive resolver can probe opportunistically to see if an authoritative name server will accept a connection on port 853 in the absence of server-published information. RFC 7858 explicitly notes that it "focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic" and that "It might work equally between recursive clients and authoritative servers". This is a specification gap, and work is required to ensure that DoT works reliably in this context. Experimentation would help determine if/how RFC 7858 needs to be updated. The draft should note this limitation in Section 2.2. I'd like to suggest changing the first paragraph from this: "Although this document focuses specifically on strategies used by DNS servers, it does not go into detail on the specific protocols used because those protocols, in particular DoT and DoQ, are described in other documents." To this: "Although this document focuses specifically on strategies used by DNS servers, it does not go into detail on the specific protocols used because those protocols, in particular DoT and DoQ, are described in other documents. DoT explicitly notes that it "focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic" and that "It might work equally between recursive clients and authoritative servers". Additional specification work might be required to ensure that DoT works reliably in this context." RFC 9250 is more definitive about support for recursive-authoritative encryption, but it has a gap, too. Section 5.1 explicitly notes that "For the recursive to authoritative scenario, authentication requirements are unspecified at the time of writing and are the subject of ongoing work in the DPRIVE WG". This is a specification gap, and experimentation would help determine if/how RFC 9250 needs to be updated. Experimental status worked for QNAME minimization. It can work here, too. If the working group agrees, it could be helpful to add text to the draft to describe the nature of the experiment. Section 2 would be a good place for that. I'm willing to contribute text. I also noticed that RFCs 7858 and 9250 are identified as informative references. Section 3 says that an authoritative name server "MUST implement at least one of DoT or DoQ on port 853". That's a normative requirement. Both RFCs should be identified as normative references. Scott _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
