Re: [DNSOP] discussion for draft-woodworth-bulk-rr-00.txt

Edward Lewis <edward.lewis@icann.org> Mon, 02 November 2015 02:40 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96381B2A03 for <dnsop@ietfa.amsl.com>; Sun, 1 Nov 2015 18:40:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.431
X-Spam-Level:
X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 kSzCw2rCZcxt for <dnsop@ietfa.amsl.com>; Sun, 1 Nov 2015 18:40:36 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646BE1B2A09 for <dnsop@ietf.org>; Sun, 1 Nov 2015 18:40:34 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Sun, 1 Nov 2015 18:40:32 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Sun, 1 Nov 2015 18:40:32 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "Woodworth, John R" <John.Woodworth@CenturyLink.com>
Thread-Topic: [DNSOP] discussion for draft-woodworth-bulk-rr-00.txt
Thread-Index: AQHQs6HajEBE2MNJJEGXvuU+27Pii56IYagggAGDsIA=
Date: Mon, 02 Nov 2015 02:40:32 +0000
Message-ID: <D25CED53.10A58%edward.lewis@icann.org>
References: <A05B583C828C614EBAD1DA920D92866BA5DF065B@PODCWMBXEX501.ctl.intranet>
In-Reply-To: <A05B583C828C614EBAD1DA920D92866BA5DF065B@PODCWMBXEX501.ctl.intranet>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.236]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3529309219_7846020"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/T-_hGFSXh0mAdpTMlWjVR_rprWs>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] discussion for draft-woodworth-bulk-rr-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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, 02 Nov 2015 02:40:39 -0000

Process wise, you should seek to have this on the experimental track.  It
has potential but is far from a sure thing.

The idea of being able to send formulas for generating responses,
particularly for address records, reverse map and CNAME is a latent need
in the DNS hosting industry.  These types are special in that way, so it's
no surprise they are singled out.

I'll admit that I read and scanned portions to get an idea of what is
discussed.  I do like that you have the section 7.1, addressing DNSSEC.

One "red flag" to me is the idea of hidden wildcards.  One of the design
principles of DNSSEC is that it exposes the "thinking" process of the
server to the requestor.  That alone isn't a dead end - hidden records and
on-the-fly signing would "work" (but as you note not all name server
implementations have the ability to sign on-the-fly).

Cutting to the chase, there are various elements here that could work
together.  But also combinations that wouldn't work so well.  Simply put,
this is complicated.  For reasons I'll not include here, complicating the
protocol isn't leading in the right direction.

I do get the desire for this.  I also would like to see someway to augment
response synthesis (beyond wildcards).  Perhaps a scaled down version
would be more manageable (like removing the hidden records and answering
with the signed formula plus unsigned result - just as for DNAME).

On 11/2/15, 5:50, "DNSOP on behalf of Woodworth, John R"
<dnsop-bounces@ietf.org on behalf of John.Woodworth@CenturyLink.com> wrote:

>All,
>
>Apologies for any procedural missteps as I am new to the group but am
>trainable.
>
>I am looking to get some traction on a recent I-D my group is working on
>and
>am looking for advice along the way.
>
>We are confident this draft can play a significant role in the future of
>DNS
>especially as it relates to IPv6.  While there are many problems we are
>attempting to address with this draft, we believe the biggest among them
>are related to IPv6 and the scarcity of IPv4 address space.
>
>If, by contacting this mailing list, we are heading down the wrong path
>we are
>particularly fond of any advice to move this forward as we see the need
>for it
>becoming more and more important as the adoption of IPv6 increases.
>
>
>The draft announcement is here:
>
>> -----Original Message-----
>> Subject: New Version Notification for draft-woodworth-bulk-rr-00.txt
>>
>>
>> A new version of I-D, draft-woodworth-bulk-rr-00.txt has been
>>successfully
>> submitted by John Woodworth and posted to the IETF repository.
>>
>> Name:         draft-woodworth-bulk-rr
>> Revision:     00
>> Title:                BULK DNS Resource Records
>> Document date:        2015-06-30
>> Group:                Individual Submission
>> Pages:                28
>> URL:            
>>https://www.ietf.org/internet-drafts/draft-woodworth-bulk-rr-00.txt
>> Status:         
>>https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/
>> Htmlized:       https://tools.ietf.org/html/draft-woodworth-bulk-rr-00
>>
>>
>> Abstract:
>>    The BULK DNS resource record type defines a method of pattern based
>>    creation of DNS resource records to be used in place of NXDOMAIN
>>    errors which would normally be returned.  These records are currently
>>    restricted to registered DNS resource record types A, AAAA, PTR and
>>    CNAME.  The key benefit of the BULK resource record type is the
>>    simplification of maintaining "generic" record assignments which
>>    would otherwise be too many to manage or require scripts or
>>    proprietary methods as bind's $GENERATE.
>>
>
>
>Thanks and best regards,
>John
>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.
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop