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

[Frederico A C Neves <[e-mail]>]

On Fri, Mar 30, 2012 at 10:19:43AM +0000, Ray Bellis wrote:
> 
> On 30 Mar 2012, at 12:09, Ond??ej Surý wrote:
> 
> > 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.
> 
> +1

I'm not quite sure 2317 can be used for shorter prefixes but it's
actually only seen in the wild for /25 onwards. The proposed idea
works for any prefix outside the 8 or 4 bit boundary depending on what
family we are talking.

> > 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.
> 
> With the current scheme it's possible to delegate longer prefixes, and this is a necessary feature.
> 
> The stuff Dan was saying about two alternate representations concerns me, though.  As written, by default:
> 
>   192.168.64/18 is 1.0.m.168.192
> 
> but
> 
>   192.168.64/24 is 64.168.192
> 
> which is not a sub-domain of the enclosing /18 representation.
> 
> This way lies dragons, I think...

If your parent have't made their mind I agree with you, but this is
very unlekely.

> Ray

Fred