forwarding zone setup from a BIND slave (without recursion?)

Tony Finch dot at
Wed Apr 7 14:37:33 UTC 2021

Chuck Aurora <ca at> wrote:
> A stub or static-stub zone would not require recursion.  In that case
> named is asking for authoritative data from upstream.  But type
> forward zones indeed cannot work if recursion is disabled.

Be careful in this kind of situation to be very clear about which client
or server is doing what: in this case, it isn't clear what doesn't require
recursion for stub or static stub.

All three types of zone configuration (stub, static stub, and forward)
are only useful on a server that is providing recursive service.

Forward zones require the upstream server to be recursive too.

Stub and static-stub expect the upstream server to be authoritative;
the stub server list is a hint that gets replaced by the authoritative
server list from the zone (a bit like the root hints) whereas static-stub
only uses the configured upstream servers.

> > What I've learned from this list is that you should split
> > authoritative and recursive service.
> I would suggest that as a general best practice, but not an absolute
> one.  There's nothing wrong with having internal-only authoritative
> zones on your recursive resolver.  The potential problem comes when
> you're a globally-published NS for your zones; having recursion
> enabled can make you vulnerable to more possible attacks.

Right: the rule is that authoritative servers listed as targets of NS
records should be authoritative-only; it's OK if recursive servers have
authoritative copies of zones: it can make them more resilient to outages,
though it does slightly weird things to DNSSEC validation.

f.anthony.n.finch  <dot at>
Whitby to Gibraltar Point: Northwest 4 to 6 becoming variable 2 to 4,
then southwest 4 to 6 later. Very rough at first in north, otherwise
moderate or rough. Snow showers, then rain for a time later. Good,
occasionally very poor at first.

More information about the bind-users mailing list