IETF Logo Mail Archive

Re: [DNSOP] BULK RR as optional feature

"Woodworth, John R" <John.Woodworth@CenturyLink.com> Wed, 29 March 2017 00:41 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 BDD7312871F for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 17:41:35 -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 5srP6C5TYKZc for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 17:41:34 -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 E086A128B44 for <dnsop@ietf.org>; Tue, 28 Mar 2017 17:41:33 -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 v2T0fXeS025341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Mar 2017 18:41:33 -0600
Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 2CBBD1E0053; Tue, 28 Mar 2017 18:41:28 -0600 (MDT)
Received: from lxomp06u.corp.intranet (unknown [151.119.92.134]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 058031E004E; Tue, 28 Mar 2017 18:41:28 -0600 (MDT)
Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v2T0fRL5025183; Tue, 28 Mar 2017 19:41:27 -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 v2T0fRq2025180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Mar 2017 19:41:27 -0500
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:41:27 -0500
From: "Woodworth, John R" <John.Woodworth@CenturyLink.com>
To: 'Evan Hunt' <each@isc.org>, John Levine <johnl@taugh.com>
CC: "dnsop@ietf.org" <dnsop@ietf.org>, "Woodworth, John R" <John.Woodworth@CenturyLink.com>
Thread-Topic: [DNSOP] BULK RR as optional feature
Thread-Index: AQHSp/GxEz7tgyTElE2qFZBLVlV576GrDi6A///pAzA=
Date: Wed, 29 Mar 2017 00:41:26 +0000
Message-ID: <A05B583C828C614EBAD1DA920D92866BD0717CFC@PODCWMBXEX501.ctl.intranet>
References: <20170328183156.2467.qmail@ary.lan> <20170328205151.GB23312@isc.org>
In-Reply-To: <20170328205151.GB23312@isc.org>
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/uDOK3cj76wx-T570OUsBMDtchiw>
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:41:36 -0000

> -----Original Message-----
> From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Evan Hunt
>
> On Tue, Mar 28, 2017 at 06:31:56PM -0000, John Levine wrote:
> > What if such a server receives BULK by AXFR?  By IXFR?
>
> I agree these scenarios in particular need to be specified.
>

Hi Evan,

Thanks for your comments.

>
> One possible solution would be an EDNS signal indicating whether or
> not the secondary server implements BULK. If not, the primary would
> have to expand the BULK data during transfer, same as BIND expands
> $GENERATE.  (I proposed a similar sort of EDNS signaling mechanism
> in draft-hunt-note-rr-01 a few years back.)
>

I believe this would ultimately be less efficient than generating
the records on the fly.

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.

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.


Thanks,
John

>
> --
> Evan Hunt -- each@isc.org
> Internet Systems Consortium, Inc.
>
> _______________________________________________
> 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.

v2.23.0 | Report a Bug | By Email