Lee, I think this is reasonable.
(I'd actually like to go further and say "there is no expectation that there is a PTR for any address", but I recognize this is a minority view.) ;) Cheers, -- Shane On Wed, 13 May 2015 10:57:21 -0400 Lee Howard <l...@asgard.org> wrote: > I'm revising draft-howard-isp-ip6rdns again. Several folks have said > something like, "There should be no expectation that a residential ISP will > populate PTRs for all of its customers." When I started this document, five > or six years ago, there didn't seem to be consensus on that point. I hear a > lot of support for it these days, and disdain for people who rely on PTRs. > (I think we generally agree that PTRs for servers are good). > > Is there consensus now that ISPs don't need to provide PTRs for their > customers? > > Thanks, > Lee > > > From: Shumon Huque <shu...@gmail.com> > Reply-To: <shu...@gmail.com> > Date: Wednesday, April 1, 2015 at 10:05 PM > To: Alain Durand <alain.dur...@icann.org> > Cc: Lee Howard <l...@asgard.org>, "dnsop@ietf.org" <dnsop@ietf.org> > Subject: Re: [DNSOP] draft-howard-isp-ip6rdns-07.txt > > > On Tue, Mar 31, 2015 at 4:31 PM, Alain Durand <alain.dur...@icann.org> > > wrote: > >> > >> 3) There is another solution, that is do nothing, i.e. Do NOT populate the > >> reverse tree. > >> Probably ISPs on that path would like to see an update to RFC1033 & > >> RFC1912 to > >> explicitly say that the PTR record requirement is relaxed in IPv6 (and > >> maybe > >> in IPv4 as well?) > >> > >> The mere fact that this draft is still here many years after the effort > >> was started should tell us somethingŠ It would appear as if the world is > >> on path 3) above. > > > > I agree with Alain. > > > > With widespread use of stateless address auto-configuration and privacy > > addresses, I don't think the blanket PTR requirements/recommendations in > > those > > old RFCs are practical or relevant to IPv6. They make sense for IPv6 servers > > and statically configured computers, but not dynamically configured clients. > > And it might make sense to update those documents not only to relax those > > requirements for IPv6, but also to dissuade IPv6 services deployers from > > using > > reverse DNS checks as a pre-condition to providing service. > > > > If the ISP is offering DHCPv6, they might be able to prepopulate the reverse > > DNS for a sufficiently small address pool. For non-residential/business > > customers that are planning to run servers, I assume they'd get static > > address > > assignments and either run their own DNS, and/or have the ISP configure > > static > > reverse DNS entries for them. > > > > When I was involved in running a large IPv6-enabled campus network, no > > client > > computers (predominantly using SLAAC/privacy addresses) got IPv6 PTR records > > and I never heard of any issues encountered by them in accessing IPv6 > > services. Same goes for many of my peers in the R&E world (many of whom were > > early adopters of IPv6). SMTP servers are one category of services where > > it's > > still popular to do client PTR checks even for v6, but most IPv6 clients > > don't > > deliver to mail servers directly (they usually talk to a submission server, > > where user authentication is the access control mechanism used, rather than > > PTR checks). > > > > Shumon Huque > > > > _______________________________________________ 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
