Original text:
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 <del> updated by RFC6891, and this protocol does not put any limit on the size of DNS on-the-wire format payloads. </del>  When using the GET method, the data payload MUST be encoded with base64url RFC4648 and then placed as a name value pair in the query 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 <del> 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. </del>  10.

Reviewer comments:
Fixes to PR
It doesn't feel to me like "beyond what is already in {{RFC1035}}" really clarifies anything, and might just cause additional confusion, as it makes me as a reader wonder, "oh well what's in 1035? Guess I have to go searching..."
If you want to put the specific limit from RFC 1035 in, that's fine.
Well no, because I don't think there should be a limit. While DNS messages implicitly have a maximum size of 64k in DNS, there's no reason dns-udpwireformat in HTTPS can't surpass that.
NAME It would be an interoperability problem if a DNS API server handed a DNS API client a message that it could not handle. It is reasonable to assume that DNS API clients expect to parse messages as if they were DNS messages.
NAME This was sloppy on my part: I meant the addition to point to RFC 6891; now changed.
Right NAME but my point is that something like multiple AXFR messages re-assembled into one unit is still a DNS message even if it exceeds 64k. From a wire-format point of view, it parses exactly the same way.
NAME Really? Ugh. Gotta love this protocol. So, you would prefer that the text says "URL this protocol allows DNS-on-the-wire format payloads of any size"?
Yes, I would. Realistically almost everything is still going to be sub-10k, but I don't see an intrinsic need to limit it, especially with https channels routinely handling far larger responses.
I think David and I are now in agreement; NAME should consider accepting.

Revised text:
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  <ins> updated by RFC6891, and this protocol allows DNS on-the-wire format payloads of any size. </ins> When using the GET method, the data payload MUST be encoded with base64url RFC4648 and then placed as a name value pair in the query 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  <ins> the query 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. </ins> 10.