[DNSOP] 答复: 答复: Call for Adoption: draft-song-atr-large-resp

[Davey Song(宋林健) <[e-mail]>]

Hi Brian, 

Thanks for your questions. Reply inline

>(1) Has your testing revealed *where* the IPv6 fragmentation is occurring? IIRC, IPv6 requires the originating host to do so. And originating UDP packet size will be the smaller of the authority servers' configs and the EDNS bufsize on the request.

IPv6 fragmentation is done by the end host which is specified in in RFC8200. The difference of IPv4 and IPv6 fragmentation is comprehensively introduced in draft-ietf-intarea-frag-fragile-05.  EDNS0 bufsize initialized to 4096 octets has no meaning for large UDP DNS response. Because if a IPv6 packets size larger than 1500 will be fragmented by the Ethernet interface. AFAIK, I''m not sure there is a configuration on authority severs on the size of UDP packets size. I think you refer to the the size of the DNS message.

>(2) Have you experimented with setting EDNS0 UDP bufsize to the *actual max size* that IPv6 allows *without fragmenting* (or MTU?), and what happens when you do that? (Actual MTU may vary topologically, YMMV, etc.)

It require resolvers' change to set EDNS0 bufsize below a certain number. Usually the authority server will work around it  as stated in the ATR draft.

" To avoid that issue, some  authoritative servers may adopt a policy 
   ignoring the UDP payload size in EDNS0 extension and always 
   truncating the response when the response size is large than a 
   expected one."

It is introduced that some root operator did this during KSK rollover. (https://blog.apnic.net/2016/11/15/scoring-dns-root-server-system ) 

Because some end users may be behind a resolvers which is not TCP-capable(17% according to APNIC measurement). That is one background that ATR is proposed:

 "ATR will helpful for resolver without TCP capacity, because the resolver
   still has a fair chance to receive the large response. "

I noticed there is a typo in above sentence in 02-version in which the txt is ""ATR will helpful for resolver with TCP capacity" .

>My suspicion is that the better approach for resolvers might actually be to do their IPv6 stuff "better", for some value of "better", in a way that does not require DNS protocol changes (or changes to transport specs like UDP or IPv6).
Or maybe we could add a new edns0 ip6-bufsize option in future so v4 vs v6 limits can be separated (and thus standardize (and kind of simplify) resolver and auth server configs).

It is a choice to ask resolver or server to  adopt that change which  is in the solution category  of Tony Finch.  I think both work and both with incentive to change. The difference is resolver's change take long time (installed base).   And the server's change will efficient in a timely manner.

However, ATR actually did not necessary require DNS protocol to change  or more specifically the change to the running authoritative server. Akira KATO once suggested me that ATR can be implemented as a on-path fix independent of DNS server. For example, use a hack in iptable or a separated device monitoring the DNS response size on the path and generate an additional truncated response if the size beyond a certain number.

Davey