DNS seems like exactly the scenario where you would want http2 (or http1.1 pipelining but nobody supports that). You need to make a bunch of dns requests at once, and dont want to have to wait a roundtrip to make the next one.

ok multiple requests makes sense for keepalive (or just support a "batch" query, it's http already why adhere so tightly to the udp protocol)

http/1.0 w/keepalive is common (amazon s3 for example) perfectly suitable simple protocol for this

Keepalive is not really what you want here.

For this usecase you want to be able to send off multiple requests before recieving their responses (you want to prevent head of line blocking).

If anything, keep alive is probably counter productive. If that is your only option its better to just make separate connections.

makes sense but I still would prefer to solve that problem with "batch" semantics at a higher level rather than depend on the wire protocol to bend over backwards

The problem with batch semantics is you do have to know everything up front. You cant just do one request and then 20 ms later another.

For DNS this might come up in format parsing. E.g. in html, First you see <script> tag, fire off the DNS request for that, and go back to parsing. Before you get the DNS result you see an <img> tag for a different domain and want to fire off the DNS result for that. With a batch method you would have to wait until you have all the domain names before sending off the request (this might get more important if you are recieving the file you are patsing over the network and you dont know if the next packet containing the next part of the file is 1ms away or 2000ms).

clearly dns requests ought to be batched in this scenario, but we can imagine a smarter mechanism than http2 multiplexing to do it

the problem with relying on the wire protocol to streamline requests that should've been batched is that it lacks the context to do it well