Re: [DNSOP] Perl related question on BULK RR

"Woodworth, John R" <John.Woodworth@CenturyLink.com> Mon, 03 April 2017 22:09 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 67B68124BE8 for <dnsop@ietfa.amsl.com>; Mon, 3 Apr 2017 15:09:07 -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 XYl1D4HJARFr for <dnsop@ietfa.amsl.com>; Mon, 3 Apr 2017 15:09:05 -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 4C73B1294F0 for <dnsop@ietf.org>; Mon, 3 Apr 2017 15:09:02 -0700 (PDT)
Received: from lxdnp04n.corp.intranet (lxdnp04n.corp.intranet [151.119.92.83]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v33M8xYH030614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 3 Apr 2017 17:08:59 -0500
Received: from lxdnp04n.corp.intranet (localhost [127.0.0.1]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v33M8sDB013661; Mon, 3 Apr 2017 16:08:54 -0600
Received: from lxomp06u.corp.intranet (lxdnp23m.corp.intranet [151.119.92.134]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v33M8rKa013631 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Mon, 3 Apr 2017 16:08:54 -0600
Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v33M8rKS046162; Mon, 3 Apr 2017 17:08:53 -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 v33M8rvO046156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Apr 2017 17:08:53 -0500
Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.196]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Mon, 3 Apr 2017 17:08:54 -0500
From: "Woodworth, John R" <John.Woodworth@CenturyLink.com>
To: 'Tony Finch' <dot@dotat.at>
CC: "'dnsop@ietf.org'" <dnsop@ietf.org>, "Ballew, Dean" <Dean.Ballew@CenturyLink.com>, 'JW' <jw@pcthink.com>, "Woodworth, John R" <John.Woodworth@CenturyLink.com>
Thread-Topic: [DNSOP] Perl related question on BULK RR
Thread-Index: AdKnNHlp8TWdUeDYQ/qmHdlSCDbwXAAoizEAAAAXlNABNqUQEA==
Date: Mon, 03 Apr 2017 22:08:53 +0000
Message-ID: <A05B583C828C614EBAD1DA920D92866BD0739DC5@PODCWMBXEX501.ctl.intranet>
References: <A05B583C828C614EBAD1DA920D92866BD0716932@PODCWMBXEX501.ctl.intranet> <alpine.DEB.2.11.1703281107300.13590@grey.csi.cam.ac.uk> <A05B583C828C614EBAD1DA920D92866BD0717607@PODCWMBXEX501.ctl.intranet>
In-Reply-To: <A05B583C828C614EBAD1DA920D92866BD0717607@PODCWMBXEX501.ctl.intranet>
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/2XjvZUKU6NSVnTblVEg9_rQW7d4>
Subject: Re: [DNSOP] Perl related question on BULK RR
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: Mon, 03 Apr 2017 22:09:07 -0000

> -----Original Message-----
> From: Woodworth, John R
>
> > -----Original Message-----
> > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Tony Finch
> ...
> >
> > So my question is, how does the BULK rewriting system interact
> > with DNS loops? Is there a CPU-eating tarpit in there?
> >
>

Hi Tony,

Thanks again for your question.

According to RFC1034, protection should already be in place for all
compliant nameserver implementations.

    ... domain software should not fail when presented with CNAME
    chains or loops; CNAME chains should be followed and CNAME loops
    signalled as an error.

Although this does not specifically call out other RR types, it does
set precedence for following chains and avoiding loops.

I've run through a number of thought exercises and believe this
should still be the case with BULK RRs.

Having said this, I believe your point to be valid and our draft
as well as any implementations would benefit from explicit guidance
for loop avoidance specific to processing BULK RRs.  This should
provide greater consistency across implementations and help avoid
any confusion and error prone logic.

I've also been meaning to flesh out the section regarding sanity
checks while reading BULK RRs into memory (from file or wire).
This could help with avoiding a particular type of loop.

I will work to get these changes added into our draft.


Thanks,
John

>
> > Tony.
> > --
> > f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h
> > punycode South Utsire: Northwesterly 4 or 5 backing southwesterly
> > 3 or 4. Slight or moderate. Fog patches, drizzle. Moderate or good,
> > occasionally very poor.
> >
> > _______________________________________________
> > 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.