Re: [DNSOP] BULK RR as optional feature

"Woodworth, John R" <John.Woodworth@CenturyLink.com> Wed, 29 March 2017 00:26 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 96ED3129479 for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 17:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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, URIBL_BLOCKED=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 avxGNQoV01Fn for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 17:26:23 -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 920BE129456 for <dnsop@ietf.org>; Tue, 28 Mar 2017 17:26:23 -0700 (PDT)
Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v2T0QMlQ011106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Mar 2017 18:26:23 -0600
Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 996BF1E0065; Tue, 28 Mar 2017 18:26:17 -0600 (MDT)
Received: from lxdnp32k.corp.intranet (unknown [151.119.92.134]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 767F41E0058; Tue, 28 Mar 2017 18:26:17 -0600 (MDT)
Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v2T0QHW2038054; Tue, 28 Mar 2017 18:26:17 -0600
Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v2T0QHSd038049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Mar 2017 18:26:17 -0600
Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.58]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 19:26:16 -0500
From: "Woodworth, John R" <John.Woodworth@CenturyLink.com>
To: "'John Levine'" <johnl@taugh.com>, "dnsop@ietf.org" <dnsop@ietf.org>
CC: "Woodworth, John R" <John.Woodworth@CenturyLink.com>
Thread-Topic: [DNSOP] BULK RR as optional feature
Thread-Index: AQHSp/GxEz7tgyTElE2qFZBLVlV576Gq7U4w
Date: Wed, 29 Mar 2017 00:26:16 +0000
Message-ID: <A05B583C828C614EBAD1DA920D92866BD0717CCA@PODCWMBXEX501.ctl.intranet>
References: <20170328183156.2467.qmail@ary.lan>
In-Reply-To: <20170328183156.2467.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.7]
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/1Pj04MDf54T2O6Sbi2feuKXKiDQ>
Subject: Re: [DNSOP] BULK RR as optional feature
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: Wed, 29 Mar 2017 00:26:26 -0000

> -----Original Message-----
> From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of John Levine
>
> At yesterday's session, Tale confirmed that since BULK adds so much
> new special purpose complexity to DNS servers, the plan is that
> support for it will be optional.
>
> An optional RRTYPE with extra semantics introduces some new
> compatibility problems.  What happens if a server that doesn't
> support BULK tries to load a local zone file with a BULK record.
>

Hi John,

Thanks for your beautiful question.  If a server doesn't support BULK
the RR will simply sit there like any other unrecognized RR type.

>
> Does it reject the whole file, ignore the record, or something else?
> What if such a server receives BULK by AXFR?  By IXFR?  What if one
> shows up in a cache from a buggy authoritative server?  In all of
> these cases, the current RFC 3597 behavior will just return the
> BULK record which seems wrong.
>

The BULK RR simply transfers "intent" or a "recipe" for other records.
As you indicate, it would be displayed as TYPEXX and "\#" RDATA
encoding but would not interfere with transfers.  Since this RFC3597
behavior is expected behavior, these zones could even be housed in a
nameserver without support and transferred to one with, again with
no impact to the transfer.

One thing I feel I must point out is no one other than the zone admin
really cares about the recipe just the cupcakes.  If your nameserver
can't (or won't) make cupcakes then the cupcakes just don't exist.

Not understanding the recipe is really no different than not using it.

>
> I continue to think that this kind of feature belongs in special
> purpose DNS servers, not in the core DNS.
>

I wouldn't want to force any customers to use "XYZ" just to be able
to send us their recipes.  They probably already have tools and people
in place for managing their current "ABC" nameservers.

I would also just love for a $GENERATE to make it across the wire
intact (assuming both ends are on bind).


Thanks again,
John

>
> R's,
> John
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
-- 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.