Re: [DNSOP] request for working group to adopt draft-gersch-dnsop-revdns-cidr-04.txt

Joseph Gersch <Joe.Gersch@Secure64.com> Wed, 06 March 2013 15:34 UTC

Return-Path: <Joe.Gersch@Secure64.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 C788B21F856E for <dnsop@ietfa.amsl.com>; Wed, 6 Mar 2013 07:34:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.298
X-Spam-Level:
X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_FORM=2.3, NORMAL_HTTP_TO_IP=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 PJAK1ttlStHE for <dnsop@ietfa.amsl.com>; Wed, 6 Mar 2013 07:34:12 -0800 (PST)
Received: from zimbra.secure64.com (mail.secure64.com [64.92.221.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA3221F8549 for <dnsop@ietf.org>; Wed, 6 Mar 2013 07:34:11 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 1F295B8797; Wed, 6 Mar 2013 08:34:11 -0700 (MST)
X-Virus-Scanned: amavisd-new at secure64.com
Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDsaIEryV-2N; Wed, 6 Mar 2013 08:34:10 -0700 (MST)
Received: from [10.138.15.18] (unknown [192.168.254.4]) by zimbra.secure64.com (Postfix) with ESMTPSA id 4021EB8784; Wed, 6 Mar 2013 08:34:09 -0700 (MST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1362584050; bh=95iR/ovv0hYynT0EenR/hjqDKNFSMfS+PaMS7wWlqZU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=scf2otHWXHIpQSRNawpOYD+zb3Ko2a2jq5Zw3t Df07tvFk/3Ql3/Zu4Lbf4q2qL5KSMfqjt+liQ5ThnEPO8Z2nNuSDedjHBv7oUIamyNC mseslWYhWRxmBQBmY52PCOCmFfOKHZPnf9xzONvMFRhbdVT19vql4hcMxsvrbl6mrE=
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/signed; boundary="Apple-Mail=_8594B1E5-2508-44E6-B7DC-210A87530BA7"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Joseph Gersch <Joe.Gersch@Secure64.com>
In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE7310592540@wds-exc1.okna.nominet.org.uk>
Date: Wed, 06 Mar 2013 08:34:09 -0700
Message-Id: <52993A80-864D-4324-B041-4D285513A529@Secure64.com>
References: <D8A9B38C-8E83-44E9-8733-000FA8705F60@cs.colostate.edu> <53F00E5CD8B2E34C81C0C89EB0B4FE7310592540@wds-exc1.okna.nominet.org.uk>
To: Ray Bellis <Ray.Bellis@nominet.org.uk>
X-Mailer: Apple Mail (2.1283)
Cc: "<dnsop@ietf.org>" <dnsop@ietf.org>, Daniel Massey <massey@cs.colostate.edu>
Subject: Re: [DNSOP] request for working group to adopt draft-gersch-dnsop-revdns-cidr-04.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: Wed, 06 Mar 2013 15:34:12 -0000

Hello Ray,
   you are correct in your statement that m.82.129.in-addr.arpa (for 129.82.0.0/16) is not a subdomain of the name assigned to 129.82.0.0/15 in the proposed naming scheme.

   We basically had two choices -- one was to go strictly binary, in which case all of the possible sub-delegations will work.  But we also had the objective to work with the currently defined reverse DNS which DOES sub-delegate at octet boundaries.  Therefore we state in the new draft that subdelegations work up to the nearest octet (or nibble) boundary.  If the naming rules are followed, only one name can be assigned to each cidr address block.  Sub-delegations work within an octet and a nibble.

    The objective of working within the current system trumped the desire to have perfect sub-delegations from top to bottom.    Despite this limitation, the sub-delegations within an octet are very useful.  
    If there is a better way to describe this in the document, we are open to suggestions.  Thanks for your comments.

  - Joe and Dan

> 
> is not a subdomain of
> 
>  1.0.0.1.0.1.0.m.129.in-addr.arpa (for 129.82.0.0/15).
On Mar 5, 2013, at 5:11 AM, Ray Bellis wrote:

> 
> On 5 Mar 2013, at 01:24, Daniel Massey <massey@cs.colostate.edu> wrote:
> 
>> Hi,
>> 
>> We have an approach for naming IP prefixes and have been using the naming scheme for about a year now.       The scheme is documented at:
>> 
>> draft-gersch-dnsop-revdns-cidr-04.txt
>> 
>> Over the past several months,   we have incorporated feedback from users and also incorporated some past feedback from the working group.     We ask the community to take a look at the above draft and consider adopting the draft as a working group item.
> 
> I still find one aspect of this draft very troubling.
> 
> Having just written a script to test out the algorithm, I find that it still has the property that the generated prefix for "/M" is not a sub-prefix of that for "/N" if "M" is not within the same octet boundary as "N".
> 
> For example:
> 
>  m.82.129.in-addr.arpa (for 129.82.0.0/16)
> 
> is not a subdomain of
> 
>  1.0.0.1.0.1.0.m.129.in-addr.arpa (for 129.82.0.0/15).
> 
> What I can't tell from the draft is whether this fails Design Requirement 3:
> 
> "Coverage Authority: With the exception of data that has been sub-
> delegated to a child zone, the reverse DNS zone must be
> authoritative for all sub-prefixes below the covering prefix.
> Any query for a sub-prefix must be answered with a data record or
> NXDOMAIN specifying this zone as the authority."
> 
> I posted the exact same concerns to DNSOP last May and June but there were not addressed.
> 
> kind regards,
> 
> Ray
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

Joseph Gersch
Chief Operating Officer
Secure64 Software Corporation