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. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
