Re: Avoid RFC 2317 style delegation.

> At 3:43 +0000 8/25/04, Jonathan de Boyne Pollard wrote:
>
> >superdomain to avoid RFC 2317-style delegation, because it breaks quite
> >a few such features.
>
> News to me...so, looking at
>
> <URL:http://homepages.tesco.net./~J.deBoy...c-2317-delegat
> ion.html>
>
> # If one employs RFC 2317 style delegation, one cannot test one's content
> # DNS servers directly using dig with the -x option. One is instead required
> # to determine by hand what reverse lookup domain name to use (which will, of
> # course, vary according to the specific private syntax that is being
> employed),
> # and explicitly provide that to dig.
>
> That's not true, try "dig -x 69.25.34.196"

It's version dependent. "dig -x 69.25.34.196 ptr" will work for
all versions and matches the behaviour of gethostbyaddr() /
getnameinfo().

The original authors of dig wanted "dig -x 69.25.34" to get the
NS record so they used "*" rather than PTR which matches any
record type but does *not* follow CNAMES.

This is a case of not understanding the tool rather than a
bad solution.

> # If one employs RFC 2317 style delegation, the feature of djbdns that allows
> # one to specify both address->name and name->address mappings with a single
> # database record, and thus automatically keep them the inverses of each othe
> r,
> # is rendered useless. The record will create the address->name mapping using
> # the standard RFC 1035 reverse lookup domain name. But because of the RFC 23
> 17
> # style delegation, this datum will never actually be used. One is instead
> # required to determine by hand what reverse lookup domain name to use, and
> # explicitly create a second database record.
>
> That's an problem with an implementation's DNS management tools, not
> DNS. I'd bet that even djb servers and resolvers can handle it. (I
> have no hands on experience with the code.) I bet you could overcome
> this easily though. (I.e., seeing what's at in the reverse map
> before writing to it, changing the place you write to it there's a
> CNAME there.)
>
> # If one employs RFC 2317 style delegation, the feature of Microsoft's DNS
> # server that allows one to create both address->name and name->address
> # mappings at the same time is rendered useless. The address->name mapping
> # is created using the standard RFC 1035 reverse lookup domain name. But
> # because of the RFC 2317 style delegation, this datum will never actually be
> # used. One is instead required to determine by hand what reverse lookup
> # domain name to use, and explicitly create a second database record.
>
> Same problem, again, I don't (even) have access to MS DNS.
>
> # If one employs RFC 2317 style delegation, the feature of Microsoft's DNS
> # server that ensures that the related address->name mapping is deleted
> # when a name->address mapping is deleted is rendered non-functional. The
> # server attempts to delete the address->name mapping that uses the standard
> # RFC 1035 reverse lookup domain name. But because of the RFC 2317 style
> # delegation, this is not the right thing to be deleting. One is instead
> # required to determine by hand what reverse lookup domain name to use, and
> # explicitly delete the relevant database record.
>
> This is a problem in the interaction between DHCP and DNS. I have
> seen that. I have also seen other problems with dynamic update of
> DNS by ISC's DHCP - it erases what's in the reverse map, assuming
> you'd never want more than one PTR record there. This is something
> to think about.

It more a matter of telling dhcpd the correct place to
update. If that fails then file a bug report against dhcpd.
It is actually pretty easy to cope with RFC 2317 style
delegations if you program for it.

Make a SOA query for 1.2.3.4.in-addr.arpa. If you get a
CNAME in the response adjust the names of the PTR records
from the default then use those to discover the enclosing
zone.

> # If one employs RFC 2317 style delegation, the features of Microsoft's DHCP
> # clients and DHCP servers, whereby the address->name mappings for machines'
> # IP addresses are automatically created and destroyed (via dynamic DNS) as
> # the IP addresses are assigned to and removed from the machines, are rendere
> d
> # non-functional. The address->name mapping is registered (by the Microsoft
> # DHCP client or DHCP server) using the standard RFC 1035 reverse lookup
> # domain name. But because of the RFC 2317 style delegation, this datum will
> # never actually be used. There is no workaround for this problem.
> # Address->name lookups will simply not be updated dynamically and
> # automatically as IP addresses are assigned to and removed from machines.
>
> I think this is related to the one above.
>
> So, even avoiding djb and MS software (not necessarily recommending
> that, but this is a BIND list), you might have a problem with DHCP
> dynamically updating the reverse map when using RFC 2137. I wish we
> had thought of testing that in January 2002 at the workshop in
> Amsterdam.
>
> (The results of that workshop are documented at
> http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html).
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis +1-703-227-9854
> ARIN Research Engineer
>
> "I can't go to Miami. I'm expecting calls from telemarketers." -
> Grandpa Simpson.
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org