Draft: draft-ietf-doh-dns-over-https-latest

Commentary: Sorry , I may be late to this party ... I 'm not keen on the use of and when discussing which DNS servers a client should choose / trust - those terms are used when discussing technical implementation details , and choosing whether to trust a DNS server is n't that - per RFC2119 : Additionally , without providing an explicit means of determining how and whether a DNS server is trusted , we 're not really helping - we 're just saying that the client MUST make that determination , with no further details . I 'd be fine with replacing them with lower - case non - normative and/or , e.g. : the HTTP request URI is a trusted service for the DOH query ; in other words , a DNS API client should only use a DNS API server that is determined to be trustworthy . because the client was told to use the DNS API server by an untrusted party . not recognized by the DNS API client as trusted DNS API servers . As such , use of untrusted servers is out of scope of this document . 
 its actually not uncommon to leave the ultimate decision about trust out of a protocol definition while still saying that the protocol needs to make such a distinction . HTTPS is the most obvious example - in the end there are not rules about what certificate root to honor , how to annotate it , etc .. those are decisions implementations make . 
 Yes , but if a client chooses to make bad decisions and trust a DNS server that they have n't ' vetted ' , then are they actually in contravention of this specification ? Actually , I guess it 's really my second point that 's in some ways the most important - typically a MUST / REQUIRED / SHALL specifies an action to take and there will be some obvious consequences for not taking that action ( an error thrown ) . In this case , we 're saying " You MUST check that the DNS server you want to connect to is trustworthy " without saying how they should do that . And since there will be no error message from an untrustworthy DNS server , how would they know ? It feels like we 're taking things that outside of the spec ( whether / how to trust a DNS server ) and making it part of the spec ... 
 MUST has many purposes . One of them is to avoid confusion . There 's been a lot of concern during the DOH process that DOH clients will spray queries to random webservers , or otherwise violate security common sense . This " requirement " is intended to respond to those concerns , and clarify that we are not proposing to do anything reckless . 
 Well OK then . I 'm still not entirely happy , but if the consensus is to leave it as it is , I 'm not going to push it . 
 I have moved the discussion to the mailing list :
Paragraph (version B):
Before using a DNS API server for DNS resolution, the client MUST
establish that the HTTP request URI is a trusted service for the DOH
query, in other words, a DNS API client MUST only use a DNS API
server that is configured as trustworthy.
Paragraph (version B):
A client MUST NOT use a DNS API server simply because it was
discovered, or because the client was told to use the DNS API server
by an untrusted party.
Paragraph (version B):
This specification does not extend DNS resolution privileges to URIs
that are not recognized by the DNS API client as trusted DNS API
servers.  As such, use of untrusted servers is out of scope of this
document.
Paragraph (version A):
Before using DOH response data for DNS resolution, the client MUST
establish that the HTTP request URI is authorized for the DOH query.
For HTTP requests initiated by the DNS API client this authorization
is implicit in the selection of URI.  For HTTP server push (RFC7540
Section 8.2) extra care must be taken to ensure that the pushed URI
is one that the client would have directed the same query to if the
client had initiated the request.  This specification does not extend
DNS resolution privileges to URIs that are not recognized by the
client as authorized DNS API servers.
Paragraph (version B):
Before using DOH response data for DNS resolution, the client MUST
establish that the HTTP request URI may be used for the DOH query.
For HTTP requests initiated by the DNS API client this is implicit in
the selection of URI.  For HTTP server push (RFC7540 Section 8.2)
extra care must be taken to ensure that the pushed URI is one that
the client would have directed the same query to if the client had
initiated the request.
Paragraph (version A):
In the absence of information about the authenticity of responses,
such as DNSSEC, a DNS API server can give a client invalid data in
responses.  A client MUST NOT authorize arbitrary DNS API servers.
Instead, a client MUST specifically authorize DNS API servers using
mechanisms such as explicit configuration.
Paragraph (version B):
In the absence of information about the authenticity of responses,
such as DNSSEC, a DNS API server can give a client invalid data in
responses.  A client MUST NOT use arbitrary DNS API servers.
Instead, a client MUST only use DNS API servers specified using
mechanisms such as explicit configuration.  This does not guarantee
protection against invalid data but reduces the risk.