On 3/9/2021 6:03 PM, Tony Finch wrote:
Marki <bind-us...@lists.roth.lu> wrote:
I am seeking a combination of either a combined configuration on one, or a
config of several different DNS servers together to achieve the following:
* Some clients should be able to resolve authoritative local zones as well as
some forwarded zones.
* Other clients should be able to resolve all of that _plus_ be able to make
recursive queries to the internet (or use a global forwarder).
In my opinion, as a rule of thumb it's best to avoid per-zone forwarding
in BIND. (Microsoft DNS really encourages it, but be wary because it
doesn't mean the same thing there!)
It's helpful if you have a clear distinction between authoritative-only
nameservers on the one hand, and on the other hand recursive nameservers
that provide service to stub resolvers. It sounds like you want to provide
an internal-only sandbox to some recursive clients, but it's best to think
of it as a restricted recursive service, not a special kind of
authoritative service. Especially because stub clients expect to receive
fully-resolved answers, so if you point them at an authoritative-only
server you'll get obscure problems in cases like cross-zone CNAMEs.
[ The distinction is that auth-only servers expect to receive only RD=0
(recursion not desired) queries from recursive DNS servers and reply with
RA=0 (recursion not available), whereas recursive servers expect to
receive RD=1 (recursion desired) from stub resolvers and reply with RA=1
(recursion available). ]
When you need to tie authoritative zones together, use delegation records
pointing at your authoritative-only name servers. Then your recursive
servers can just follow delegations in the usual way without special
configuration. (If you are doing split DNS, this can get fiddly, which is
a good reason for keeping your split DNS as simple as possible.)
[ You can configure recursive servers to have their own authoritative
copies of your zones - it can be faster and more resilient - but you can
think of it as a shortcut or optimization, on top of the fundamental
auth/rec split. ]
Your question is now, how to provide a restricted recursive service?
The top-level setup is to have multiple views with match-clients clauses
to determine whether a client is in the sandbox view or not. Then the
question is how to configure the sandbox view.
I don't know of any particularly good ways in BIND :-) When you want
default-allow with a block list, then RPZ is ideal, but you are asking for
default-deny with an allow list.
You might be able to configure a dummy default forwarder, and tell BIND it
is bogus, something like this (which I have not tested!):
forwarders A.B.C.D;
server A.B.C.D {
bogus yes;
};
then have per-zone static-stub configuration for allowed zones, pointing
at working authoritative servers.
Alternatively it might be easier to make other software such as dnsdist do
what you want. Or, consider implementing the sandbox with firewalls at the
network level. (But are you sandboxing DNS because of worries about
data exfiltration?)
Tony.
You're right about the sandbox and exfiltration (C2 etc.). What can't go
out, can't hurt. We don't need public DNS resolution on most client
systems since all Internet access is filtered through an explicit proxy.
Thus, why not just turn it off instead of trying to protect it using
expensive appliances and whatnot.
Concerning static-stub: Using a (bogus) forwarder together with "forward
first" (default) seems to work (Note: using "forward only" gives
SERVFAIL). All outside requests get a SERVFAIL even with "forward first"
but that's an esthetic problem. Another approach might be to disable
forwarders altogether (make it fully recursive) and then use RPZ. This
would however mean that stubs/forwarded zones would need to be
whitelisted, which means one or two more lines of configuration (and a
nice reply from the server).
As you mentioned there would be other view(s) for clients that actually
need public DNS. Correctly firewalling means blocking everything unless
it is allowed (whitelisting principle). I'm not sure about the
flexibility of RPZ; it doesn't seem that I can have rules like "client
1.2.3.4 is allowed to look up example.com but client 1.2.3.5 is not".
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
