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. 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). > 2. Support someone else writing a draft called "PTRs unnecessary" or > whatever. I have someone in mind. This is a waste of time—it will never get consensus. We've wasted time in this working group trying to do this in the past. > 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. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
