Document: draft-ietf-dnsop-structured-dns-error Title: Structured Error Data for Filtered DNS Reviewer: Petr Špaček Review result: On the Right Track
I have reviewed this document as part of the DNS directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational spects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. For more information about the DNS Directorate, please see https://wiki.ietf.org/en/group/dnsdir ## Summary - The 'idea' of the protocol seems clear. - The description of the protocol and data format in the document are very imprecise and suffer from multiple interoperability issues. I pictured how to implement the current text and, if I were actually doing a production implementation, I would have violated several MUSTs because some requirements are impractical for a real DNS deployment or simply don't define all possible cases. Feedback to sections is in order of appearance in the document, not in order of importance: > 2. Conventions and Definitions > "Requestor" refers to the side that sends a request. "Responder" refers to an authoritative, recursive resolver, or other DNS component that responds to questions. > The term "DNS server" refers to a DNS recursive resolver or a DNS forwarder that generates DNS structured error responses.This document defines 'Requestor' and 'Responder' (both terms make sense to me), but then the document goes on and mixes in undefined "client" (without DNS prefix), and an undefined "application", and confusingly defined "DNS server". I suggest getting this straight and going either all in to Requestor/Responder, or Client/Server. Mixing all terms is very confusing - I kept looking for semantic difference, and there does not seem to be any? Additionally, I suggest defining acronym SDE as "Structured DNS Error" into section 2 and not half-way through the document. >3. DNS Filtering Techniques and Their Limitations > 1. ... If the authority component of an HTTP(S) URL is blocked, There seems to be confusion about terms. https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Authority says that 'authority' is all of 'user:password@host'. I guess this section should use term 'host', preferably with reference to relevant URI spec. > 4. I-JSON in EXTRA-TEXT Field > DNS servers that are compliant with this specification and have received an indication that the client also supports this specification as per Section 5.1 send data in the EXTRA-TEXT field [RFC8914] encoded using the Internet JSON (I-JSON) message format [RFC7493]. > Note that [RFC7493] was based on [RFC7159], but [RFC7159] was replaced by [RFC8259]. I don't know how to interpret this note. What are the implications for an implementer? What's possibly even worse, the format seems underspecified/half-implicit in this section. RFC 7493 section 4.1 says: > An I-JSON message can be any JSON value. That implies it might as well might be an array like ["j", "go away", "c", "mailto:[email protected]";] I guess what the spec meant to say is something like {"j": "text", "c": "text"} but the section 4 does not define that. I guess it might be defined like "JSON object (see RFC 8259 section 4), with four members named ..." > This document defines the following JSON names: Nit: Maybe "member name"? I'm no JSON expert, but 'name' in document about naming system seems a bit loaded term. > optionally translate it for IT administrators. Nit: I suggest omitting "for IT administrators". I hope the software is allowed to translate it also for end user :-) > 5. Protocol Operation > 5.1. Client Generating Request > When generating a DNS query, a client that supports this specification MUST include the Structured DNS Error (SDE) option defined in Section 5.4. Interop problem: What if the client (requestor?) determines the responder breaks (e.g. times out, or returns garbage) when seeing a new EDNS option? It should not happen by EDNS spec, but reality is more complicated than that. I think SHOULD as a requirement should be sufficient here so implementations have some leeway for weird corner cases while being still compliant. > 5.2. Server Generating Response > If the query contained the SDE EDNS option (Section 5.1), and the DNS server returns an EDE indicating blocking or modification of the response, the DNS server MUST include additional detail in the EXTRA-TEXT field encoded as structured and machine-readable data. Underspecification/interop problem: What if the response EDE option with extra text does not fit into the response DNS message (say client buffer was ridiculously small or someone over-did the text messages)? Should it cause empty TC=1 response? Or can the EDE be omitted? In an implementation it usually easy enough to omit EDNS option if it does not fit at the very end of message rendering, but that would violate MUST and does not have clear instruction what to do. Personally I suggest SHOULD to simplify implementations, with a note it can be omitted if it does not fit without causing TC=1. > If the SDE option is not present, the DNS server MUST NOT include structured JSON data and MUST convey the EXTRA-TEXT field as human-readable text in accordance with [RFC8914]. Overspecification: What if an implementation does not produce humand-readable version? Does that mean it MUST NOT give back any information at all? Again, I suggest SHOULD. > Because the DNS client explicitly signals support for structured error information using the SDE option (Section 5.1), and because the EDE option is carried in the non-cached OPT pseudo-RR (Section 6.2.1 of [RFC6891]), the DNS server can tailor its filtered response to the capabilities of the client. That's a very misleading statement. Perhaps the text assumes the stub does not cache, perhaps it assumes single-level resolution hierarchy, or perhaps it is missing a definition 'client'... In any case, a forged answer might get cached if it has non-zero TTL. And many implementations have lower cap on TTL anyway because it is too easy to abuse. This makes the whole idea of tailoring per client half broken. If I first use "curl" from console, the NXDOMAIN for a blocked domain might get cached in stub's local cache. A subsequent web visit to the same domain from the same machine will get NXDOMAIN without the EDE, but it is still the same NXDOMAIN. If there is upstream cache, the same happens e.g. for a whole home (e.g. if I put my home router between client end devices and ISP's resolver). I don't know how to fix the text, but maybe just removing this paragraph would suffice? I don't think tailoring per client (whatever that is ...) is goal of this spec. > 5.3. Client Processing Response > 1. If the DNS response is not received over an encrypted DNS channel, the requestor MUST NOT act upon data in the EXTRA-TEXT field, as there is no mechanism to verify the integrity of such data and it is vulnerable to modification by an on-path attacker. This assumption is factually incorrect. As stated in RFC 8914 section 6, there's multiple ways to ensure message integrity. E.g. TSIG or SIG(0) protocols provide integrity protection for DNS message exchange without full transport encryption. Even worse, 'encryption' itself might not be sufficient because encryption generally does not guarantee non-malleability. The client always has better local knowledge than we can have 'on paper', so I suggest leave this determination for implementations without over-specifying it. Perhaps generic phrasing like this might be better: "If integrity of the DNS response is not guaranteed, ..." > 7. If a Contact URI in the "c" field uses a scheme not registered in the Section 11.3 registry, those URIs are discarded. Contact URIs using registered schemes can be processed. Nit: Perhaps I'm being too pedantic, but I would start the last sentence with 'Remaining contact URIs ...' (also the paragraph might need grammar correction?) > 7.1. Extended DNS Error Code TBA1 - Blocked by Upstream DNS Server Underspecification: It could use reference to 5.3 for integrity checking etc. There are CPEs which offer DoT to end devices but speak to their own upstream in ridiculous ways. ("There can't be attackers on our DOCIS network, we don't need expensive authentication here!") > 8. If the DNS client has enabled the opportunistic privacy profile for DoT (Section 5 of [RFC8310]) and the identity of the DNS server cannot be verified, Same comment as for section 5.3. I suggest making this technology neutral and focusing on properties, not means to get them. Something like: If the DNS client cannot verify the identity of the DNS server, ... > 9. In opportunistic discovery [RFC9462], where only the IP address of the DNS server is validated and the server identity is not authenticated, ... Same here. Please make it technology neutral. > 10. If a DNS client has enabled strict privacy profile (Section 5 of [RFC8310]) for DoT ...Same here. I'm sure we already have more technologies for authenticated channels to DNS responders than just DoT. > Note that the strict and opportunistic privacy profiles as defined in [RFC8310] only apply to DoT; there has been no such distinction made for DoH. While that's true, I find it irrelevant for this draft. Another RFC might be published tomorrow which defines profiles for DoH or DoQ and then this document would have to get update to accommodate that. Again, focus on properties would be more generic and future proof. > 7.1. Extended DNS Error Code TBA1 - Blocked by Upstream DNS Server > the EXTRA-TEXT field may be forwarded to the DNS client. Nit: Perhaps use MAY here? Not that it would change much. > 8. Examples > An example showing the nameserver at 'ns.example.net' that filtered a DNS "A" record query for 'example.org' is provided in Figure 1. Nit: Name 'ns.example.net' seems superfluous. I spent some time looking for it in the JSON and could not find it (which is okay), so I suggest to remove it. > "sips:[email protected]" Misleading example: I think this should have been example.net (reference to the filtering provider, not the blocked party). > 10.1. Authentication and Confidentiality This too should talk about properties (integrity protection), not means (encryption). IMO the statement about altering DNS protocol processing is not applicable to this draft anyway. SDE data does not change what the DNS layer reacts to responses in any way. It is an information for the upper layers. I would much rather see this reference removed because it is misleading and someone might get an idea to change what DNS resolver does based on EDE/SDE (if it came with integrity protection), which is prohibited for good reasons (e.g. cache coherency). -- Petr Špaček _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
