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

Commentary: Related to 
 this is a strict improvement . let 's merge and we can adjust further if there is feedback 
 No limit ? Not even the UDP 64 k limit ? 
 I would delete the " over TCP " in " DNS API server was not able to retrieve a full answer for the query over TCP " The DoH server is supposed to do its best to get the fuil answer , it does not mean we force TCP . 
 Good catches . Will update with 
 I do n't see a compelling technical reason to set a limit . 
 Whether or not RFC 1035 has this limit , DOH should not . 
 The relevant text in RFC 1035 is : or UDP headers ) . Longer messages are truncated and the TC bit is set in the header . If the DOH protocol is referred to as " per RFC 1035 " then readers of the spec would be entitled to believe that the 512 byte limit applies unless explicitly documented otherwise . 
 Hello ! as quite a bunch of records are indeed 512 .... some companies set 1024~4096 as operational limit on forwarders and routers . Maybe it could be set in draft to 1024 , to avoid jumboframes at all in the picture ? Maybe  not have foreseen the increasing size of messaging we then experienced lately ( along with Add and Auth getting bigger for redundancy ) ? no doubts on it , people are creative about what they can put inside DNS : geo - informations in LOC type , or surf web within TXT records , PGP keys ... I can personally get along most of times with 50 - 100 bytes average packet size in a simple browsing session , but carrying DNSSEC or even just an SPF will make the use of TCP on DNS backend more and more and more exclusive ... I am not saying is any bad / good . We risk limiting the " native DNS " initial use of UDP ( which has probably grown after 1035 initial needs ) by reverting back to quite an " old " setting . I am not sure everyone today does truncate on exact 512 , I might be very wrong . Little higher limit can still be beneficial to transport , compression , stateless / stateful costs etc . By the way , one of today 's standing argument by Sir   , is indeed the present limit on the size of datagrams , just to make things funnier ! Making a parallel with the transport layer , we do not want to drive trough TCP - only world as we had also mentioned QUIC and others . Another parallel on semantics , we almost mention  just because comes after HTTP2 but nothing lower than 2 . So why shall we not leave that choice OPEN to implementors , to set the desired truncating threshold starting at 512 an up ? Are there references to present RFC on the topic to help reasoning or delegate the choice on this ? The truncate decision for an ANSWER having size threshold is taken only by server , client will accept and parse so no impact ? Can we try to elaborate on this ? Just brainstorming ... 
 Goodness no , not the least of which being because  transport issues are clearly out of scope for this work . 
 The truncate decision for an ANSWER having size threshold is taken only by server , client will accept and parse so no impact ? Can we try to elaborate on this ? The server may have gotten a truncated response from an an authoritative name server , so the client always need to expect an truncated response ( except in some local uses of DNS ) . YES , Seems like something that should be elaborated on . 
 Proposed fix at 
 .. we can reopen this issue if necessary 
 reopen to consider
Paragraph (version A):
The data payload is the DNS on-the-wire format defined in RFC1035.
The format is for DNS over UDP.  (Note that this is different than
the wire format used in RFC7858.
Paragraph (version B):
The data payload is the DNS on-the-wire format defined in RFC1035.
The format is for DNS over UDP.  Note that this is different than the
wire format used in RFC7858.  Also note that while RFC1035 says
"Messages carried by UDP are restricted to 512 bytes", that was later
updated by RFC6891, and this protocol does not put any limit on the
size of DNS on-the-wire format payloads.
Paragraph (version B):
If a DNS API server responds to a DNS API client with a DNS message
that has the TC (truncation) bit set in the header, that indicates
that the DNS API server was not able to retrieve a full answer for
the query over TCP and is providing the best answer it could get.
This protocol does not require that a DNS API server that cannot get
an untruncated answer send back such an answer; it can instead send
back an HTTP error to indicate that it cannot give a useful answer.