[dns-wg] Policy for Reverse DNS for End-User PA Addresses?

Jon Lawrence wrote:
> ISP's/LIR's should be required to provide reverse DNS. Even if it's just a 
> generic reverse such as adsl-xx-xx.isp.com

Although generic reverses does help in some ways, it could also be 
argued that they do not provide much real information. In my opinion it 
will only make sense to make reverse DNS mandatory, if the end user can 
decide that the information should be useful, i.e. that addresses 
resolve to corresponding canonical hostnames.

> No privacy issues aren't irrelevant.
> When I got my IP range at home, I wasn't informed that my details could 
> potentially appear in a public registry - they didn't in the end, although 
> there is an inetnum for my range it's fully admin'd by my ISP and doesn't 
> contain any of my details.
> Privacy issues must be addressed, and there is actually no reason why the end 
> user's details need to be associated with the inetnum.

Sorry, I did not mean that privacy issues are irrelevant.

What I (and the draft) ment was that there are no privacy issues with 
reverse DNS as long as you can find the end user for an IP address 
through whois.

Whether the whois database should allow anonymised inetnum objects is 
another discussion.

But of course there will be privacy issues if otherwise anonymous IP 
addresses are forced to have reverse DNS pointing to something personal. 
  Thanks for pointing that out - I had not thought of that, since I 
started the other way around, wanting to ensure that end users could 
have relevant reverse DNS if they wanted.

In practice, however, this is should not be a problem. Even if you can 
be identified though domain X, there is usally no practical way for the 
ISP to know that you have made a hostname in that domain point to one of 
your IP addresses. Unless you instruct your ISP to make reverse DNS 
point for your addresses to something specific, they usually will have 
no choice but to let it point to a generic reverse.


Best regards,


Jørgen E. Larsen
CTO
Elgaard Data
jel(at)elgaard.net