Re: [DNSOP] BULK RR as optional feature

"Woodworth, John R" <> Wed, 29 March 2017 03:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DE16128D3E for <>; Tue, 28 Mar 2017 20:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BcSdIhOm_g7k for <>; Tue, 28 Mar 2017 20:40:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D78311204DA for <>; Tue, 28 Mar 2017 20:40:40 -0700 (PDT)
Received: from ( []) by (8.14.8/8.14.8) with ESMTP id v2T3edPY008566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Mar 2017 21:40:40 -0600
Received: from (unknown []) by IMSA (Postfix) with ESMTP id D2E941E0063; Tue, 28 Mar 2017 22:40:33 -0500 (CDT)
Received: from lxomp06u.corp.intranet (unknown []) by (Postfix) with ESMTP id B81311E004F; Tue, 28 Mar 2017 22:40:33 -0500 (CDT)
Received: from lxomp06u.corp.intranet (localhost []) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v2T3eX5v018666; Tue, 28 Mar 2017 22:40:33 -0500
Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet []) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v2T3eXDx018663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Mar 2017 22:40:33 -0500
Received: from PODCWMBXEX501.ctl.intranet ([]) by vodcwhubex502.ctl.intranet ([]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 22:40:33 -0500
From: "Woodworth, John R" <>
To: 'Evan Hunt' <>
CC: John Levine <>, "" <>, "Woodworth, John R" <>
Thread-Topic: [DNSOP] BULK RR as optional feature
Thread-Index: AQHSp/GxEz7tgyTElE2qFZBLVlV576GrDi6A///pAzCAAHKOgP//sSIA
Date: Wed, 29 Mar 2017 03:40:32 +0000
Message-ID: <A05B583C828C614EBAD1DA920D92866BD0717F28@PODCWMBXEX501.ctl.intranet>
References: <20170328183156.2467.qmail@ary.lan> <> <A05B583C828C614EBAD1DA920D92866BD0717CFC@PODCWMBXEX501.ctl.intranet> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
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: <>
Subject: Re: [DNSOP] BULK RR as optional feature
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Mar 2017 03:40:43 -0000

> -----Original Message-----
> From: Evan Hunt []
> On Wed, Mar 29, 2017 at 12:41:26AM +0000, Woodworth, John R wrote:
> > I believe this would ultimately be less efficient than generating
> > the records on the fly.
> Unquestionably. This clearly wouldn't be the preferred behavior.
> If the slave does understand BULK records, you'd just transfer those.
> > Assuming a relatively small range, say an IPv4 /16.  You would
> > need to sweep through similar logic and load _every_single_answer_
> > into memory rather than just the ones which are asked for.
> Sure, that's what $GENERATE does. The generated records are then
> transfered normally. You con't end up with one auth server that
> has generated records and another that doesn't.
> > I see no reason caching couldn't be used to hold the more
> > commonly requested records in order to save on CPU. (apologies
> > for double-neg)
> >
> > Additionally, the patterns could (and most likely should) be pre-
> > parsed for simpler/ lower calorie processing.
> But if you have a primary that supports BULK and a secondary that
> doesn't, then you have two authoritative servers for the same domain
> with the same serial number but one of is saying NXDOMAIN when the
> other one returns a positive answer.  This is a significant problem,
> and the draft ought to address it.  (Or have I misunderstood
> something?)

Hi Evan,

Thanks again for your continued feedback.  A reasonable amount of
inconsistency is expected and even tolerated in the wild today.  As
far as BULK RRs are concerned, we do touch on it in section 6.2.

   "Prior to widespread adoption on the authoritative side all generated
   records would be invisible if served on nameservers lacking support.
   Since generated records are generally NOT service impacting records
   this should be understood but not of great concern."

Should BULK RRs gain wider adoption more quickly than expected perhaps
this would not be a prolonged condition.

Making support optional, while I do not strongly oppose, would
definitely exacerbate the issue of consistency to some extent.


> --
> Evan Hunt --
> Internet Systems Consortium, Inc.
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.