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

Commentary: ? 
 This probably fell through the cracks when was closed . The current design of the GET - based request uses two fields that work in tandem . carries a content type , carries the query . This is suboptimal from a performance perspective when a new request format is developed , which would effectively discourage adoption of new formats ( though most likely it will just prolong the lifetime of the baseline format ) . A query in the form with an implicit content type would be ideal . New formats for requests could do this : . POST requests ca n't benefit from this sort of approach . Not sure what I think about that . 
 My question is : does this also extend to multi - parameter query types in the future , e.g. ? 
 Yes , I am for having query types yes ! My pre - doh thing was accounting for name+type to allow for that granularity , for example MX resolution ( looking outside web - only context ) Other bits are welcome , recursion for example . 
 yes . 
 I am warming up to this . 
 This still seems silly to me for wireformat because if you can decode the answer , you can encode the query . If someone comes up with a JSON response encoding , the query type will be trivial to describe . what other use cases are you thinking of ? 
 The notion would be to create performance incentives for deploying new media types .. you 're right that for it to work you also need to support the old wireformat type so the new type needs to have an advantage other than " easier " . Is that not a possibility - will wireformat always be the most expressive ? 
 How could the wire format not be the most expressive ? DNS does n't have an analog of HTTP headers : it 's always just a message body . 
 tl;dr : reopen please . If you subscribe to the notion that wire format is all you ever need , then we 're done already . Just close the door on that possibility and remove . That would be fine for web+JS cases , because all the ugliness of the wire format can be wrapped with an ergonomic API . On the other hand , you might believe there to be value in formats that can express queries in a less - obtuse format . After all , you ca n't slap every problem with a JSL until it goes away . For instance , replacing a ' . ' with a count is pretty onerous in some clients . After considering this some more , I do n't think that you want to manage this by overloading a request with multiple query types . That might sound like a good idea , but it has complications in implementation ( what if the two queries disagree , how do you ensure cachability , etc .... ) . I really want to consider the interaction with discovery , without actually defining a discovery method . Say that you invent a new scheme that includes the combination of multiple QNAMEs and QTYPEs in the following fashion : . Rather than put that query syntax on the same base URL , you would instead configure clients with a discovery document that lists different query modes : Yes , risks straying into territory , but I do n't think that you need to actually specify discovery . Instead , you can instead structure configuration / discovery differently . That would enable that sort of discovery if someone wanted to go there , but it would n't force it on anyone . that this document has precisely one query syntax for GET that syntax with a single variable input ( drop ) and use a URI template to define the placement of that parameter that an alternative query syntax might be supported , but that the syntax would use a different endpoint and URI template and so would require separate configuration That does n't invalidate the current query format , it only changes the configuration . Servers can provide a URI template for their current syntax ( e.g. , would describe the endpoint that is also usable by clients that use configuration from earlier draft versions ) . 
 I 'm a bit torn here . The proposed architecture is fine . My gut also says that its a layer of indirection that wo n't be used in anyway that is more meaningful than what is defined .. and adds it complexity to understanding what is going on which is definitely an anti - goal . your 3 point definition is actually on the side of " simple enough " for me , though I 'm not positive we can write it down in a way that does n't create a lot of questions . I 've made a PR with what works for me but I 'm hesitant to go much further . let me know what you think . 
 I have mixed feelings about changing the wireformat so late , but think this is probably the best way to go .
Paragraph (version A):
To make a DNS API query a DNS API client encodes a single DNS query
into an HTTP request using either the HTTP GET or POST method and the
other requirements of this section.  The DNS API server defines the
URI used by the request.  Configuration and discovery of the URI is
done out of band from this protocol.
Paragraph (version A):
DNS API servers MUST implement both POST and GET methods.
Paragraph (version A):
When using the GET method the URI path MUST contain a query parameter
name-value pair QUERYPARAMETER with the name of "ct" and a value
indicating the media-format used for the dns parameter.  The value
may either be an explicit media type (e.g., "ct=application/dns-
udpwireformat&dns=...") or it may be empty.  An empty value indicates
the default application/dns-udpwireformat type (e.g., "ct&dns=...").
Paragraph (version A):
When using the GET method the URI path MUST contain a query parameter
with the name of "dns".  The value of the parameter is the content of
the request potentially encoded with base64url RFC4648.
Specifications that define media types for use with DOH, such as DNS
Wire Format dnswire of this document, MUST indicate if the dns
parameter uses base64url encoding.
Paragraph (version B):
A DNS API client encodes a single DNS query into an HTTP request
using either the HTTP GET or POST method and the other requirements
of this section.  The DNS API server defines the URI used by the
request through the use of a URI Template RFC6570.  Configuration and
discovery of the URI Template is done out of band from this protocol.
Paragraph (version B):
The URI template defined in this document is processed without any
variables for requests using POST, and with the single variable "dns"
for requests using GET.  The value of the dns parameter is the
content of the request (as described in dnswire), encoded with
base64url RFC4648.
Paragraph (version B):
Future specifications for new media types MUST define the variables
used for URI Template processing with this protocol.
Paragraph (version B):
DNS API servers MUST implement both the POST and GET methods.
Paragraph (version A):
When using the GET method, the data payload MUST be encoded with
base64url RFC4648 and then placed as a name value pair in the query
portion of the URI with name "dns".  Padding characters for base64url
MUST NOT be included.
Paragraph (version B):
When using the GET method, the data payload MUST be encoded with
base64url RFC4648 and then provided as a variable named "dns" to the
URI Template expansion.  Padding characters for base64url MUST NOT be
included.
Paragraph (version A):
These examples use a DNS API service located at
https://dnsserver.example.net/dns-query to resolve the IN A records.
Paragraph (version B):
These examples use a DNS API service with a URI Template of
"https://dnsserver.example.net/dns-query{?dns}" to resolve IN A
records.