A resolver for your devices, not an open amplifier.

Choose the role

A recursive resolver such as Unbound and a filtering interface such as AdGuard Home solve related but distinct problems. Decide whether the service recurses itself or forwards to an upstream and understand which party then sees queries.

Keep it private

An unrestricted public resolver can be abused for reflection attacks. Bind to a private network or allow only authorised sources, including IPv6. If using encrypted DNS, authenticate or otherwise restrict access appropriately instead of assuming HTTPS makes it private.

Set a logging policy

DNS queries can reveal sensitive browsing and application activity. Disable unnecessary retention, protect the records you keep and explain the scope to users. Encrypted transport protects a path; it does not prevent the resolver itself seeing queries.

Test more than one name

Verify DNSSEC behaviour where enabled, IPv4 and IPv6 results, filtering exceptions and recovery when an upstream fails. Keep a secure way to fix access without depending exclusively on the resolver you are repairing.

Prove strangers cannot query it

Bind the resolver to the intended interface, define the permitted client ranges and restrict the firewall. Validate configuration before restarting. Query it from an authorised client, then repeat from outside the trusted network: that request should be refused or time out. Check IPv6 separately. A resolver that accepts arbitrary internet queries can become a source of abuse.

• Run the configuration validator before applying changes
• Test a permitted client and a denied client
• Keep verbose query diagnostics temporary

unbound-checkconf

Official documentation: Unbound access-control configuration

Keep encrypted DNS claims precise

DNS-over-HTTPS or DNS-over-TLS encrypts a particular transport path. The resolver still receives the query, and a forwarding resolver can pass it to another operator. Review upstream choice and retention. If you expose an encrypted resolver endpoint, make its access policy as deliberate as the ordinary DNS port.

Choose the resolver chain before opening a port

A useful private design is a VPN client querying AdGuard Home, with AdGuard forwarding to Unbound on loopback. Unbound then performs recursion; AdGuard adds filtering and a management interface. Alternatively use only Unbound for a smaller stack. Give each listener a distinct address/port and draw the forwarding direction: sending Unbound back to AdGuard creates a loop. Decide which private clients may use the service before publishing anything.

• Keep public inbound TCP and UDP 53 closed unless there is a specific authorised-client policy.
• Give the filtering interface and DNS listener separate access rules.
• Check port ownership before installation; an existing system resolver may already bind the intended address.

Official documentation: AdGuard Home setup

A loopback Unbound starting point

On a system with Unbound already installed, the following fragment illustrates a backend reachable only on the host. Integrate it with the distribution configuration rather than overwriting package settings or trust-anchor management. The high port lets another DNS frontend use port 53. Validate the complete effective file, then reload through the installed service manager. A remote client needs a separately controlled tunnel or frontend; this fragment intentionally creates no public resolver.

server:
  interface: 127.0.0.1
  port: 5335
  access-control: 127.0.0.0/8 allow
  access-control: 0.0.0.0/0 refuse
  access-control: ::0/0 refuse

# Validate the complete installed configuration:
unbound-checkconf

Official documentation: Unbound configuration reference

Run an acceptance checklist from two networks

First query the backend locally, then the normal client path. Check ordinary A/AAAA records, a deliberately nonexistent name and DNSSEC validation using a documented test domain. Repeat from a machine outside the permitted subnet: it must not receive recursion. Review whether a browser uses its own encrypted resolver and bypasses the configured device DNS. Keep a temporary independent resolver available during the change so a DNS mistake does not remove your administration route.

• Local diagnostic: dig @127.0.0.1 -p 5335 example.org A
• Inspect both UDP and TCP reachability, plus IPv6 listeners.
• Confirm filtering exceptions and record only the diagnostics actually needed.

Diagnose timeouts, loops and validation failures

A frontend timeout with a working local backend suggests the frontend address, firewall or forwarding target. Repeated self-directed queries suggest a loop. Widespread DNSSEC failures can involve incorrect system time or trust-anchor maintenance; fix the cause rather than leaving validation disabled. If only large replies fail, investigate TCP fallback and the network path. Keep query logging temporary, and test a restart and configuration restore before making the resolver a dependency for every device.