Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

"Woodworth, John R" <John.Woodworth@CenturyLink.com> Sat, 22 July 2017 21:23 UTC

Return-Path: <John.Woodworth@CenturyLink.com>
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 5EBBC12711E for <dnsop@ietfa.amsl.com>; Sat, 22 Jul 2017 14:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 DVA8ID449TzG for <dnsop@ietfa.amsl.com>; Sat, 22 Jul 2017 14:23:33 -0700 (PDT)
Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (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 C30F312009C for <dnsop@ietf.org>; Sat, 22 Jul 2017 14:23:33 -0700 (PDT)
Received: from lxdnp04n.corp.intranet (lxdnp04n.corp.intranet [151.119.92.83]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v6MLNUEC061228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 22 Jul 2017 15:23:30 -0600
Received: from lxdnp04n.corp.intranet (localhost [127.0.0.1]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MLNP5m033903; Sat, 22 Jul 2017 15:23:25 -0600
Received: from lxomp07u.corp.intranet (lxdnp23m.corp.intranet [151.119.92.134]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MLNP6L033886 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Sat, 22 Jul 2017 15:23:25 -0600
Received: from lxomp07u.corp.intranet (localhost [127.0.0.1]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MLNPND053957; Sat, 22 Jul 2017 16:23:25 -0500
Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MLNPJS053954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Jul 2017 16:23:25 -0500
Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.120]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Sat, 22 Jul 2017 16:23:25 -0500
From: "Woodworth, John R" <John.Woodworth@CenturyLink.com>
To: 'John R Levine' <johnl@taugh.com>, Tony Finch <dot@dotat.at>
CC: "dnsop@ietf.org" <dnsop@ietf.org>, "Woodworth, John R" <John.Woodworth@CenturyLink.com>
Thread-Topic: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"
Thread-Index: AQHTANpDgEgN9xEOMEWNOGhWzVLUxqJb7Y7AgADKXwCAAFQZAIAAD+qAgANDleA=
Date: Sat, 22 Jul 2017 21:23:24 +0000
Message-ID: <A05B583C828C614EBAD1DA920D92866BD08245A8@PODCWMBXEX501.ctl.intranet>
References: <alpine.LRH.2.20.1707190347390.10419@ns0.nohats.ca> <20170719215749.2241.qmail@ary.lan> <A05B583C828C614EBAD1DA920D92866BD081E78B@PODCWMBXEX501.ctl.intranet> <alpine.OSX.2.21.1707200928290.4118@dhcp-8e4c.meeting.ietf.org> <alpine.DEB.2.11.1707201432160.4413@grey.csi.cam.ac.uk> <alpine.OSX.2.21.1707201624560.5111@dhcp-9d40.meeting.ietf.org>
In-Reply-To: <alpine.OSX.2.21.1707201624560.5111@dhcp-9d40.meeting.ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [151.117.206.8]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/w_-tMGajJet_Vx9wp6acMCF5Zxo>
Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"
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: Sat, 22 Jul 2017 21:23:35 -0000

> -----Original Message-----
> From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of John R Levine
>
> On Thu, 20 Jul 2017, Tony Finch wrote:
> > John R Levine <johnl@taugh.com> wrote:
> >>
> >> BULK absolutely requires online DNSSEC signing,
> >
> > This basically means that BULK is a master-only feature, which implies
> > that there's no need for BULK to work across zone transfers, which
> > implies the need to standardize it for interop is almost nonexistent.
>
> I can't speak for the draft's authors, but in previous correspondence
> I've gotten the impression that they believe that slaves that serve
> BULK can stay in sync via AXFR and IXFR.  Perhaps they can clarify
> how this is supposed to work.
>

Hi John,

Thanks again for your feedback.

First, let me state *I LOVE DNSSEC* but this was definitely not
always the case.  In fact it took nearly a decade for me to go
from: "Why are they solving for a nuclear meltdown of SSl/TLS/PKI?"
to:   "Why isn't this everywhere already?!"

Wherever I was on this path, DNSSEC's eventual ubiquitousness was
always assumed.

However, even now while my group is actively promoting DNSSEC
adoption, from where I sit, I see roughly 1/10 of 1% authoritative
zones with DNSSEC enabled and believe me, most of those 0.1% were
by mandate and not choice.

I write this not as discouragement, reason to dismiss or to
point out failure, as this is *my* community and *my* responsibility
to see it succeed and thrive.  Rather, this is to point out
opportunity where it can be seen.

Dean (co-author) and I believe the success of DNSSEC is
vital to the future of the Internet and hope to play active
roles in its future.  However, as stated its low adoption rate
offers an opportunity to make changes before critical mass makes
it much more complicated.

I see no reason to delay technology like NSEC5 and BULK out of
fear it will slow the adoption of DNSSEC but rather see this as
an opportunity to move forward in parallel and meet this new
landscape we are all building.

As this progress is made, I would like to propose a phased-in
approach for BULK which can be added to the draft a la IPv6.

  Phase-1) BULK only assumed to work on *own* authoritative
           nameservers with insecure zones

  Phase-2) BULK only assumed to work with *some* external
           backup nameservers with insecure zones

  Phase-3) BULK only assumed to work with *most* external
           backup nameservers with insecure zones

  Phase-4) BULK only assumed to work on with *some*
           validating nameservers

  Phase-5) BULK works on all authoritative nameservers
           and validating nameservers


Thanks,
John

>
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
> https://jl.ly
-- THESE ARE THE DROIDS TO WHOM I REFER:
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.