Ballot for draft-ietf-add-resolver-info
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
In general, I am not sure what this document wants to achieve. It states: DNS clients can use the resolver information to identify the capabilities of DNS resolvers. It then defines qnamein, exterr and infourl. The latter should not be used by the DNS client. So what should a DNS client do with the information that QNAME Minimalization is used, or that the DNS resolver code base supports EDE (but EDE might not be in use anyway). What behavioral change is expected from "DNS Clients" that are targeted by this document? If no change in behavior is expected, why should a DNS client support and perform this query? Furthermore, none of the answers can be trusted without some form of enterprise provisioning. Why inform the resolver is using qname minimalization? What makes this optional special, compared to other things like 0x20 support, the infra-rr hardering support, DNSSEC support? Why is it not providing keywords for DoH or DoT or DoQ support? Why not show what normally would be in the CHAOS version.bind data like dns implementation name and version? If the DNS client would behave differently based on the setting of qnamein, what would it be and how would it determine the security of the returned value (eg why wouldn't the target DNS resolver just lie to cause the DNS Client to do whatever behavior it does differently when it sees qnamein?). If this is meant only for administrators doing DNS diagnostics, why not ONLY return an infourl and have qnamein and exterr contained in infourl, or even more keywords based on a DNS yang model list of keywords? What is the DNS Client expected to do with the exterr values returned? What does "supported" mean, eg versus "configured". What different DNS Client behavior is expected based on this value? The "infourl" seems a bit risky. While the documents tries to limit the impact, I don't understand its approach. Why insist on "https" ? It's a public API that anyone that can query the nameserver can presumably retrieve anyway? That is, I assume such a infourl would not require HTTP level authentication. I don't see why it should be forced over https. Why is the information presented a text/html and not plaintext ? Or json? Or yang? This would avoid various risks of exposure to the enduser which are not meant to consume this anyway according to the document. The URL SHOULD be treated only as diagnostic Why is that not the case for qnamein and exterr? Why is that not a MUST? A DNS client MAY choose to display the URL to the end user Why is this not a MUST NOT ? if and only if the encrypted resolver has sufficient reputation This is not something an implementer can write code for reading the RFC. It further more pushes centralization towards "reputable DNS resolvers". How does the DNS client get updates about the reputable status of a DNS resolver? I feel just like "captive portals", that this can/will be misused and be used for advertisement or other non-DNS purposes. Forcing this to be text/plain or json/yang would make this "less consumable" to endusers and thus make them more safe against abuse. In Section 7 it states: 1. Establish an authenticated secure connection to the DNS resolver. [...] It is important to note that, of these two measures, only the first one can apply to queries for 'resolver.arpa' How can anyone establish a secure authenticated connection to "resolver.arpa"? If they do, either the client has to authenticate it is the real "resolver.arpa" but then its contents cannot apply (it's something on the internet, not local) or it authenticates to "something else", in which case how can that be secure, or if it is secure but populated with information that validates "starbucks", how meaningful is "authentication" in this context? The section contains another set of "weasel wording" on determining reputation of the resolver that is not really implementable in code.
# Internet AD comments for draft-ietf-add-resolver-info-12 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S5 * For "exterr", does this mean that a server that supports RFC 8914 in full should reply with: "exterr=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24" Without some attempt at summarizing this (e.g. "=0-24") there is a penalty to supporting more error codes over time. Of course, summarization schemes do introduce their own parsing complexity. :-/ This is obviously a minor concern/comment, though. (No action needed.) ### S7 * It occurs to me that an encrypted resolver might return correct information for itself but this information could still be incorrect for other resolvers that are part of a shared serving infrastructure (i.e. those servers comprising the service behind a resolver VIP). It might be worth noting some operational guidance like all resolvers in a group SHOULD have consistent RESINFO?
Many thanks for the document. It was easy to read and process and well written. Please use or ignore the below observations at your desire. The abstract could be made more precise: [existing] 13 This document specifies a method for DNS resolvers to publish 14 information about themselves. DNS clients can use the resolver 15 information to identify the capabilities of DNS resolvers. How such 16 an information is then used by DNS clients is out of the scope of 17 this document. [proposed] This document specifies a method for DNS resolvers to publish information about themselves. DNS clients can use the resolver information to identify the capabilities of DNS resolvers. How DNS clients use such information is beyond the scope of this document. other observations and clarifications: 101 Retrieved information can be used to feed the server selection 102 procedure. However, that selection procedure is out of the scope of 103 this document. Can the retrieved only be used for server selection, or is this merely an example use-case? This could maybe be clarified? 133 Section 5. If the resolver understands the RESINFO RR type, the 134 RRSet MUST have exactly one record. RESINFO is a property of the What if there is none or more as one? is there an exception procedure? 156 The resolver information record uses the same format as DNS TXT 157 records. As a reminder, the format rules for TXT records are defined 158 in the base DNS specification (Section 3.3.14 of [RFC1035]) and The words 'As a reminder' sound pedantic. Maybe they can be removed without changing the validity of the information. 172 Keys MUST either be defined in the IANA registry (Section 8.2) or 173 begin with the substring "temp-" for names defined for local use 174 only. Maybe additional clarification on what keys is being referenced to? It is reasonably clear from the previous context, but being more explicit, especially with a training MUST statement will reduce confusion. 180 qnamemin: If the DNS resolver supports QNAME minimisation [RFC9156] 181 to improve DNS privacy, the key is present. Note that, as per the 182 rules for the keys defined in Section 6.4 of [RFC6763], if there 183 is no '=' in a key, then it is a boolean attribute, simply 184 identified as being present, with no value. I am unsure what 'the key is present' exactly means? does this need BCP14 normative language? note that 'minimisation' is British English, while 'minimization' is American English 188 exterr: If the DNS resolver supports extended DNS errors (EDE) 189 option [RFC8914] to return additional information about the cause 190 of DNS errors, the value of this key lists the possible extended 191 DNS error codes that can be returned by this DNS resolver. When 192 multiple values are present, these values MUST be comma-separated. what if the same value is added multiple times? or if there are 100000 values inserted? what if illegal values are inserted? 196 infourl: An URL that points to the generic unstructured resolver 197 information (e.g., DoH APIs supported, possible HTTP status codes 198 returned by the DoH server, or how to report a problem) for 199 troubleshooting purposes. The server that exposes such 200 information is called "resolver information server". Is it possible that the URL is not complete, invalid or overly long? how to handle exception scenarios when the URL is illegal or incorrect? 202 The resolver information server MUST support the content-type 203 'text/html'. The DNS client MUST reject the URL if the scheme is 204 not "https". The URL SHOULD be treated only as diagnostic 205 information for IT staff. It is not intended for end user 206 consumption as the URL can possibly provide misleading 207 information. A DNS client MAY choose to display the URL to the 208 end user, if and only if the encrypted resolver has sufficient 209 reputation, according to some local policy (e.g., user 210 configuration, administrative configuration, or a built-in list of 211 respectable resolvers). The wording 'if and only if' seems a difficult way to use 'when'?
I support Paul’s DISCUSS.
Thanks for the quick IANA Considerations fix, clearing my DISCUSS. I've left the rest of my original comment here: In Section 5: "Note that, as per the rules for the keys defined in Section 6.4 of [RFC6763], if there is no '=' in a key, then it is a boolean attribute, simply identified as being present, with no value." I don't know what it means for a Boolean value to be "present". Do you mean that its presence in the record indicates the value is "true"? The last few sentences of the description of "infourl" seem awfully hand-wavy. You might want to simplify this by saying it's a URI referring to content that may be useful for debugging, and just leave it at that. And I don't understand the SHOULD here; what's the alternative you're trying to discourage? Once the list of registered RESINFO keywords is big enough, it's possible to pack enough of them into one of these records to cause truncation and a switch to TCP. Should we be encouraging registration of shorter names wherever possible to forestall this?
Thanks to Arnt Gulbrandsen for the ARTART Review. Thanks to Tommy Jensen for the shepherd write up. I support Paul's Discuss, and agree with many of his comments. In particular, Arnt mentioned in his review similar concerns regarding Section 7. In Section 5, is misleading IT staff a security issue? Its not clear how to protect end users in this section. Consider MUST NOT display the URL to end users. If you retain the recommendation to use text/html consider adding some guidance regarding web app sec, scripts etc... This might better help explain your requirement to use HTTPS? Prefer to see some concrete examples of acceptable strategies for managing reputation.
Thank you to Mallory Knodel for the GENART review. I support the DISCUSS positions of Paul Wouters and Warren Kumari. Both of these positions already capture the majority of the feedback I would have provided. I would emphasis the point made my Warren that additional text on the use case and deployment environment might help illuminate the design described in this document. ** Section 5. Infourl The resolver information server MUST support the content-type 'text/html'. ... The URL SHOULD be treated only as diagnostic information for IT staff. -- Does this text imply that resolver information can be sent back in some other content-type as long as the resolved information server supports ‘text/html’? As constructed, this text doesn’t appear to restrict the content-type of the information. -- Under what circumstances would the IT staff use this for non-diagnostic information?
Thank you for addressing my DISCUSS position; I have updated my Ballot to NoObj.
Thanks for working of this specification, no objection from me regarding transport layer considerations.