An Unbound resolver that answers recursion for every host on the internet is an amplification and reconnaissance service. access-control is the local decision that tells Unbound which clients may use which resolver operations. The default is conservative for a reason: an interface rule can expose a service, but the client policy decides whether that service becomes useful to an attacker.
The default is refuse
The Unbound configuration manual states that the default action for interfaces is refuse and that only localhost is implicitly allowed through the default behavior. That is a safe starting point, not proof that a host is closed. A configuration can add an allow rule for a subnet, a wildcard, or a management network that is larger than intended.
Actions have different observable behavior. deny drops the request. refuse returns a DNS refusal. allow permits recursive service, while allow_snoop also permits access to cached or nonrecursive data. Use the least action that supports the intended clients. An allow rule for an internal subnet should be tied to a documented resolver group, not written as an open fallback.
Matching is not a firewall chain
Unbound selects the most specific access-control match for the client address. Operators should document that behavior and test it with the same Unbound version in use. A firewall rule and an access-control rule answer different questions: one decides whether packets reach the process, the other decides whether the process will serve the client. Keep both, and do not assume that DNSSEC validation makes open recursion harmless.
The resolver must still be protected from unwanted control traffic. Bind the control interface to a local or management address, protect the control certificate and key, and restrict the Unix socket permissions. Review do-not-query-localhost and forwarder configuration. A resolver that accepts queries from everywhere can also be used to map internal names if it has access to private zones.
Test from several networks
Query from localhost, from an approved internal address, from an adjacent untrusted subnet, and from a public address if the deployment exposes one. Ask for a recursive name and a cached response. Confirm each result matches the documented action. Use dig or another client that preserves the response code. A timeout and a REFUSED response are different observations; record both.
Review logs for client address, query name, query type, response code, and cache status. Do not retain sensitive query names for longer than the investigation policy allows. Alert on a sharp rise in refused queries, unusual query types, or a new source range that begins probing the resolver.
Make exceptions expire
Access-control exceptions accumulate during migrations. A subnet allowed to forward during a data-center move can remain open long after the move. Store the rule owner, purpose, and review date in configuration management. Remove an exception when the client no longer needs it. Run a periodic external and internal check so the actual service matches the intended policy.
The resolver is a small service with a large view of naming and reachability. Keep the access policy narrow, test the actions rather than only the listening socket, and make each exception auditable.