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.deBoynePollard/FGA/avoid-rfc-2317-delegation.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"

# 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 other,
# 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 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.

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.

# 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 rendered
# 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.