Reviewer: Scott Rose Review result: Ready with Issues Overall it is fine and does not change the DNS or DoH protocol or the SVCB RRType defined in another document. There is the dependence on the SVCB Internet-Draft advancing before this one, but that is not a DNS issue. In Section 4.2, it says clients SHOULD NOT support the “port” key unless the client trusts the server not to attempt an attack. Is there any way to verify this? It sounds like this behavior would need to be configured for individual servers and not in general. In Section 5, the text states: “Clients SHOULD NOT query for any HTTPS RRs…” Maybe that should be a MUST NOT? Is there a reason why a client would send a query for type HTTPS rather than SVCB? Like if the SVCB query returned a response saying the RRType does not exist? Section 8.1.2, the text says: “If an endpoint sends an invalid response to a DNS query, the client SHOULD NOT send more queries to that endpoint.” That refines what is in RFC 8484, which is rather open ended. I don’t know if this rises to the need for this document to update RFC 8484, since the text there implies retry or try another DoH server but RFC 8484 does not state that a client SHOULD NOT retry to the same server. Maybe just mention that this refines the behavior in RFC 8484 for SVCB aware clients? There are some small nits about terminology (RFC 8499) that can be addressed easily: Section 3: Uses QNAME to refer to hostname. QNAME is technically applies to queries and usually "owner name" is usually used to refer to the hostname portion of an RRset in a zone. Section 6: uses "stub resolution" but should be "recursive resolution". Section 7: The owner name doesn't need to be repeated for every RRset in the last example if they are all at the same name. No harm though. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
