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. -- f.anthony.n.finch <d...@dotat.at> https://dotat.at/ Irish Sea: South or southwest 4 to 6, increasing 7 to severe gale 9 for a time. Slight or moderate, becoming rough or very rough for a time. Rain. Moderate occasionally poor. _______________________________________________ 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