Forward zone not working

MegaBrutal megabrutal at
Mon May 16 17:30:30 UTC 2016

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 [] 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 "" {
    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!


More information about the bind-users mailing list