Forward zone not working

John Wobus jw354 at
Fri May 20 19:08:13 UTC 2016

On May 16, 2016, at 5:35 PM, MegaBrutal <megabrutal at> wrote:
> 2016-05-16 19:45 GMT+02:00 Alan Clegg <alan at>:
>> On 5/16/16, 1:30 PM, "MegaBrutal" <bind-users-bounces at on
>> behalf of megabrutal at> 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

More information about the bind-users mailing list