Using DNAMEs for RFC2317-like delegations - DNS

This is a discussion on Using DNAMEs for RFC2317-like delegations - DNS ; 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. ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Using DNAMEs for RFC2317-like delegations

  1. Using DNAMEs for RFC2317-like delegations

    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@cam.ac.uk


  2. Re: Using DNAMEs for RFC2317-like delegations

    Chris Thompson writes:

    > 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:


    DNAMEs really do work.

    > $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


    $GENERATE 0-127 $ DNAME $.0-127

    > 128 DNAME 128.28-191
    > ...
    > 191 DNAME 191.128-191


    $GENERATE 128-191 $ DNAME $.128-191

    > 192 DNAME 192.192-255
    > ...
    > 254 DNAME 254.192-255
    > 255 DNAME 255.192-255


    $GENERATE 192-255 $ DNAME $.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.


    yes.

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


    yes.
    --
    Paul Vixie


  3. Re: Using DNAMEs for RFC2317-like delegations

    On Jul 30 2008, Paul Vixie wrote:

    >Chris Thompson writes:
    >
    >> 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:

    >
    >DNAMEs really do work.
    >
    >> $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)

    [...]
    >$GENERATE 0-127 $ DNAME $.0-127
    >$GENERATE 128-191 $ DNAME $.128-191
    >$GENERATE 192-255 $ DNAME $.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.

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

    >
    >yes.


    Example(s) in the public DNS? So that I can point at it/them, and say
    "look, it doesn't cause any problems for John Doe's networks: why don't
    we start doing it like that?" ?

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



  4. Re: Using DNAMEs for RFC2317-like delegations

    > Example(s) in the public DNS? So that I can point at it/them, and say
    > "look, it doesn't cause any problems for John Doe's networks: why don't
    > we start doing it like that?" ?
    > --
    > Chris Thompson
    > Email: cet1@cam.ac.uk


    for starters, .


    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.



  5. Re: Using DNAMEs for RFC2317-like delegations

    On Jul 30 2008, Paul Vixie wrote:

    >> Example(s) in the public DNS? So that I can point at it/them, and say
    >> "look, it doesn't cause any problems for John Doe's networks: why don't
    >> we start doing it like that?" ?
    >> --
    >> Chris Thompson
    >> Email: cet1@cam.ac.uk

    >
    >for starters, .


    Well yes, but ip6.int doesn't exist any longer, so I can't hold it up
    as an "example in the public DNS".

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


  6. Re: Using DNAMEs for RFC2317-like delegations

    > >for starters, .
    >
    > Well yes, but ip6.int doesn't exist any longer, so I can't hold it up
    > as an "example in the public DNS".


    ah. most unfortunate. this worked for years in the public dns.

    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.



+ Reply to Thread