Re: [DNSOP] BULK RR as optional feature

"Woodworth, John R" <John.Woodworth@CenturyLink.com> Wed, 29 March 2017 05:01 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 94695129432 for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 22:01:36 -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 qz8Viz5ac19E for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 22:01:34 -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 8050E12922E for <dnsop@ietf.org>; Tue, 28 Mar 2017 22:01:34 -0700 (PDT)
Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v2T51XEq058928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Mar 2017 00:01:33 -0500
Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 428DA1E004F; Wed, 29 Mar 2017 00:01:28 -0500 (CDT)
Received: from lxomp06u.corp.intranet (unknown [151.117.18.14]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 2740E1E004D; Wed, 29 Mar 2017 00:01:28 -0500 (CDT)
Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v2T51RNW032028; Wed, 29 Mar 2017 00:01:27 -0500
Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v2T51RIo032025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Mar 2017 00:01:27 -0500
Received: from PDDCWMBXEX507.ctl.intranet ([fe80::48d4:ee92:4aae:cbd0]) by vddcwhubex501.ctl.intranet ([151.119.128.28]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 23:01:27 -0600
From: "Woodworth, John R" <John.Woodworth@CenturyLink.com>
To: 'Evan Hunt' <each@isc.org>, John R 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///pAzCAAHKOgIAAGG8AgAAEp4D//7LuoA==
Date: Wed, 29 Mar 2017 05:01:26 +0000
Message-ID: <A05B583C828C614EBAD1DA920D92866BD0722285@PDDCWMBXEX507.ctl.intranet>
References: <20170328183156.2467.qmail@ary.lan> <20170328205151.GB23312@isc.org> <A05B583C828C614EBAD1DA920D92866BD0717CFC@PODCWMBXEX501.ctl.intranet> <20170329021935.GA25314@isc.org> <alpine.OSX.2.20.1703282245500.4804@ary.local> <20170329040341.GA27262@isc.org>
In-Reply-To: <20170329040341.GA27262@isc.org>
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/IBmcd-UxbByoMgvUq4c9Gf8GIro>
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 05:01:36 -0000

> -----Original Message-----
> From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Evan Hunt
>
> On Tue, Mar 28, 2017 at 10:47:02PM -0500, John R Levine wrote:
> > That's exactly the problem -- a server that doesn't handle BULK will
> > return the wrong answer.  It might return the BULK record itself or
> > NXDOMAIN for an address that BULK would synthesize.
>
> And, if the zone is signed, it'll be provably wrong.  I don't think
> it's enough to handwave the problem as "not of great concern". At
> least, please add some operational advice that BULK is not to be
> deployed in any domain unless all auth servers for that domain
> fully implement it.
>

Evan,

Again, thank you.

I can see your point where more guidance could be needed here.


As far as BULK RRs in this scenario are concerned, there would still be
two provably valid states as seen from the perspective of a validating
resolver.


Either -

1) *No* BULK support on this auth NS:
   Queried RR does not exist (and actually does not exist)
   NSEC/NSEC3/etc. proves it does not exist.

2) BULK support on this auth NS:
   Queried RR does exist (is actually synthesized)
   RRSIG exists (online) proves it does exist
     - Or -
   RRSIG and NPN exist (offline)
     - proves it does exist (requires NPN aware resolver for validation)


Other options are available (e.g. insecure delegation for these RRs, etc.)


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.