Using DNAMEs for RFC2317-like delegations

[Chris Thompson]

On Jul 28 2008, Matus UHLAR - fantomas wrote:
>On 28.07.08 15:00, Tomasz Pajor wrote:
>> I want to split [a /16] to one /17 and two /18, how can I do that?
>
>it would be horrible and complicated. Just use /16's, 256 reverse zones for 
>0.b.a.in-addr.arpa
>1.b.a.in-addr.arpa
>...
>255.b.a.in-addr.arpa
>
>and first (or last) 128 will be for the /17, first half (64) of the rest
>will be first /18, remaining will belong to second /18

That's the conventional advice, of course, but does lead to a proliferation
of reverse zones. It seems to me that if one believes that DNAMEs really do
work (by virtue of the synthesized CNAMEs), then one ought to be able to use
them in an RFC2317-like way in cases like this:

$ORIGIN b.a.in-addr.arpa.
@       SOA ...
        NS  ...
0-127   NS  (delegation for the /17)
128-191 NS  (delegation for the first /18)
192-255 NS  (delegation for the second /18)
0       DNAME 0.0-127
1       DNAME 1.0-127
...
127     DNAME 127.0-127
128     DNAME 128.28-191
...
191     DNAME 191.128-191
192     DNAME 192.192-255
...
254     DNAME 254.192-255
255     DNAME 255.192-255

and then the delegatees have only three zones

  0-127.b.a.in-addr.arpa.
  128-191.b.a.in-addr.arpa.
  192-255.b.a.in-addr.arpa.

to look after, each of which they populate as if they were (incomplete) 
reverse zones for b.a.in-addr.arpa.

This is only a thought experiment: has anyone actually tried to do
something like this?

-- 
Chris Thompson
Email: cet1 at cam.ac.uk