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> Thu, 20 July 2017 02:12 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 E852C12F274 for <dnsop@ietfa.amsl.com>; Wed, 19 Jul 2017 19:12:47 -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 94YrWCf51rde for <dnsop@ietfa.amsl.com>; Wed, 19 Jul 2017 19:12:46 -0700 (PDT)
Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 7C9EB126C2F for <dnsop@ietf.org>; Wed, 19 Jul 2017 19:12:46 -0700 (PDT)
Received: from lxomp90v.corp.intranet (lxomp90v.corp.intranet [151.117.203.59]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v6K2Cixs058695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 19 Jul 2017 21:12:44 -0500
Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6K2Cdo1045704; Wed, 19 Jul 2017 21:12:39 -0500
Received: from lxomp06u.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6K2Cdbc045699 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Wed, 19 Jul 2017 21:12:39 -0500
Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6K2CdYr015698; Wed, 19 Jul 2017 21:12:39 -0500
Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v6K2CcRP015695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jul 2017 21:12:39 -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; Wed, 19 Jul 2017 21:12:38 -0500
From: "Woodworth, John R" <John.Woodworth@CenturyLink.com>
To: 'John Levine' <johnl@taugh.com>, "dnsop@ietf.org" <dnsop@ietf.org>
CC: "paul@nohats.ca" <paul@nohats.ca>, "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: AQHTANpDgEgN9xEOMEWNOGhWzVLUxqJb7Y7A
Date: Thu, 20 Jul 2017 02:12:38 +0000
Message-ID: <A05B583C828C614EBAD1DA920D92866BD081E78B@PODCWMBXEX501.ctl.intranet>
References: <alpine.LRH.2.20.1707190347390.10419@ns0.nohats.ca> <20170719215749.2241.qmail@ary.lan>
In-Reply-To: <20170719215749.2241.qmail@ary.lan>
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/JcILD6XGnRq9oEcsf2JO37JD56E>
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: Thu, 20 Jul 2017 02:12:48 -0000

> -----Original Message-----
> From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of John Levine
>
> I realize that my biggest problem with this draft is not that
> I don't think that it's useful -- we have lots of RFCs that
> turned out to be useless but harmless.  It's that it breaks the
> DNS by being egregiously not backward compatible.
>

Hi John,

As always, we welcome your comments.

Agreed, BULK is not 100% backward compatible.  Unfortunately,
we are not coming into a greenfield situation and are forced
work within the confines of where we are.

Sometimes an idea like this is better discussed over a cold beer
or N-A beverage and my next opportunity, I hope to sit with you
and others on this list.


For now, I think we've narrowed the draft opposition to two camps:

Camp#1) Don't force me to use IPv6 reverse, I simply will never

and

Camp#2) Don't break DNS, even for a second


I feel I hear and understand the concerns of both camps but believe
the problems may be being over stated.

If you choose to not use BULK for IPv6, fine.  Perhaps you may see
the benefit of $GENERATE-like synthesis that can be easily AXFR'd?

>
> I would strongly prefer if we defer consideration of this draft
> until we figure out how to do DNS versioning, some way to say
> that this record type (and consequently, the zone returned to
> this AXFR or IXFR) requires special processing, and if you don't
> know how to do the processing, don't guess.  This would update or
> perhaps even replace RFC 3597.
>
...
>
> But with BULK, if a secondary doesn't understand it, the answers
> will just be wrong.
>

If you choose a secondary, that is unaware of BULK, you will get
NXDOMAIN's when they are hit.  If BULK makes it into the top-5
DNS nameserver implementations, it's only a matter of time before
the next security concern will get the secondary back in sync and
in the meantime, maybe you can choose a compatible one.

Early adopters will see hiccups, not sure this can be avoided,
but how would delaying BULK until versioning is in place be able to
prevent it?  Wouldn't a secondary just have stale data or some
other data inconsistency based on version incompatibility?


Thanks again,
John

>
-- 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.