Hi Lee,
Some comments below, based on a fairly cursory skim through (so, I may well
have 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 UPDATE
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 might
previously have been used by someone else, and hence the blah.blah.ip6.arpa
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 vast
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
speculation :-)
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 as a
recursive server. If that's really a requirement, that ought to be spelled 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,
which is contrary to general best practice. Quite possibly that's a reasonable
trade-off in this case (poor link quality affecting DNS resolution would also
affect the ability of the customer to use the network) but the trade-off should
be mentioned.
The conclusion that this is not an option for residential ISPs assumes sysadmin
requirements on the part of the user, incidentally. If this convention was
widely deployed in home gateways, users wouldn't need to care.
2.5 Dynamically Generate PTR When Queried ("On the Fly")
The DNSSEC commentary is a bit weird. Keys are associated with zones, not with
RRSets. Keys would not need to be generated on the fly; I think you're talking
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 advice
to an ISP who is trying to find an analogue to "pre-populate all my IN-ADDR
zones containing customer addresses" as is commonly (whatever you think about
it) done in IPv4. I don't think that's generally a fault of the draft; I think
this is just an operational consideration that was not well-explored during the
development of IPv6. There are potentially additional requirements for hosts,
routers, DHCPv6 and RADIUS in here.
Perhaps a more useful approach (if there is consensus that more work is
required in this area) would be to work on a requirements document for the
solution 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 <l...@asgard.org> 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
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
