Avoid RFC 2317 style delegation.

Mark Andrews Mark_Andrews at isc.org
Thu Aug 26 01:28:22 UTC 2004


> 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-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 at isc.org


More information about the bind-users mailing list