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

Davey Song(宋林健) <ljsong@biigroup.cn> Sat, 26 January 2019 03:10 UTC

Return-Path: <ljsong@biigroup.cn>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0168F1310F4 for <dnsop@ietfa.amsl.com>; Fri, 25 Jan 2019 19:10:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.352
X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, INVALID_MSGID=0.568, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5runEU0yaN9h for <dnsop@ietfa.amsl.com>; Fri, 25 Jan 2019 19:10:53 -0800 (PST)
Received: from smtpbg320.qq.com (smtpbg320.qq.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178E61310F0 for <dnsop@ietf.org>; Fri, 25 Jan 2019 19:10:51 -0800 (PST)
X-QQ-mid: bizesmtp11t1548472239taqc01ca
Received: from sljpc (unknown []) by esmtp6.qq.com (ESMTP) with id ; Sat, 26 Jan 2019 11:10:38 +0800 (CST)
X-QQ-SSF: 00400000000000Q0ZLF0B00A0000000
X-QQ-FEAT: JUPa0usIjzyZLNhlwItcY8QpPYUIA/6QC8WOsvMbKKcZgxezTwFS/iZ4znxnW VsWLdxL+8rCF3svPYGe8wCBFivBNKC05M8bsTZl5gZntw8Bp5GtfGcW1znJH2ZRoN8VH72Q cAcQ0orgIBTKdG2xTx3lwzTcDf1+H6g4yjB2zbsxiVbJ56IW/vyi9jXhiUDYo1ALdIZsote PtDFlk0I1Vh3fQE+wV+zfbdaXvhCsYuH+hAJc/5Uz3vq2gpNdUNGJNGWEsg5Awath1QlAqS iTEXeTQLpM6+oK7bW06euS0LPskl2f5HAbX73pcIVwuuk7
X-QQ-GoodBg: 2
From: "Davey Song(宋林健)" <ljsong@biigroup.cn>
To: 'Brian Dickson' <brian.peter.dickson@gmail.com>
Cc: 'Peter van Dijk' <peter.van.dijk@powerdns.com>, dnsop@ietf.org, 'Ralf Weber' <dns@fl1ger.de>
References: <BCACF554-8BE6-49BC-B75A-BCED776F5189@NLnetLabs.nl> <4A75C4E3-F74F-46DB-9A8A-879C0BB79190@powerdns.com> <52CC68F4-231A-4002-A615-12F2F044342E@isc.org> <533234C8-A97C-4AA3-8395-0708909444B0@rfc1035.com> <595ae5ba-d92c-5d4d-d62b-293a343bf69b@nic.cz> <5c46d965.1c69fb81.5b50.dcd6SMTPIN_ADDED_BROKEN@mx.google.com> <CAH1iCiqHYqh_1vMJkQ5-qMxDatccv7hmLeUps8DwDRpXFY-XWA@mail.gmail.com>
In-Reply-To: <CAH1iCiqHYqh_1vMJkQ5-qMxDatccv7hmLeUps8DwDRpXFY-XWA@mail.gmail.com>
Date: Sat, 26 Jan 2019 11:10:46 +0800
Message-ID: <00b001d4b524$bbf67b90$33e372b0$@cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: zh-cn
Thread-Index: AdS0I2AdkhhsONX6QTqHiZP1kKEw1AA+jHfg
Feedback-ID: bizesmtp:biigroup.cn:qybgweb:qybgweb1
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6E0-iJJxmYiAbCp1bcVfzDe8MOw>
Subject: [DNSOP] 答复: 答复: Call for Adoption: draft-song-atr-large-resp
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Jan 2019 03:10:58 -0000

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.