Skip to main content

DNS Resolver Information
draft-ietf-add-resolver-info-13

Note: This ballot was opened for revision 11 and is now closed.

Éric Vyncke
Yes
Erik Kline
No Objection
Comment (2024-03-30 for -12) Sent
# 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?
Gunter Van de Velde
No Objection
Comment (2024-03-29 for -12) Sent
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'?
Jim Guichard
No Objection
John Scudder
No Objection
Comment (2024-04-01 for -12) Not sent
I support Paul’s DISCUSS.
Murray Kucherawy
(was Discuss) No Objection
Comment (2024-04-04 for -12) Sent
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?
Orie Steele
No Objection
Comment (2024-04-01 for -12) Sent
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.
Roman Danyliw
No Objection
Comment (2024-04-03 for -12) Sent
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?
Warren Kumari
(was Discuss) No Objection
Comment (2024-04-26) Sent
Thank you for addressing my DISCUSS position; I have updated my Ballot to NoObj.
Zaheduzzaman Sarker
No Objection
Comment (2024-04-04 for -12) Not sent
Thanks for working of this specification, no objection from me regarding transport layer considerations.
Paul Wouters
(was Discuss) Abstain
Comment (2024-05-22) Sent
I have updated by ballot from DISCUSS to ABSTAIN.

The document still suffers from not specifying client security policies,
making the entire security basis incomplete, leaving my security questions
with "that is out of scope" answers.

One argument is that one could select or prefer resolvers offered
by the network based on EDE, but it seems unlikely the network would
supply different DNS resolvers, so this really becomes another case of
"preconfigured vs network assigned". Also, the EDE option support without
knowing the kind of filtering that is selected is not very meaningful.
(while kind is "censored" you don't know if this is censored for adult
content, political content, or just malware, so the option itself without
knowing the policy is not very useful.

From a security point of view, a DNS server conveying "I am going to
withhold DNS answers" cannot be distinguished from beneficial vs an
attack, and so this comes down again to "reputation" of the DNS servers.

Other options conveyed are also on a trust basis, and can 
therefor not really be used by DNS clients in a secure way without
pre-trust/pre-configuration.

The document (and discussion we had via email) seems to think this is a
tool for the client to choose between "preconfigured TRR DNS servers"
versus "network supplied ones", but I don't see how the network's
advertised (unverifiable) claims of how it will do DNS can ever be 
evaluated or trusted by the client. Really, "reputation" is another word
for "preconfigured non-network supplied DNS servers", which then defeats
the whole purpose of this document's protocol. And will lead to further
DNS centralization.