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

[Chuck Aurora]

On 2021-04-07 03:59, Marki wrote:
> To elaborate a little bit on that... Indeed that is how it works,
> unfortunately. When you start using forwarders or stubs, recursion
> needs to be enabled because you're no longer looking for your own
> authoritative data only.

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.

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

I'd say it depends more who/what you are.  Small-timers are not at so
much risk for this than large sites and ISPs.  But there too, the
paranoid would go for two instances of named, authoritative and
recursive, on a small hosted server even where it's only offering
recursion to itself.

> May I ask what is the reasoning behind your current setup (pointing
> your users to the non-recursive service)? What would you like to
> achieve? What would you like to prevent?

Agreed, that is strange.  It does not seem that an authoritative-only
named can be very useful for end users.