Change:
4. <del> 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. </del> <ins> 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. </ins> <del> DNS API servers MUST implement both POST and GET methods. </del> <ins> 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. Future specifications for new media types MUST define the variables used for URI Template processing with this protocol. DNS API servers MUST implement both the POST and GET methods. </ins> When using the POST method the DNS query is included as the message body of the HTTP request and the Content-Type request header indicates the media type of the message.  POST-ed requests are smaller than their GET equivalents. <del> 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=..."). 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. </del> Using the GET method is friendlier to many HTTP cache implementations.

Discussion:
NAME ?
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 can'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.
NAME 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. NAME 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 doesn'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 can'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 don'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 don'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 wouldn't force it on anyone. specify that this document has precisely one query syntax for GET specify that syntax with a single variable input (drop ) and use a URI template to define the placement of that parameter observe 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 doesn'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 won'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 doesn'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.