Authority and forwarding, but not recursion/iteration

[Marki]

On 3/9/2021 6:03 PM, Tony Finch wrote:
> Marki <bind-users at 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