Original text:
This document defines a specific protocol for sending DNS RFC1035 queries and getting DNS responses over modern versions of HTTP RFC7540 using https:// (and therefore TLS RFC5246 security for <del> integrity and confidentiality). </del>  The described approach is more than a tunnel over HTTP.  It establishes default media formatting types for requests and responses DNS API servers SHOULD use this well-known path to help contextualize DNS Query requests that use server push RFC7540. <del> A DNS API Client encodes the DNS query into the HTTP request using either the HTTP GET or POST methods. </del>  When using the POST method the DNS query is included as the message body of the HTTP request and the Content-Type request header Responses may be returned in a different temporal order than requests were made using the protocols native multi-streaming functionality. <del> A DNS response may contain a set of DNS Resource Records each with its own Time To Live (TTL) freshness information.  The freshness lifetime (RFC7234 Section 4.2) of the HTTP response should be coordinated with the Resource Record bearing the smallest TTL in the response.  The freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The response freshness lifetime MUST NOT be greater than that indicated by the DNS Record with the smallest TTL in the response. </del>  A DNS API Client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic

Reviewer comments:
… issue
It is not stated crystal clear in the -01 draft if there's only one DNS packet per HTTP request or if it is allowed to send more than one. Some wordings (like ) suggest a single packet. I think it would benefit the document to be more explicit on this detail.
good point - it is meant to be one, otherwise blocking and reordering (which is resolved at the intra-request http level) would be a problem. we'll add text.

Revised text:
This document defines a specific protocol for sending DNS RFC1035 queries and getting DNS responses over modern versions of HTTP RFC7540 using https:// (and therefore TLS RFC5246 security for  <ins> integrity and confidentiality).  Each DNS query-response pair is mapped into a HTTP request-response pair. </ins> The described approach is more than a tunnel over HTTP.  It establishes default media formatting types for requests and responses DNS API servers SHOULD use this well-known path to help contextualize DNS Query requests that use server push RFC7540.  <ins> A DNS API Client encodes a single DNS query into the HTTP request using either the HTTP GET or POST 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 Responses may be returned in a different temporal order than requests were made using the protocols native multi-streaming functionality.  <ins> The Answer section of a DNS response contains one or more RRsets. (RRsets are defined in RFC7719.)  According to RFC2181, each resource record in an RRset is supposed to have the Time To Live (TTL) freshness information.  Different RRsets in the Answer section can have different TTLs.  The HTTP response freshness lifetime (RFC7234 Section 4.2) should be coordinated with the Resource Record bearing the smallest TTL in the Answer section of the response.  The HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The response freshness lifetime MUST NOT be greater than that indicated by the DNS Record with the smallest TTL in the response. </ins> A DNS API Client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic