Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt

Ondřej Surý <ondrej.sury@nic.cz> Fri, 30 March 2012 10:09 UTC

Return-Path: <ondrej.sury@nic.cz>
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 12D6421F86B5 for <dnsop@ietfa.amsl.com>; Fri, 30 Mar 2012 03:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Level:
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCsRpXkQBE2D for <dnsop@ietfa.amsl.com>; Fri, 30 Mar 2012 03:09:13 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BDA4321F8690 for <dnsop@ietf.org>; Fri, 30 Mar 2012 03:09:12 -0700 (PDT)
Received: from [IPv6:2001:df8::96:70e4:97af:392a:a0d0] (unknown [IPv6:2001:df8:0:96:70e4:97af:392a:a0d0]) by mail.nic.cz (Postfix) with ESMTPSA id A71AE141260; Fri, 30 Mar 2012 12:09:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333102151; bh=FE50SvH5Cpgexr4xKcg3dIiBQv3mA/q24blLotCp2bw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qoA0+oLnnFGJHSFQwiPkrdGAkkOppSNEUU+AKDhV0LDrOL2eY/VDLNca+KGSBcG1X jZOymJi862gjsf7rGJwnDVMZ8WsnX5DLZUiL6fJAVvn4bGun8XEKyilNhZ//Uw6MFs +z2TJJlTkEXyOYA8GjvMd2E5e6uEvwbJmkjkUtwA=
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="utf-8"
From: Ondřej Surý <ondrej.sury@nic.cz>
In-Reply-To: <C21F43CF-9CA9-4A40-A7CC-463C5139F362@secure64.com>
Date: Fri, 30 Mar 2012 12:09:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2FDD0E1-9C08-43C4-967E-1AE9102D817E@nic.cz>
References: <20120217000918.22307.43753.idtracker@ietfa.amsl.com> <2D04DB88-9570-4DE3-A796-F4F07AF5EF74@secure64.com> <017101ccefd5$51790560$f46b1020$@lampo@eurid.eu> <C21F43CF-9CA9-4A40-A7CC-463C5139F362@secure64.com>
To: Joseph Gersch <Joe.Gersch@Secure64.com>
X-Mailer: Apple Mail (2.1257)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 30 Mar 2012 10:09:14 -0000

Hi Joseph,

since I am not sure if you understood my point (I am not sure if I was able
to understand it myself :), I am summarizing it to the mailing list.

I like the direction of your work, but I miss a way how to put more stuff under
the named prefix.

I would like you to update RFC2317 together with your document, so the end
customers don't have two distinct trees in their DNS infrastructure.

F.e. if I have 1.0.m.82.129.in-addr.arpa prefix in the DNS and I have delegate
it to the customer, how do I put my PTRs in?  The block owner would still have
to delegate another "dummy" prefix with CNAMEs and you have to handle it in
separate zone.

BTW one more observation.  Since you don't have to do any zone cuts in the binary
part, why not merge them into just one label?  E.g. something like 10.m.82.129.in-addr.arpa or 10001101.m.82.129.in-addr.arpa.

O.

On 20. 2. 2012, at 23:33, Joseph Gersch wrote:

> Hello Marco,
> 
>  Thanks for reading and commenting on our draft.  We have a couple of weeks to make corrections to draft-00 before they get frozen for the IETF meeting.  We appreciate your pointing out the typos (we found the ipv6 one ourselves, oops.....) and the suggestions for clarification.
> 
>   This draft on CIDR naming is mainly focused on  proposing a simple, direct way to name CIDR addresses and eliminates the need for CNAME indirection.  It can be used for a number of purposes.
> 
> Regarding the intro on pre-populating the reverse-DNS... you are correct, this is a draft on CIDR naming, not on fixing that particular IPv6 issue.  We will make that clarification in our next draft.  The ipv6 issue "might" be able to be addressed with this approach, but more thought needs to be put in to it before a complete solution could be proposed.  We were mentioning this issue in order to give multiple examples of the reasons why CIDR naming is a useful concept.
> 
>    Again, thanks,
>  - Joe Gersch and Dan Massey
> 
> 
> On Feb 20, 2012, at 6:41 AM, Marc Lampo wrote:
> 
>> Hello,
>> 
>> (sorry – previously sent email was not finished …)
>> 
>> Some “typographic” remarks :
>> 1) 5.2 IPv4 Address Block Naming → IPv6 Address Block Naming
>> 2) In 5.2 there are 2 examples that have missing “::”,
>> (2607:fa88:8000:/33 → 2607:fa88:8000::/33 and
>> 2607:fa88:8000:/35 → 2607:fa88:8000::/35)
>> in 5.3 there is 1 example with missing “::”.
>> (2607:fa88:8000:/36 → 2607:fa88:8000::/36)
>> 
>> About “content” :
>> 1) 3. Design Requirement → 2. Coverage Authority.
>> “Any … with a data record or NXDOMAIN …”
>> to be completed with : NODATA
>> → “Any … with a data record or NODATA or NXDOMAIN …”
>> 
>> 2) In 5.2 IPv6 Address Block Naming
>> Why not add some examples to show conversion from a reverse-DNS name back to 
>> CIDR ?
>> (just like in 5.1)
>> 
>> Globally :
>> 1) It is implied by the content of the present draft,
>> but should it be stated (in Design Requirements)
>> that the proposal should be valid for both IPv4 and IPv6 addresses ?
>> 
>> 2) In the Introduction, where you correctly state that ISP’s pre-populate 
>> reverse DNS,
>> the problem is stated that the approach of pre-populating does not scale for 
>> IPv6.
>> However, by itself, this draft does not solve that problem, does it ?
>> (needs programmatic support)
>> (this example in the Introduction made me think/assume that this draft
>> also applies to “simple” reverse mapping.  In which case I wondered how
>> this draft does away with CNAME (a la RFC 2317).
>> But then, after rereading it occurred to me that this draft is about 
>> storing
>> CIDR info in revdns.
>> → isn’t it confusing to give, in the intro, an example that does not apply 
>> to CIDR info ?
>> (it got at least me confused, not that I’d want to be taken as a reference 
>> ;-)
>> 
>> Kind regards,
>> 
>> Marc Lampo
>> Security Officer
>> EURid
>> 
>> 
>> From: Joseph Gersch [mailto:joe.gersch@secure64.com]
>> Sent: 17 February 2012 06:17 PM
>> To: dnsop@ietf.org
>> Subject: [DNSOP] Fwd: New Version Notification for 
>> draft-gersch-dnsop-revdns-cidr-00.txt
>> 
>> All,
>> we have submitted a new draft that will be presented at the Paris IETF 
>> meeting.
>> Please take the time to send any comments and suggestions regarding this 
>> idea on naming CIDR address blocks in the Reverse DNS.
>> 
>> Best regards,
>>  - Joe Gersch and Dan Massey
>> 
>> 
>> Begin forwarded message:
>> 
>> 
>> From: internet-drafts@ietf.org
>> Date: February 16, 2012 5:09:18 PM MST
>> To: joe.gersch@secure64.com
>> Cc: joe.gersch@secure64.com, massey@cs.colostate.edu
>> Subject: New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt
>> 
>> A new version of I-D, draft-gersch-dnsop-revdns-cidr-00.txt has been 
>> successfully submitted by Joe Gersch and posted to the IETF repository.
>> 
>> Filename:	 draft-gersch-dnsop-revdns-cidr
>> Revision:	 00
>> Title:		 Reverse DNS Naming Convention for CIDR Address Blocks
>> Creation date:	 2012-02-14
>> WG ID:		 Individual Submission
>> Number of pages: 19
>> 
>> Abstract:
>> The current reverse DNS naming method is used to specify a complete
>> IP address.  It has not been used to handle address ranges; for
>> example, there is no formal mechanism for specifying a reverse DNS
>> name for the block of addresses specified by the IPv4 prefix
>> 129.82.0.0/16.  Defining such a reverse DNS naming convention would
>> be useful for a number of applications.  These include applications
>> for secure BGP routing, and applications that need host-information
>> for a device owning a complete IPv6 address block.  This draft
>> proposes a naming convention for encoding CIDR address blocks in the
>> reverse DNS.
>> 
>> 
>> 
>> 
>> The IETF Secretariat
>> 
>> Joseph Gersch
>> Chief Operating Officer
>> Secure64 Software Corporation
>> 
>> 
>> 
> 
> Joseph Gersch
> Chief Operating Officer
> Secure64 Software Corporation
> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:ondrej.sury@nic.cz    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------