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 <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
Joseph Gersch
Chief Operating Officer
Secure64 Software Corporation
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
