Hi, I found a few problems with this draft. 1. Provisioning In Section 3.1.6, there is this text: > ServiceMode (Section 2.4.3 of [I-D.ietf-dnsop-svcb-https]) SHOULD be used because the Encrypted DNS options are self-contained and do not require any additional DNS queries. When I first hit this text, I got the strong impression that DHCP/RA would be carrying SVCB resource records, but that is not the case. This text is therefore misleading. This leads to the next point, which is that there is a trap here for an incautious implementer that really needs to be better signposted. The name that is authenticated when you use AliasMode is the **input** name. If you supply an authenticated domain name and populate DHCP using the ServiceMode results, they risk skipping over any names that might have been queried in that process, either those with AliasMode SVCB records or those with CNAME records. This text needs to be clarified and the pitfalls better signposted. 2. Authentication In Section 3.3 there is this text: > The client follows the mechanism discussed in Section 8 of [RFC8310] to authenticate the DNS resolver certificate using the authentication domain name conveyed in the Encrypted DNS options. This is not a specification that can be implemented interoperably. Despite it being on the standards track[1], RFC 8310 is a multiple-choice questionnaire, not an interoperable protocol specification. It offers a number of deployment options. It is not sufficient to leave clients to guess which or for servers to support all options to allow clients a choice. Even if this document doesn't choose, the implications of not choosing need to be properly documented (which is probably more work than choosing, frankly). 3. Error Handling The specification does not describe how to handle poorly formatted options. 4. Other There are a number of formatting issues (Section 8.2 has a diagram containing a table rather than a table); same for the aside in Section 3.1.1 and Section 10. There were a number of other issues that would have resulted in a pull request, had a destination for that existed. [1] A mistake, in my opinion. On Sat, Jun 25, 2022, at 03:30, The IESG wrote: > The IESG has received a request from the Adaptive DNS Discovery WG (add) to > consider the following document: - 'DHCP and Router Advertisement Options for > the Discovery of Network- > designated Resolvers (DNR)' > <draft-ietf-add-dnr-09.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@xxxxxxxx mailing lists by 2022-07-08. Exceptionally, comments may > be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > The document specifies new DHCP and IPv6 Router Advertisement options > to discover encrypted DNS resolvers (e.g., DNS-over-HTTPS, DNS-over- > TLS, DNS-over-QUIC). Particularly, it allows a host to learn an > authentication domain name together with a list of IP addresses and a > set of service parameters to reach such encrypted DNS resolvers. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-add-dnr/ > > The ADD WG has another document > https://datatracker.ietf.org/doc/draft-ietf-add-ddr/, which should > probably be reviewed at the same time. > > No IPR declarations have been submitted directly on this I-D. > > > > > > -- > Add mailing list > Add@xxxxxxxx > https://www.ietf.org/mailman/listinfo/add -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
