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

Crist Clark cjc+bind-users at pumpky.net
Sun Apr 18 20:45:12 UTC 2021


So why doesn’t it work to make your limited server authoritative for the
root and only forward the zones you want? Anything that isn’t in a
forwarded zone does not exist (except the root itself).

On Sat, Apr 17, 2021 at 11:07 PM Marki <bind-users at lists.roth.lu> wrote:

>
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210418/89067067/attachment.htm>


More information about the bind-users mailing list