Re: [DNSOP] Fwd: I-D Action: draft-song-atr-large-resp-00.txt

[Paul Vixie <[e-mail]>]

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