Change:
The media type has been the subject of some debate. The above might be the best I've seen.

Discussion:
The DNS API client SHOULD include an HTTP "Accept" request header to indicate what type of content can be understood in response. Irrespective of the value of the Accept request header, the client <del> MUST be prepared to process "application/dns-udpwireformat" (See dnswire) responses but MAY also process any other type it receives. </del> <ins> MUST be prepared to process "message/dns" (as described in dnswire) responses but MAY also process any other type it receives. </ins> In order to maximize cache friendliness, DNS API clients using media <del> formats that include DNS ID, such as application/dns-udpwireformat, SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as application/dns-udpwireformat.  The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. </del> <ins> formats that include DNS ID, such as message/dns, SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as message/ dns.  The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. </ins> DNS API clients can use HTTP/2 padding and compression in the same way that other HTTP/2 clients use (or don't use) them.

"https://dnsserver.example.net/dns-query{?dns}" to resolve IN A records. <del> The requests are represented as application/dns-udpwirefomat typed bodies. </del> <ins> The requests are represented as message/dns typed bodies. </ins> The first example request uses GET to request www.example.com

At the time this is published, the response types are works in progress.  The only response type defined in this document is <del> "application/dns-udpwireformat", but it is possible that other response formats will be defined in the future. </del> <ins> "message/dns", but it is possible that other response formats will be defined in the future. </ins> <del> The DNS response for "application/dns-udpwireformat" in dnswire MAY have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </del> <ins> The DNS response for "message/dns" in dnswire MAY have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </ins> Each DNS request-response pair is matched to one HTTP exchange.  The responses may be processed and transported in any order using HTTP's

caching discusses the relationship between DNS and HTTP response caching. <del> A DNS API server MUST be able to process application/dns- udpwireformat request messages. </del> <ins> A DNS API server MUST be able to process message/dns request messages. </ins> A DNS API server SHOULD respond with HTTP status code 415 (Unsupported Media Type) upon receiving a media type it is unable to

5.4. In order to maximize interoperability, DNS API clients and DNS API <del> servers MUST support the "application/dns-udpwireformat" media type. Other media types MAY be used as defined by HTTP Content Negotiation (RFC7231 Section 3.4). </del> <ins> servers MUST support the "message/dns" media type.  Other media types MAY be used as defined by HTTP Content Negotiation (RFC7231 Section 3.4). </ins> 6.

DNS API clients using the DNS wire format MAY have one or more EDNS options RFC6891 in the request. <del> The media type is "application/dns-udpwireformat". </del> <ins> The media type is "message/dns". </ins> 7.