questions on allow-query
each at isc.org
Wed Feb 21 00:28:55 UTC 2018
On Tue, Feb 20, 2018 at 11:41:37PM +0000, Darcy Kevin (FCA) wrote:
> Call me a contrarian, but I've never really signed onto the conventional
> wisdom that recursive and authoritative roles should never be mixed, even
> as I've transitioned into the InfoSec realm, where, generally speaking,
> we are quite wary of mixing roles within a single service (more software
> complexity leads to higher probability of defects, a bigger attack
> surface, and so on).
I agree with this. There are circumstances when it's convenient. For one
example, adding an empty authoritative zone to your resolver is a handy
way to stop certain classes of DDoS attack from eating up your recursive
Many years ago BIND could leak cache information when set up this way.
The allow-recursion ACL would prevent unauthorized clients from causing
named to recurse to look up information, but if the information was
already cached, it would return it just fine. The introduction of the
allow-query-cache ACL put a stop to that, back in 9.4 I think.
I was one of the early authors of the late lamented BIND10/Bundy, and my
recollection is we decided to separate the auth and recursive functions for
reasons of code simplicity and performance, not security. Most other
DNS implementations have done the same, and I suspect it was for the
same reasons, not because there's anything really wrong with mixing
One thing to keep in mind, though, is that the two services will share each
other's fates. If I were deploying a really big high-traffic server, I
might consider whether I wanted my recursive service to have to wait for
all the zones to load before it could function, or whether I wanted to have
to update my authoritative server because it was vulnerable to a crash bug
in the recursive code.
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.
More information about the bind-users