Forward zone not working

[Woodworth, John R]

> -----Original Message-----
> From: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of MegaBrutal
> Sent: Monday, May 16, 2016 1:31 PM
> To: bind-users at lists.isc.org
> Subject: Forward zone not working
>
> Hi all,
>
> I have an IPv6 reverse PTR zone for a /48 subnet delegated to my BIND
> server, and one of its /64 subnets are used with SLAAC + Privacy Extensions.
> I want to have valid reverse & forward hostnames set up for this /64 subnet.
> Generating 2 ^ 64 reverse & forward records for BIND would be wasteful if
> not impossible, so I found out that another DNS server, AllKnowingDNS
> [http://all-knowing-dns.zekjur.net/] is built for this particular purpose.
> So far so good, I set up an AllKnowingDNS on another IP address, and delegated
> the /64's PTR zone for it.
>
> It seemed to work at first, but then I discovered that PTR resolutions are
> not reliable. Some services are unable to resolve my reverse PTRs.
> You know, in 2016, I assumed that the majority of recursive DNS servers are
> IPv6-ready (especially those that deal with IPv6 reverse PTRs – I thought
> services those see my IPv6 address and want to reverse-resolve it, most
> probably have access to IPv6-enabled recursive NS-es), so I didn't see any
> problem with having only an IPv6 address for my AllKnowingDNS server. I was wrong.
>
> So let's see my options:
> 1. Reserve a public static IPv4 address for my AllKnowingDNS server. I simply
> can't afford that. IPv4 addresses are expensive.
> 2. Configure my BIND to forward the reverse PTR requests for the reverse /64
> zone to the AllKnowingDNS server, and directly answer queries on its behalf.
> Since my BIND is dual-stack, it would have no problem with receiving requests
> on its IPv4 interface and forwarding them on IPv6. Dnsmasq can easily do that
> (to forward requests for specific zones to specific NS servers), but I don't
> have public Dnsmasq anywhere around, all my authoritative name servers are BIND.
>
> So this how I came around to try a forward-type zone:
>
> zone "y.y.y.y.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" {
>     type forward;
>     forward only;
>     forwarders { zzzz::zzzz; }; // IPv6 address of AllKnowingDNS.
> };
>
> Where x substitutes digits of my /48, y substitutes digits of my /64, and z
> substitutes digits of the AllKnowingDNS IPv6 address.
>
> It simply doesn't work. In query logs, I see BIND treats requests for the zone
> as if they were requests for recursion, thus rejects them appropriately. DiG
> backs this up with "status: REFUSED". It doesn't seem like if BIND does any
> effort in forwarding the zone, it just treats it as non-authoritative, which
> would need recursion, and of course recursion is very properly disabled. It's
> like the zone entry weren't even there.
>
> Does anyone have any insights or suggestions?
>
> Thanks in advance!
>

MegaBrutal,

Unfortunately, I don't have an answer for "how to do this today" but I have an
I-D in the works targeting the scalability of large datasets with an emphasis on
the IPv6 namespace (http://tools.ietf.org/html/draft-woodworth-bulk-rr-01).

We've spent a lot of time and effort developing our solution and hope to gain
some traction so for others that might ask this next year I can have an answer.

We are also working on our own implementation for bind and unbound which I would
be glad to share once it is mature enough.


Regards,
John

>
> MegaBrutal
> _______________________________________________
> 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.