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
