When working on dnsconfd, we have uncovered a problem configuration of forwarding via unbound-control. If we try to use unbound-control explicitly, there does not seem to be a way to tell unbound to not use root hints.
I can configure forwarding when starting unbound via configuration file and use forward-first: no. The problem is I cannot do the same, if unbound should be started before we know exact forwarders to use. For example I want to serve localhost and built-in authoritative zones, but until I know forwarder address and possible TLS status of it, I cannot configure forwarder at startup.
I have found there is a trick to make queries to outer hosts fail, until forwarders are configured.
forward-zone:
name: "."
forward-first: no
Problem is, after I use "unbound-control forward 192.0.2.53", followed by "unbound-control forward off", root hints are used back again. It does not seem to be possible to return back to original configuration. Not by simple reuse of unbound-control forward, at least. Or is there?
Is there some other way in latest unbound releases, how to tell unbound to use only forwarders configured or fail always?
I have tried this on unbound-1.19.0, but I expect that has not changed since then.
This behavior is needed to use only some trusted protective DNS service, which might have applied some protective query filter (RPZ) applied. Therefore iteration from root is not acceptable, as it could circumvent such filter. Most likely something with TLS authentication endpoint.
"unbound-control forward" is very specific as it operates implicitly on a '.' zone. When you add a forward that zone is implicitly changed. When you turn it off that zone (which is the one configured in the file) is removed.
What I would do instead is configure forwarders as desired from the get-go or through unbound-control.
Then for access control I would use
local-zone: "." deny/refuse
in the configuration file.
And when your forwarders are ready you can remove the local-zone via unbound-control to let queries flow into Unbound.
You can also add that local zone via unbound-control if you want to block queries while changing something.
Of course with whatever you configure on the upstream proper cache management may need to happen, unless you want your forwarders without caching any data with 'forward-no-cache: yes'.
Problem is, after I use "unbound-control forward 192.0.2.53",
followed by "unbound-control forward off", root hints are used back
again. It does not seem to be possible to return back to original
configuration. Not by simple reuse of unbound-control forward, at
least. Or is there?
What if you configure unbound with an "empty" root-hints file ?
I think unbound has built-in hints, which it will use unless something else is specified. So I doubt empty file will change its behavior.
Specifying something bogus could prevent it, but local-zone as proposed by Yorgos seems more maintainable solution.
Something like:
server:
local-zone: "." "refuse"
Seems to work similar way as dnsmasq, when it does not have forwarders configured. But responds with local data known, for example localhost.
A bit problem is if I define just subdomain forwarding, it will still return REFUSED.
But if I configure also local-zone: "test" "nodefault", where "test" is the subdomain with forwarders, it work well. And we do not have to publish false hints this way.
I think we just miss batch adding via unbound-control, if multiple commands need to be used for a single domain.
It will, the built-in hints are only used if no explicit 'root-hints:' configuration is defined. So providing non-working root hints will render Unbound unable to resolve. Even for configured forward and stub zones as priming needs to happen before going out to the network.
Things that don't need recursion will still work like local-zones, auth-zones (for downstream only), and rpz (triggers which don't rely on recursion) will continue to work.
I think unbound has built-in hints, which it will use unless
something else is specified. So I doubt empty file will change its
behavior.
Yes, it does, that's why I clarified my point by posting a simple
example of an "empty" root hints file
Specifying something bogus could prevent it, but local-zone as
proposed by Yorgos seems more maintainable solution.
I'd rather use a different approach, by using NSD for the local zones
and setting up UnBound to forward to NSD for such zones AND for the
root zone at startup, then once things settle, change UnBound to use
the preferred forwarders, then as a note I prefer carrying on full
recursive resolution using UnBound and perform filtering there, instead
of relying on external DNS resolvers