A local caching DNS resolver with Unbound: access-control, forwarding, and DNSSEC validation

Goal

Run Unbound as a caching, validating DNS resolver for a network segment: decide who may query it, whether it recurses itself or forwards to an upstream resolver, and confirm DNSSEC validation is active.

Prerequisites

Unbound installed; a network segment whose hosts will point at this resolver; outbound access to the internet (for recursion) or to an upstream resolver (for forwarding).

Steps

1. In unbound.conf's server: clause, add an interface: line for the LAN address (by default Unbound listens on localhost only), then restrict who may query with access-control: lines, one per netblock plus an action. The netblock is given as an IP4 or IP6 address with a size appended for a classless network block; by default only localhost is allowed and everything else refused. refuse answers REFUSED, deny drops silently. Do not set a blanket allow on an internet-facing interface, since that turns the resolver into an open recursive resolver usable for DNS amplification.
2. Decide between recursion and forwarding. With no forward-zone: clause, Unbound resolves queries itself by walking the DNS hierarchy from the root. Adding a forward-zone: with name: "." and one or more forward-addr: targets instead sends queries to an upstream recursive resolver — that list of nameservers is used to forward the queries to, and Unbound still validates DNSSEC on the answers, provided the upstream returns the DNSSEC records.
3. Keep DNSSEC validation configured: set auto-trust-anchor-file: to a path the unbound user can write (Debian and RHEL packages already set one, seeded by unbound-anchor). It holds a trust anchor for the zone, tracked with RFC 5011 probes run several times per month, so the resolver needs to stay online often enough to refresh it.
4. Before reloading, validate syntax: unbound-checkconf checks the configuration file for the Unbound DNS resolver for syntax and other errors, without starting the daemon.
5. Reload the running resolver as root (unbound-control reload, which also flushes the cache, or a service restart). unbound-control needs control-enable: yes in a remote-control: clause plus either TLS keys created once with unbound-control-setup or a local Unix-socket control-interface.
6. Flush a stale or poisoned cache entry without restarting: unbound-control flush <name> removes the name from the cache, covering the common record types in one call.

Expected result

Queries from the configured network resolve and are cached; queries from outside it get REFUSED (or no answer with deny); dig +dnssec against a validated zone shows the AD flag, and a deliberately broken DNSSEC test domain fails to resolve instead of returning a spoofable answer.

Limits and test basis

unbound-checkconf catches syntax errors, not operational ones such as an unreachable forward target — test resolution after a reload, not only the config check. An overly broad access-control rule is a common source of resolver abuse; review it whenever the resolver moves to a new network. auto-trust-anchor-file needs the resolver to run continuously enough to complete RFC 5011 update probes; a resolver offline for a long stretch may need its trust anchor reseeded.