Change:
These examples use HTTP/2 style formatting from RFC7540. <del> These examples use a DNS API service located at https://dnsserver.example.net/dns-query to resolve the IN A records. </del> <ins> These examples use a DNS API service with a URI Template of "https://dnsserver.example.net/dns-query{?dns}" to resolve IN A records. </ins> The requests are represented as application/dns-udpwirefomat typed bodies.

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.