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

Mark Andrews <marka@isc.org> Fri, 22 September 2017 03:14 UTC

Return-Path: <marka@isc.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 D9AFC128D0D for <dnsop@ietfa.amsl.com>; Thu, 21 Sep 2017 20:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 pW_jHhKrcVkR for <dnsop@ietfa.amsl.com>; Thu, 21 Sep 2017 20:14:35 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 614141252BA for <dnsop@ietf.org>; Thu, 21 Sep 2017 20:14:35 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 603513495A8; Fri, 22 Sep 2017 03:14:02 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 408D116003D; Fri, 22 Sep 2017 03:14:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0F0F1160069; Fri, 22 Sep 2017 03:14:02 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id z3B-fx-km0ql; Fri, 22 Sep 2017 03:14:01 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 78DDB16003D; Fri, 22 Sep 2017 03:14:00 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 94ABB87A157F; Fri, 22 Sep 2017 13:13:58 +1000 (AEST)
To: Paul Vixie <paul@redbarn.org>
Cc: =?UTF-8?B?IkRhdmV5IFNvbmco5a6L5p6X5YGlKSI=?= <ljsong@biigroup.cn>, 'dnsop' <dnsop@ietf.org>
From: Mark Andrews <marka@isc.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 <59C34510.4080705@redbarn.org> <048701d332a8$6f944980$4ebcdc80$@cn>+1004318D79D4A4F6 <59C47601.5030804@redbarn.org>
In-reply-to: Your message of "Thu, 21 Sep 2017 19:31:29 -0700." <59C47601.5030804@redbarn.org>
Date: Fri, 22 Sep 2017 13:13:58 +1000
Message-Id: <20170922031358.94ABB87A157F@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pNRw48ksvsjcB38DY2ln7mEmPJY>
Subject: Re: [DNSOP] =?utf-8?b?562U5aSNOiAgIOetlOWkjTogIEZ3ZDogSS1EIEFjdGlv?= =?utf-8?q?n=3A_draft-song-atr-large-resp-00=2Etxt?=
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: Fri, 22 Sep 2017 03:14:37 -0000

In message <59C47601.5030804@redbarn.org>rg>, Paul Vixie writes:
> Davey Song() wrote:
> > Hi Paul,
> >
> > I know you suggest expose the problem and let the trouble maker
> > feeling the pain themselves. But return to the specific issue, from
> > APNIC's measurement the ASes in the path are dropping the fragments,
> > rather than end ASes. From these ASes' view , it's your pain not
> > theirs.
>
> it's a question of first mover advantage. EDNS will never be fully
> deployed, because of the middleboxes built before 1999 who "know" what a
> UDP/53 datagram has to look like, and which disallow ADCOUNT>0 && QR=0.

The ones built after 1999 that assume EDNS will always have a version
field of zero, or that there won't be any EDNS options, or that
there won't be any EDNS flags bits, other than DO, are the biggest
problem.

> we can, if we wish, continue to standardize one protocol, watch as the
> world deploys a different one, and still pretent that our effort was
> worthwhile. however, this would fit the technical definition of
> "insanity", and i urge that we avoid this course of action.
>
> > In another word, we are facing the fragmented and uncooperative
> > Internet. What should we do ? It is very hard to coordinate all parts
> > and networks. DNS is a field with lots of tussle.
>
> we need a kernel option for various open source operating systems which
> causes all UDP to be fragmented at 512 octets of payload. for ipv4, so
> that we can hard-smash every middlebox which still prevents EDNS from
> being deployed, and for ipv6 also, so that we can hard-smash any middle
> or edge network who won't carry ipv6 extension headers.
>
> and we need to turn this on everywhere. root, gtld, cctld, recursives,
> authoriatives, 8.8.8.8, opendns... Everywhere. with a press release to
> pre-announce the flag day.
>
> if we're not going to stand up for the standards we write, then we
> should admit that nothing except tcp/80 will work, and avoid all else.

Just padding UDP responses to EDNS buffer size should be enough to
force fragmentation.  If you advertise a 4096 buffer you should be
able to accept such a response.

We also need to bump the EDNS version number.  Going to EDNS(1)
will hit the firewalls that think EDNS(0) is the only EDNS version
they will ever see.

BIND 9.11 is already adding a DNS COOKIE option to every request.
That is causing some firewalls to be fixed as well as some nameservers.
We haven't added additional workaround code for this.

Mark
> --
> P Vixie
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org