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

[Lars-Johan Liman <liman@sunet.se>]

dts@senie.com:
> Ask it another way: if folks are doing this already, should we
> encourage network operators to make sure inaddr at least functions
> properly so that IT is not contibuting to end user problems?

Well ... it's one thing to say "everyone does this, so therefore you
should too", but a BCP to me is really a "Best Current Practice",
meaning "this is what a bunch of enlightened experienced people think
is the best for the Internet". I'm not sure "doing what everybody else
does" is the best for the Internet.

I have no problems publishing an informational RFC stating the common
behaviuor on the 'net, and how to co-exist with it. But I would
hesitate to call it a BCP, unless there is proper technical motivation
for it.

The cause-consequence relationship is wrong in "applications do these
strange lookups, therefore give them what they want". It should be
"there is reliable reverse DNS, therefore applications are welcome to
use it", but the latter is sofar untrue. We want to make it true. To
do that we have to start with the first part of it, "there is reliable
reverse DNS". Now why do we have to provide reliable reverse DNS to
the applications?

Maybe I should formulate it thus: Why should an application be able to
expect proper data in the reverse DNS?

In the forward DNS case there is a logical answer. The domain name is
an abstraction layer, making it easier for humans to remember Internet
addresses and information pointers, and facilitating change of the
underlying infrastructure without changing these addresses. Now, what's
the counterpart of that in the rev-DNS case?

And, yet again: I _really_ honestly want to know! I've been looking
for this reason for _years_, and so far my logical brain is
dissatisfied. I'm willing to accept going to a BCP if I hear many
voices saying that my demands are too high, so please speak up,
working group! :-)

				Cheers,
				  /Liman