On 4/14/2021 12:44 AM, Sebby, Brian A. via bind-users wrote:
My situation is due to a security requirement. We have DNS servers at
our site running BIND that allow recursion, but I’ve been requested to
set up some additional DNS servers for another project that is
expected to **only** access the data that we’re authoritative for.
And of course …. there’s a chance that it might need to look up one or
two external zones. Essentially, what I really need is a recursive
whitelist that doesn’t tell BIND what clients are allowed to do
recursive lookups, but to limit BIND to only allow recursive lookups
on a very small list of allowed domains.
I was trying to set up a forwarding zone to forward queries to our DNS
servers that do allow recursion, but as I discovered (and as was
discussed earlier in the thread), if recursion is not allowed, then
forwarding is also not allowed. I had tried setting the
“allow-recursion” field to “localhost” and setting up a forward zone
to forward to 127.0.0.1, but that didn’t work either.
Hello,
So they do _not_ only look up internal/authoritative zones, but external
ones as well. (It's always the exceptions that kill you.)
I think we have previously established that there is not a good way to
do whitelisting using Bind, see the thread "Authority and forwarding,
but not recursion/iteration".
If you can live with non-allowed zones returning SERVFAIL (instead of
NXDOMAIN for example), then using a recursive service with a bogus
global forwarder and static stubs pointing to the
authoritative/non-recursive service might do the trick.
You might also be able to leverage RPZ if there are no complex
conditions associated to your rules (everyone will have the same
white/blacklists). You configure passthrough for the allowed zones and
deny the rest.
Alternatively, there is dnsdist which, while being a load-balancer,
could be considered the swiss army knife of DNS filtering.
Finally, some firewalls like Fortigates provide a "DNS filter" that lets
you define custom white and blacklists. Palo Altos currently are not
able to whitelist AFAIK.
Best regards,
Marki
_______________________________________________
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