Forward zone not working

Fri May 20 21:09:20 UTC 2016

> -----Original Message-----
> From: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org]
>  On Behalf Of John Wobus
> Sent: Friday, May 20, 2016 3:08 PM
> To: bind-users
> Subject: Re: Forward zone not working
>
> On May 16, 2016, at 5:35 PM, MegaBrutal <megabrutal at gmail.com> wrote:
> >
> > 2016-05-16 19:45 GMT+02:00 Alan Clegg <alan at clegg.com>:
> >> On 5/16/16, 1:30 PM, "MegaBrutal" <bind-users-bounces at lists.isc.org
> >> on behalf of megabrutal at 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.

John,

This is exactly what some colleagues and I are working to get a handle on.
We see this as becoming a larger and larger issue especially as IPv6 adoption
increases.  We have had several customers already request generics at /96 and
larger blocks as they are accustom to doing with IPv4.  From a sheer marketing
perspective $GENERATEs with PTRs "brand" the IPs to a network and a few other
ISPs already have hacks in place to provide similar functionality so why drive
away potential customers?  Just because something seems silly?  Why not go and
give your money to the provider that doesn't think your business is silly.

We could have (with much less effort) hacked this functionality into bind or
another implementation but felt our customers could legitimately benefit from
being able to transfer these records back and forth between their systems,
our systems and even others so they should have the same capability as we did.
This was our motivation, to attempt to free the technology and work toward an
actual standard everyone could benefit from.

<promo>
The below referenced I-D for "BULK" records:
  * Provides "generics" which are automatically generated based on a set of rules.
  * The records have similar features as wildcards where they may be superimposed
    an appear only where more specific records do not already exist.
  * There are provisions for DNSSEC support of BULK generated records.
  * Can be done at any place in the DNS tree and overridden throughout the tree.
  * Can be easily AXFRed between servers.
  * Have immeasurably lower memory footprint compared with $GENERATEs (esp. IPv6).
</promo>

I can't tell you how many times $GENERATEs have bitten us where a customer requests
a singleton record to be placed in the middle of a $GENERATE and it had to be
split into several smaller $GENERATEs (always middle of the night).  This among
many other legitimate (or not) uses even with much smaller ranges than the
IPv6 world.

But full disclosure... I am biased :)

Regards,
--
John Woodworth                           CenturyLink, Inc.
  Q. What acts like a $GENERATE with records in between??
  A. BULK CAN
[ http://tools.ietf.org/html/draft-woodworth-bulk-rr-01 ]

> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.