On Tue, Apr 4, 2023 at 9:54 AM Scott Rose via Datatracker <noreply@xxxxxxxx> wrote:
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.
That's one option. The other options are (2) if you know you're not on a network with insecure devices behind a firewall or (3) if you apply port number restrictions that you believe are sufficient to prevent any confusion.
Is there any way to verify
this? It sounds like this behavior would need to be configured for individual
servers and not in general.
Yes: "do you trust this server not to try to attack other devices on your network?" is a question whose answer cannot be automated.
In Section 5, the text states: “Clients SHOULD NOT query for any HTTPS RRs…”
Maybe that should be a MUST NOT?
Sending an HTTPS query is useless but also harmless, so I think "MUST NOT" would be too strong.
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?
The text documents one reason: "if clients might learn about this DoH service through a different channel". If the client is provisioned with a complete DoH URI template, this draft doesn't apply, but the HTTPS record draft does.
I can also imagine cases where the HTTP client implementation used for DoH is extremely high-level, and performs its own HTTPS queries.
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?
This section is not limited to DoH; it applies to all transports. RFC 8484 assumes that the DoH URI template is provisioned securely, so this mitigation would not be relevant.
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.
"QNAME" is mentioned here to clarify that we are talking about how the stub's initial query is formed, not the owner name of the SVCB record (which could be different due to CNAMEs and SVCB AliasMode records).
Section 6: uses "stub resolution" but should be "recursive resolution".
I agree that "stub resolution" isn't quite standard terminology, but I'm not sure "recursive resolution" conveys the right idea here. I've changed the text to "e.g., querying a recursive resolver vs. an authoritative server".
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.
OK, I've adjusted this example to be more compact and legible. See https://github.com/ietf-wg-add/draft-ietf-add-svcb-dns/commit/4df349bf0d8bba8f1dcbbd3a5caf9d67128b55df
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
