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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
