On May 16, 2016, at 5:35 PM, MegaBrutal <megabru...@gmail.com> wrote: > > 2016-05-16 19:45 GMT+02:00 Alan Clegg <a...@clegg.com>: >> On 5/16/16, 1:30 PM, "MegaBrutal" <bind-users-boun...@lists.isc.org on >> behalf of megabru...@gmail.com> wrote: >> >>> I want to have valid reverse & forward hostnames set up >>> for this /64 subnet. >> >> This is silly. Don't do this. > > Why? > > Most ISPs set up reverse & forward domain names for pool addresses. > OK, I'm not an ISP, but it really seems to be a widely accepted and > endorsed policy, to the point that addresses not having a reverse DNS > often treated as suspicious.
I’ve expected IPV6 would drive away the demand for PTR records for personal devices. I’ve been generating PTR records for decades, beginning when servers began using PTR-existence as a sign of legitimacy. This includes providing reverse pointers for every address in a dynamic pool. I've figured “demanding PTRs” would go away with IPV6 since SLAC (and sheer size) makes the idea of providing them less than feasible. Since security-conscious apps and library routines will need other changes to handle IPV6, it’ll be natural to eliminate something that would be both difficult and useless. I figure the number of clients without PTR records will tip a balance and servers will no longer be able to afford to demand them. Auto-generated individual PTR records for large pools are a whole lot like no pointer records at all, and seem to me like busy work. Though perhaps an unvaried PTR that shows “this address is in a pool, and not a static address” would offer useful info, perhaps with a DNS wildcard entry (if you line up your pool with a CIDR block)? For individual devices that are offering to accept connections, dynamic DNS could be useful: if someone connects to you and is willing to receive connections, an individual PTR record let you could find out their name first. These comments don’t apply to PTR records for individual servers. John Wobus Cornell University IT _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
