wrt: draft-ietf-dnsop-inaddr-required-00.txt

[Robert Elz <kre@munnari.OZ.AU>]

Sorry people, this draft is a total waste of time.

I'm an absolute supporter of properly running in-addr.arpa domains,
and if someone wanted to write an RFC to explain to people what they're
useful for, and why the data needs to be maintained, that would be fine.

But to pretend to make it a requirement (on anyone) to maintain the
things is just silly.

Worse than that, the doc just says that the data needs to exist, it
doesn't (and cannot rationally) say that it has to contain anything
particularly sensible, so

	1.0.0.127.in-addr.arpa	IN	PTR	127.0.0.1.

would be just a fine (and totally useless) PTR record to include (and
the point here has nothing to do with my choice of the loopback address
to use - that's just an arbitrary example - any other number could be used).

Similarly
	*.0.0.127.in-addr.arpa	IN	PTR	bogus.example.com.

would also satisfy the requirements, but is no use to anyone at all.

Then there's this paragraph ...

   Many applications use DNS lookups for security checks. To ensure
   validity of claimed names, some applications will look up IN-ADDR
   records to get names, and then look up the resultant name to see if
   it maps back to the address originally known. Failure to resolve
   matching names is seen as a potential security concern.

which doesn't seem to have any relevance whatever.   If the IN-ADDR
lookup fails (which is what is of concern to the draft) then there is
no name to look up the address of, and the stuff about comparing with
the originally known address is irrelevant.


Making any requirements in this area is close to hopeless, and attempting
to do so by specification is completely hopeless, those who don't care
will continue to not care, those who do care, don't need a requirement
like this.   The only ways to get people to have this done correctly are
straight out education (which this draft isn't), or by having things fail
to work if the in-addr.arpa zone isn't correct (the way that some FTP servers
used to refuse anonymous logins if the in-addr.arpa of the source wasn't
correct.)  Unfortunately, these days, getting anyone who could make a
difference to refuse connections for any reason at all is not likely to
have a lot of success - the advantage is all on the side of getting as many
people as possible to connect to your web server (which is almost all that
matters), not to prevent anyone getting there, unless they're doing you
active harm.

kre