> -----Original Message----- > From: Ted Lemon [mailto:[email protected]] > Sent: Wednesday, November 28, 2012 4:23 PM > To: Lee Howard > Cc: <[email protected]> > Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) > > On Nov 28, 2012, at 3:51 PM, Lee Howard <[email protected]> wrote: > > 2. Delegation: Several people support delegating to the home gateway. > > a. There is no mechanism to tell a home gateway that it is now > > authoritative for "12345.customer.example.net." Or is there? Without > > that, it also wouldn't know what FQDN to put in PTR RRs. > > b. Violates RFC6092 REQ-8. > > c. Delegating to a single auth nameserver may or may not be acceptable. > > d. (from v6ops) ISP should slave from customer CPE > > The really good point that you almost made here is that the CPE device doesn't necessarily > have an FQDN zone to update, and if it is delegated the PTR zone and doesn't have anything > to stuff into it, it might stuff something harmful into it. So it would be good to advise > against that. > > Then the question of what forward zone to publish is interesting; I'd assumed that the ISP > would never be involved in this. I suppose some ISPs might want to offer this as a service, > so it would be worth documenting how they ought to do it.
Without explicit caution, the CPE might populate .local for FQDN. Yes, I assumed that everyone knew that residential users rarely have their own domain name, and would have to get it from their ISP. I don't think ISPs especially want to provide this--there's no gain and lots of potential pain. > > There is a draft that documents how the reverse zone could be set up (as part of the DHCP > PD process). If we think there's a real use case for the ISP offering the customer a zone, we > should define a way for the ISP to do this (I'd suggest a DHCP option, since we're > presumably doing DHCP PD to delegate a prefix). We might want to check with some ISPs and see if they would be interested in consuming such a spec. I doubt many would--it's something to troubleshoot that offers little value to the residential user. > > 3. Document the problems with #2(a) and #3(a) above. Since there is > > currently no mechanism, no requirements document, and no charter to > > change these limitations, this provides the best information available > > at this time. > > 4. Write a requirements document to fill gaps in #2 and #3. This may > > coincidentally fall into work spinning off from 6renum. I would very > > much like co-authors for this, since I will not be able to give it my > > full attention. > > I have some interest in this topic and would be willing to write some docs, although you > might not agree with the docs I would write. Then it would be healthy for us to collaborate! Maybe we can drive compromise positions before making the WG(s) thrash. Lee _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
