Paul Vixie wrote:
As far as I know there's no mechanism to delegate reverse DNS for a locally
generated ULA, since there's no "ownership". IMO any move to start
delegating .arpa authority for ULAs would be de facto ULA-C, so if we're
going to do that we should do it right and do the other registration
functions that should go along with the DNS delegation.
not to disparage either participant shown above personally, but, this
argument is beyond nuttiness. mark andrews has a draft out about local
domain name service for RFC 1918, and his fundamental observation is
that there is no need for the resolution perimeter of a PTR to differ
from the routing perimeter of the IP address described by that PTR.
Feel free to disparage me as a newbie as appropriate. :-)
Can you point me to the name of the referenced I-D? Unfortunately I
haven't had time to closely follow new I-D's, and am only involved in
this discussion because of my ARIN PPML involvement.
yet here we have a large set of folks who unlike mark andrews are not experts
at DNS, telling us that yes we do need to be able to resolve a PTR from
places where the addresses won't be routable, and then using this ignorant
and false assertion to justify a global registry of unique but unreachable
address blocks, each having its own globally reachable nameservers for PTRs.
what's wrong with this picture? is there a use case we can all study?
Maybe the I-D answers this, but how do you resolve PTRs for some random
section of .arpa if you don't have glue NS records pointing you to the
name servers for that subdomain? In terms of use case, say my network
connects privately to a network using ULAs. I traceroute to a host on
that network, and try to resolve PTRs for the ULA block. If the block
is ULA-C, my DNS server (which may be a completely independent local
instance of BIND without forwarders) can traverse the tree from the
root, get the proper delegations to the NS's for the ULA-C (which will
need to be on public IPs), and resolve the PTRs. If the block is local
ULA, however, I don't know how my independent local resolver is supposed
to find out which name servers are authoritative for the ULA block.
I guess what it comes down to is that the intended use case for ULA-C is
to connect a bunch of companies with private address space on a private
network. In that kind of use case, close integration of DNS
infrastructure seems unlikely, so without delegating DNS authority from
the root, I don't see how you can provide good reverse DNS resolution in
such a use case. Therefore, I support draft-ietf-ipv6-ula-central-02's
requirement to support DNS delegation, with the caveat that such
delegation must be to public addresses (that NS records should not point
to ULAs).
Thanks,
Scott
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
