In message <[email protected]>, Joe Abley writes:
> Hi Lee,
>
> Some comments below, based on a fairly cursory skim through (so, I may well h
> ave missed and/or understood things).
>
> 2.2 Wildcard match
>
> There is no mention of the issue of uniqueness. What do you do when you have
> five thousand different customers who all attempt secure dynamic updates with
> the name "macbook"? Or, what to do when you have two Nest thermostats in the
> same house (on the same network) both of which think their name is "nest"?
>
> If there was a possible solution where a customer device could auto-register
> a name using dynamic DNS, how would it know what nameservers to send the UPDA
> TE messages to? Extract the MNAME from the closest-enclosing SOA? How do you
> find the closest-enclosing SOA, bearing in mind that the address concerned mi
> ght previously have been used by someone else, and hence the blah.blah.ip6.ar
> pa owner name might already exist?
>
> 2.3.1 Dynamic DNS from individual hosts
>
> I think it should be mentioned that this is a niche scenario, and that the va
> st majority of customers today don't connect a single host directly to their
> DSL/cable/whatever modem. And alongside that, some study should be cited that
> has come to that conclusion based on actual measurements, rather than my spe
> culation :-)
Individual hosts should be doing dynamic DNS. Where that update
is sent to may change but all machines should be doing it and should
support TSIG as a minimum. They should also expect to see DNAME
and CNAME records. i.e. the update may be to a name other than
that produced by the address to IP6.ARPA (and IN-ADDR.ARPA) mapping.
Individual hosts should be able to work out where to send the updates
by querying the DNS to find the nameservers of the containing zone
after processing and DNAME/CNAME mappings. We shipped code sans
DNAME/CNAME remapping a decade ago that did this.
Darwin and Windows already support sending dynamic updates though
I don't believe they handle the presence of DNAME or CNAME.
> 2.3.2 Dynamic DNS through Residential Gateways
>
> I think this section makes an assumption that the place to send your UPDATEs
> to is the same DNS server that is handed out (e.g. via DHCP option) for use a
> s a recursive server. If that's really a requirement, that ought to be spelle
> d out (because I think in general it's unusual). Most ISPs hand out at least
> two such addresses. Can either one be used? If not, which one?
>
> 2.3.3 Dynamic DNS Delegations
>
> This approach would leave a single nameserver responsible for a delegation, w
> hich is contrary to general best practice. Quite possibly that's a reasonable
> trade-off in this case (poor link quality affecting DNS resolution would als
> o affect the ability of the customer to use the network) but the trade-off sh
> ould be mentioned.
Firstly there are multiple ways to do a "delegation".
* Use a DNAME to a namespace that is already delegated.
a.b.c.d.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA DNAME IP6.EXAMPLE.NET
* The traditional method using NS records.
> The conclusion that this is not an option for residential ISPs assumes sysadm
> in requirements on the part of the user, incidentally. If this convention was
> widely deployed in home gateways, users wouldn't need to care.
And with IPv6 I would expect most homes *will* get dynamic forward zones.
IPv6 *is* a game changer and people are still rooted in IPv4 think.
> 2.5 Dynamically Generate PTR When Queried ("On the Fly")
>
> The DNSSEC commentary is a bit weird. Keys are associated with zones, not wit
> h RRSets. Keys would not need to be generated on the fly; I think you're talk
> ing about signatures.
>
> 4.3 Considerations for Other Uses of the DNS
>
> I don't understand this section at all. What does it mean?
>
> General
>
> I don't feel that in its current form this draft provides much practical advi
> ce to an ISP who is trying to find an analogue to "pre-populate all my IN-ADD
> R zones containing customer addresses" as is commonly (whatever you think abo
> ut it) done in IPv4. I don't think that's generally a fault of the draft; I t
> hink this is just an operational consideration that was not well-explored dur
> ing the development of IPv6. There are potentially additional requirements fo
> r hosts, routers, DHCPv6 and RADIUS in here.
>
> Perhaps a more useful approach (if there is consensus that more work is requi
> red in this area) would be to work on a requirements document for the solutio
> n space.
>
> If the goal is rather to figure out practical advice which ISPs can use today
> to provide PTR records for their customers, then I think this draft needs to
> provide some more concrete advice.
>
>
> Joe
>
> On 2012-11-21, at 10:01, Lee Howard <[email protected]> wrote:
>
> > You may remember this draft from a couple of years ago. People keep asking
> > me what a residential ISP should do for IPv6 PTR records, and I keep
> > repeating what's in the draft.
> > The intent is to document existing solutions, since prepopulating PTRs like
> > we did in IPv4 doesn't work. Last time I brought it to DNSOP, there was
> > interest, but not necessarily as a working group document. Since it's been
> > a while, and the operator community is still asking for guidance, I've
> > updated it, and would like a renewed review of it as an individual
> > submission (unless this WG or v6ops wants it).
> >
> > Filename: draft-howard-isp-ip6rdns
> > Revision: 05
> > Title: Reverse DNS in IPv6 for Internet Service Providers
> > Creation date: 2012-11-20
> > WG ID: Individual Submission
> > Number of pages: 13
> > URL:
> > http://www.ietf.org/internet-drafts/draft-howard-isp-ip6rdns-05.txt
> > Status: http://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns
> > Htmlized: http://tools.ietf.org/html/draft-howard-isp-ip6rdns-05
> > Diff:
> > http://www.ietf.org/rfcdiff?url2=draft-howard-isp-ip6rdns-05
> >
> > Abstract:
> > In IPv4, Internet Service Providers (ISPs) commonly provide IN-
> > ADDR.ARPA. information for their customers by prepopulating the zone
> > with one PTR record for every available address. This practice does
> > not scale in IPv6. This document analyzes different approaches for
> > ISPs to manage the ip6.arpa zone for IPv6 address space assigned to
> > many customers.
> >
> > Thanks,
> >
> > Lee
> >
> >
> > _______________________________________________
> > DNSOP mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
