|
|
 |
Re: [dns-wg] Policy for Reverse DNS for End-User PA Addresses?
- Date: Fri, 09 Jul 2004 22:14:38 +0200
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
|
|
 |
 |