Again,
unless there is impact to a 3rd party, putting local use addresses in the
global DNS is none of the IETF's business.
If you look at the case 1) below, that for certainty is a case which would impact third parties.
1) putting in local addresses to global DNS names which are expected to be used by outsiders who are not interested of local addresses, or to whom local addresses could even mean a service degradation. (e.g., www.example.com, smtp.example.com, etc.etc.)
2) putting in local addresses for names which are not expected to be used (e.g., "canada.vpn.example.com", to perform some kind of "auto-discovery" functions) except who know which hostnames those are and know what they're doing.
You guys seem to be confusing two very different things:
a. putting these addresses in the forward DNS tree b. putting these addresses in the reverse DNS tree
Now obviously a. can be harmful, but this is immaterial as anyone can do this today anyway.
I don't see how b. can be harmful in any way: only when someone has a reason to look up a certain addresses, she will see whether it's there or not. So as long as the addresses don't leak out, there is no problem. And if the addresses DO leak out, being able to look them up is a plus.
The only logical conclusion is that for registry assigned unique site local addresses, the registry MUST provide the registree with the option of registering reverse DNS servers.
As for randomly generated mostly-unique site locals... I think it would make sense to synthesize reverse DNS servers inside the address range in question here.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
