reverse dns problems

[Mark.Andrews at nominum.com]

> 
> MK> And how would you go about resolving names in the 208.21.15.0/25
> MK> network, when your server is set as authorative for reverse DNS on
> MK> 208.21.15.128/25 and in effect all of 208.21.15/24?
> 
> WY> On a theoretical level, this is probably a Bad Thing, [...]
> 
> On a practical level, if one follows the recommendation in the _DNS & BIND_
> book (as I said, the page number that I remember is 321, or somewhere
> thereabouts), the supposed difficulty simply doesn't exist.
> 
> WY> It seems like CIDR is enough of a reality now that there should 
> WY> be a more elegant solution than the CNAME hack; [...]
> 
> The whole scheme in RFC2317 is based upon the mistaken notion that delegation
> s
> must always be to zone apices, and the difficulties for BIND (in the
> subdomains) that arise as a consequence.

	Delegations must be to zone apexs otherwise it is not a delegation.

>  But if one follows the
> recommendation given in the _DNS & BIND_ book to have separate content and
> proxy DNS services, this notion simply isn't true and the difficulties *don't
> *
> arise.  As such, one can perform classless "in-addr.arpa." delegation in the
> same manner that one performs delegations for forward lookup zones.  There's
> no need at all for any CNAME records, domain names with slashes or extra
> hyphens, extra delegation points in the namespace, or other complications. 
> It's very simple and it *is* elegant.  (Well, it is just as elegant as
> delegations in forward domains are, and as the whole "in-addr.arpa." scheme
> itself is, at any rate.  (-:)
> 
> <URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/avoid-rfc-2317-delegat
> ion.html>
> 

	The BIND example in this page will not work.  You were
	depending upon bugs which have long since been removed.

	What you are recommending is dangerous as it can result in
	data from one namespace polluting another namespace,
	especially if they don't follow your example to the letter.

	Please do not "recommend" this again as the obvious "fix"
	to get it working with modern BINDs will cause namespace
	leakage and will result in servers being unable to lookup
	reverse addresses.

	We have enough problems with rogue servers claiming to
	server "com", we don't need to add "in-addr.arpa" as well.

	RFC 2317 keeps everything in one namespace.  Your method
	involves deliberate namespace leakage and is not safe.

	Mark
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com