Draft: draft-ietf-doh-dns-over-https-latest

Commentary: I think that we should specify behaviour for truncated responses with the TC bit more clearly . Right now the text is a little vague . There seem to be three options : the generation of an HTTP error the forwarding of the truncated response allow either the use of truncated responses and recommend fallback to TCP if the DNS API server is just making DNS requests to another server I think that the draft current vacilates in the direction of 3 , but I tend to like 1 or 4 . Choosing 4 would n't be consistent with the dnsop DNS - over - HTTP draft using DOH though . 
 is the right answer , so the text should just be stronger about it . If DOH requires or , that means that the DNS server code will need to be heavily reworked to capture these from going out , which seems pointless . DOH clients can act like normal stubs : either they do or do n't know about truncation and  . 
 I agree - I do n't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error . can you do a pr to clarify ? 
 Will do .
Paragraph (version A):
The primary one is to prevent on-path network devices from
interfering with native DNS operations.  This interference includes,
but is not limited to, spoofing DNS responses, blocking DNS requests,
and tracking.  HTTP authentication and proxy friendliness are
expected to make this protocol function in some environments where
DNS directly on TLS (RFC7858) would not.
Paragraph (version B):
The primary use case is to prevent on-path network devices from
interfering with native DNS operations.  This interference includes,
but is not limited to, spoofing DNS responses, blocking DNS requests,
and tracking.  HTTP authentication and proxy friendliness are
expected to make this protocol function in some environments where
DNS directly on TLS (RFC7858) would not.
Paragraph (version A):
A secondary use case is web applications that want to access DNS
information.  Standardizing an HTTPS mechanism allows this to be done
in a way consistent with the cross-origin resource sharing CORS
security model of the web and also integrate the caching mechanisms
of DNS with those of HTTP.  These applications may be interested in
using a different media type than traditional clients.
Paragraph (version B):
A secondary use case is web applications that want to access DNS
information.  Standardizing an HTTPS mechanism allows this to be done
in a way consistent with the cross-origin resource sharing security
model of the web CORS and also integrate the caching mechanisms of
DNS with those of HTTP.  These applications may be interested in
using a different media type than traditional clients.
Paragraph (version A):
The protocol must use a secure transport that meets the
requirements for modern https://.
Paragraph (version B):
The protocol must use a secure transport that meets the
requirements for modern HTTPS.
Paragraph (version A):
The media type is "application/dns-udpwireformat".  The body is the
DNS on-the-wire format is defined in RFC1035.  The body MUST be
encoded with base64url RFC4648.  Padding characters for base64url
MUST NOT be included.
Paragraph (version B):
The media type is "application/dns-udpwireformat".  The body is the
DNS on-the-wire format is defined in RFC1035.
Paragraph (version B):
When using the GET method, the body MUST be encoded with base64url
RFC4648.  Padding characters for base64url MUST NOT be included.
Paragraph (version B):
When using the POST method, the body is not encoded.
Paragraph (version A):
At the time this is published, the response types are works in
progress.  The only known response type is "application/dns-
udpwireformat", but it is likely that at least one JSON-based
response format will be defined in the future.
Paragraph (version B):
At the time this is published, the response types are works in
progress.  The only known response type is "application/dns-
udpwireformat", but it is possible that at least one JSON-based
response format will be defined in the future.
Paragraph (version A):
In order to satisfy the security requirements of DNS over HTTPS, this
protocol MUST use HTTP/2 RFC7540 or its successors.  HTTP/2 enforces
a modern TLS profile necessary for achieving the security
requirements of this protocol.
Paragraph (version A):
The messages in classic UDP based DNS RFC1035 are inherently
unordered and have low overhead.  A competitive HTTP transport needs
to support reordering, priority, parallelism, and header compression.
For this additional reason, this protocol MUST use HTTP/2 RFC7540 or
its successors.
Paragraph (version B):
This protocol MUST use HTTP/2 RFC7540 or its successors in order to
satisfy the security requirements of DNS over HTTPS.  Further, the
messages in classic UDP based DNS RFC1035 are inherently unordered
and have low overhead.  A competitive HTTP transport needs to support
reordering, priority, parallelism, and header compression, all of
which are supported by HTTP/2 RFC7540 or its successors.
Paragraph (version A):
Running DNS over https:// relies on the security of the underlying
HTTP connection.  By requiring at least RFC7540 levels of support for
TLS this protocol expects to use current best practices for secure
transport.
Paragraph (version B):
Running DNS over HTTPS relies on the security of the underlying HTTP
connection.  By requiring at least RFC7540 levels of support for TLS,
this protocol expects to use current best practices for secure
transport.