Re: [DNSOP] old arguments unrelated to SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)

Mark Andrews <marka@isc.org> Tue, 01 March 2016 23:37 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F2D1B4366 for <dnsop@ietfa.amsl.com>; Tue, 1 Mar 2016 15:37:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 p8Y4zGa_4UAJ for <dnsop@ietfa.amsl.com>; Tue, 1 Mar 2016 15:37:44 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB44B1B4346 for <dnsop@ietf.org>; Tue, 1 Mar 2016 15:37:43 -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)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 5C6621FCAB3; Tue, 1 Mar 2016 23:37:40 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3AFE61600BB; Tue, 1 Mar 2016 23:37:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2EFD31600BA; Tue, 1 Mar 2016 23:37:39 +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 0dSZsIAEFjGL; Tue, 1 Mar 2016 23:37:39 +0000 (UTC)
Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id E575D160042; Tue, 1 Mar 2016 23:37:38 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A4C0E438E1E9; Wed, 2 Mar 2016 10:37:35 +1100 (EST)
To: John R Levine <johnl@taugh.com>
From: Mark Andrews <marka@isc.org>
References: <20160301165633.71260.qmail@ary.lan> <56D5CA62.1030206@bellis.me.uk> <CAMm+LwjJ0xe2wDW98JHJfV5jV3xTeuMNguU=rkqrZMzmei2iHA@mail.gmail.com> <20160301225138.53AFB438DCC1@rock.dv.isc.org> <alpine.OSX.2.11.1603011813560.36649@ary.lan>
In-reply-to: Your message of "01 Mar 2016 18:15:22 -0500." <alpine.OSX.2.11.1603011813560.36649@ary.lan>
Date: Wed, 02 Mar 2016 10:37:35 +1100
Message-Id: <20160301233735.A4C0E438E1E9@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/tfp6SNtGexXtfn-4bvDEfU67Wts>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] old arguments unrelated to SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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, 01 Mar 2016 23:37:45 -0000

In message <alpine.OSX.2.11.1603011813560.36649@ary.lan>, "John R Levine" writes:
> >> The NDR record is deliberately free format because changing DNS
> >> servers is HARD, no really it is ridiculously hard with a ten year
> >> lag. Which is of course why we won't use a new record at all:
> >
> > Really?  We have rpm's of new versions of named supplied within
> > hours of ISC's public announcements of new named releases.  I'm
> > sure there are similar announcements for other nameserver vendors.
> 
> I suppose I could say web based configuration crudware a few dozen more 
> times, but I doubt it would sink in any more than it has before.
> 
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.

Look at https://ednscomp.isc.org/compliance/summary.html.

The EDNS COOKIE code point was only allocated in July.  You have
TLD operators and Alex top 1000 operators supporting it and we don't
yet have the RFC out the door.  Named's support in BIND 9.10.3
requires the nameserver builder to turn it on at configure time
unless you are running it on Windows where it is on by default.

[ I've heard one of the Linux vendors turns it on at compile time. ]

It will be on by default in BIND 9.11.0.

Slowness in supporting new types is not the problem of nameserver
vendors.  Support for routine extensions to the DNS actually gets
done in a timely manner.  Universal support takes a long time (which
you can also see in those graphs) but you don't need universal
support for new types.  You need a resolver that can perform the
lookup if you want to use the new type and the ability to publish
the record.

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