Davey Song wrote:
Hi folks, I just submit a draft dealing with issue of large DNS response especially in IPv6. [Comments] are welcome.
in the original EDNS I-D, the following text was present:
.IP MD ``More data'' flag. Valid only in TCP streams where message ordering and reliability are guaranteed. This flag indicates that the current message is not the complete request or response, and should be aggregated with the following message(s) before being considered complete. Such messages are called ``segmented.'' It is an error for the RCODE (including the EXTENDED-RCODE), AA flag, or DNS Message ID to differ among segments of a segmented message. It is an error for TC to be set on any message of a segmented message. Any given RR must fit completely within a message, and all messages will both begin and end on RR boundaries. Each section in a multipart message must appear in normal message order, and each section must be complete before later sections are added. All segments of a message must be transmitted contiguously, without interleaving of other messages.
the MD extended flag was removed due to its complexity in 1998 or so, and while i planned to re-introduce it in EDNS2, however, EDNS1 never made it out the door, so it was lost.
i did not make it possible to use it in UDP because of packet reordering and because of microburst problems -- which is to say, TCP delivers things in the order they were transmitted, and attempts to avoid overloading the path bandwidth-delay-product (BDP) in ways that cause congestive loss.
by implication, MD was intended to allow messages larger than 64K octets, even while requiring individual RRsets to remain atomic within 64K octet message segments. i realize that this is not the same goal you're pursuing with your draft, but this history may help you.
If chairs think it is in the scope of dnsop wg and encourage us to discuss it in this mailing list, I can submit it as a draft listed in dnsop wg.
my own view is that changing the DNS protocol to work around middle boxes is a losing game. if measurement shows that a large fraction of today's deployed IPv6 edge does not accept extension headers or ICMP, and if that means fragmentation will not work toward those edges, then our proper response is to change all DNS servers to send extension headers on every IPv6 response. force the failures to occur as close as possible to, and as early as possible after, they are caused.
separately, we should be working on TFO deployment, and DNS-over-QUIC. we need a vision, rather than a long series of easy complications.
-- P Vixie _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
