> Paul Vixie wrote:
> >
> >> As far as I know there's no mechanism to delegate reverse DNS for a locall
> y
> >> 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 exper
> ts
> > 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.
You publish D.F.IP6.ARPA and C.F.IP6.ARPA and maintain delegations
within them for all the ULA (L or C) networks that are reachable.
Each site then becomes a slave.
zone "C.F.IP6.ARPA" {
type slave;
masters { FC...; };
file "C.F.IP6.ARPA"
};
zone "D.F.IP6.ARPA" {
type slave;
masters { FD...; };
file "D.F.IP6.ARPA"
};
The only question is who maintains the D.F.IP6.ARPA registry
you are using. Yourself, someone else in your group of
networks or the RIRs. C.F.IP6.ARPA already excludes the RIRs
from this role.
> 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
> --------------------------------------------------------------------
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
