Re: [DNSOP] draft-ietf-dnsop-extended-error code options

Mark Andrews <marka@isc.org> Tue, 14 November 2017 03:06 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 A3E2E124217 for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 19:06:02 -0800 (PST)
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 c_lWj9PMRwNo for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 19:06:00 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 ABDCA126DFF for <dnsop@ietf.org>; Mon, 13 Nov 2017 19:06:00 -0800 (PST)
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 5C8D43B7454; Tue, 14 Nov 2017 03:05:56 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 40006160046; Tue, 14 Nov 2017 03:05:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 21C5D160076; Tue, 14 Nov 2017 03:05:56 +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 8oqAgbYcRg5m; Tue, 14 Nov 2017 03:05:56 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 4E451160046; Tue, 14 Nov 2017 03:05:55 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <A70D4EF3-A19D-4E8E-AE34-652F6B7166EF@hopcount.ca>
Date: Tue, 14 Nov 2017 14:05:52 +1100
Cc: George Michaelson <ggm@algebras.org>, dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B7083BF-8A0F-4C64-824D-0FA29587EAE5@isc.org>
References: <yblpo9md8fk.fsf@wu.hardakers.net> <CADyWQ+G-e+zqGkFK7vPQdXBDRvyv-Gxw75N1z+A6L8ULR=+izQ@mail.gmail.com> <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> <e9a3bbc4-0c03-b66c-eb2b-a1c1b336424b@bellis.me.uk> <20171114013049.GA19865@laperouse.bortzmeyer.org> <CAKr6gn03XiZvCx4LsWLGQy8F4ap3w48OR8jY8Fb=RS3Z3LB6YA@mail.gmail.com> <A70D4EF3-A19D-4E8E-AE34-652F6B7166EF@hopcount.ca>
To: Joe Abley <jabley@hopcount.ca>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7kHSVkb6kHhqSBSusMfsrDui8NY>
Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options
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: Tue, 14 Nov 2017 03:06:03 -0000

> On 14 Nov 2017, at 12:48 pm, Joe Abley <jabley@hopcount.ca> wrote:
> 
> On Nov 14, 2017, at 09:37, George Michaelson <ggm@algebras.org> wrote:
> 
>> Stephane, I don't entirely understand your response. old systems can
>> never understand new code point assignments, or know what to do with
>> it, no proposed change can alter this. Middleboxes dropping unexpected
>> things will hit almost any proposed modification of packets in flight.
> 
> The implication is, I think, that some new code points are more likely to survive the attention of Sauron's Middleware than others.
> 
> We have seen claims in the past that new RRTYPEs, new EDNS(0) options, new EDNS(i) with i > 0, new records in ADDITIONAL sections, etc that will all fall fail of middleware or other dependent systems. What's not clear is the relative impact of each, but it seems intuitively true that the impact of each is probably not the same.
> 
> For example, I bet it's more practical to implement a new EDNS(0) option than it is to deploy EDNS(1), but I have no science to back up that intuition.

Only marginally.  Both are deployable between recursive server and authoritative.
It’s easy enough to detect mis-implementations and fallback though one shouldn’t
have to do that.

If Amazon (bad EDNS version negotiation), GoDaddy (bad EDNS flags handling)
and Microsoft (bad EDNS version negotiation, bad EDNS options) would fix their respective
DNS server farms we would have much improved error rates.  Amazon, GoDaddy have
removed the firewall entries that were dropping the test queries since testing started.
I can’t remember if Microsoft was blocking queries.

Amazon’s mis-implementation needs to be fixed before they start serving any signed
zones as the answers to EDNS(1) queries appear as if they come from a server that
doesn’t support EDNS at all (no opt record returned).

18f.gov. @205.251.192.110 (ns-110.awsdns-13.com.): dns=ok edns=ok edns1=noerror,noopt,soa edns@512=ok ednsopt=ok edns1opt=noerror,noopt,soa do=ok ednsflags=ok optlist=ok,nsid,subnet signed=ok ednstcp=ok
29palmsbomi-nsn.gov. @208.109.255.45 (ns70.domaincontrol.com.): dns=ok edns=ok edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=mbz optlist=ok,nsid signed=ok ednstcp=ok
boimi.gov. @64.4.48.6 (ns2-06.azure-dns.net.): dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok

http://ednscomp.isc.org/compliance/summary.html

> If only there was some kind of research group adept at wide-scale measurement from the end-user perspective that could shed some light on this!
> 
> 
> Joe
> _______________________________________________
> 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