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

Paul Vixie <paul@redbarn.org> Thu, 21 September 2017 04:50 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1DF1342C2 for <dnsop@ietfa.amsl.com>; Wed, 20 Sep 2017 21:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61WziwjRHOP5 for <dnsop@ietfa.amsl.com>; Wed, 20 Sep 2017 21:50:25 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF54C124239 for <dnsop@ietf.org>; Wed, 20 Sep 2017 21:50:25 -0700 (PDT)
Received: from [10.0.0.23] (pool-173-79-98-3.washdc.fios.verizon.net [173.79.98.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id D1EC161FA2; Thu, 21 Sep 2017 04:50:24 +0000 (UTC)
Message-ID: <59C34510.4080705@redbarn.org>
Date: Wed, 20 Sep 2017 21:50:24 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.19 (Windows/20170908)
MIME-Version: 1.0
To: "\"Davey Song(宋林健)\"" <ljsong@biigroup.cn>
CC: 'william manning' <chinese.apricot@gmail.com>, 'Davey Song' <songlinjian@gmail.com>, 'dnsop' <dnsop@ietf.org>
References: <150509601027.9852.16967877638602485585@ietfa.amsl.com> <CAAObRXJ6wJGCXkbKVkNmQCJ8NccBT63A8-9-LiRVZCFsDicchw@mail.gmail.com> <CACfw2hhaKTyfJfjQ5-_kfqiHX1oX+9P6mUWD06B87y_2ysdztA@mail.gmail.com> <045b01d33288$d3fadad0$7bf09070$@cn>+5DE3FF4CB4E4721A
In-Reply-To: <045b01d33288$d3fadad0$7bf09070$@cn>+5DE3FF4CB4E4721A
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xpzsTO2_6l9hdOCq3x2szklvKA8>
Subject: Re: [DNSOP] 答复: Fwd: I-D Action: draft-song-atr-large-resp-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 21 Sep 2017 04:50:27 -0000


Davey Song(宋林健) wrote:
> Thank you.
>
> The large DNS response in IPv6 is a real problem. ATR is one option
> to adopted in authoritative  server alone. If someone or party have
> more influence on both resolver and authoritative side (cloud and app
> provider who can choose their own DNS resolution path),  Mukund’s
> proposal to fragment the DNS message is a good
> solution.https://tools.ietf.org/html/draft-muks-dns-message-fragments-00

both ideas are wrong. what we have to do is arrange to fragment, using 
the ipv6 extension header, all ipv6 udp, for a period of not less than 
five years. noone who blocks ipv6 extension headers should be able to 
get reliable ipv6 udp services. we have to make this problem felt where 
it is made. we must NOT work around it to insulate the makers of the 
problem from the costs of their actions.

> So I do recommend ATR and DNS message fragments should be both
> considered  in a tool box for large DNS response issues.

can a freebsd kernel hacker please contact me? i need some patches, but 
i'm traveling extensively, and i can't do the investigation and software 
engineering myself.

-- 
P Vixie