Unbound may be active in systemctl but not serve any requests from the workstation. On a Debian or Ubuntu VM, the symptom is common: the service is running, but DNS requests remain slow, or an application resolves nothing.
Before modifying /etc/resolv.conf or disturbing systemd-resolved, first perform a local diagnosis. Check the configuration and the port, then query Unbound directly. The system’s DNS remains in place during these checks.
Read the configuration before touching port 53
On Debian and Ubuntu, the main configuration often goes through /etc/unbound/unbound.conf, with inclusions in /etc/unbound/unbound.conf.d/. Do not assume that Unbound is listening on 127.0.0.1:53.
Port 53 may already be taken by systemd-resolved, dnsmasq, or BIND. The risk is straightforward: by changing the system resolver too early, you may cut off the workstation’s DNS resolution while Unbound is not listening in the right place.
sudo unbound-checkconf /etc/unbound/unbound.conf
sudo unbound-checkconf -o interface /etc/unbound/unbound.conf
sudo unbound-checkconf -o port /etc/unbound/unbound.conf
sudo ss -lntup 'sport = :53'unbound-checkconf reads the configuration and returns an error if a directive blocks the loading. According to the official man page, a return code 0 validates the file. The options -o interface and -o port display the actual values.
ss shows the process that is actually listening. If you see 127.0.0.53:53 on the systemd-resolved side while Unbound should respond on 127.0.0.1:53, you have a concrete conflict to address.
Before making a modification, keep a readable copy of the main file:
sudo cp -a /etc/unbound/unbound.conf /etc/unbound/unbound.conf.before-local-testQuery Unbound without changing the workstation’s DNS
An active service is not enough. Unbound may listen on a different interface, use a different port, or fail to respond because upstream servers or DNSSEC are problematic.
The service status and the startup logs provide the first sorting. Then send a request to the local resolver, without going through the system’s DNS configuration:
sudo systemctl status unbound --no-pager
sudo journalctl -u unbound -b -n 50 --no-pager
dig @127.0.0.1 example.net A +noall +comments +answer
dig @127.0.0.1 example.net A +noall +statsAdapt 127.0.0.1 and add -p 5335 if your configuration shows a different port. A response with status: NOERROR and a section ANSWER proves that Unbound has responded for that name.
connection refused refers to the service or the port. SERVFAIL indicates that the daemon received the request but could not resolve the name. Logs help to separate network failures, DNSSEC validation, and upstream server configuration.
Then re-run the same request. A shorter time on the second pass may come from Unbound’s cache. This test does not measure the resolver’s performance; it only confirms that you are talking to the right instance.
Connect the system resolver only after the direct test
If dig @127.0.0.1 responds but applications still fail, Unbound is probably not in the chain used by the system. Read this chain before modifying the network.
resolvectl statusdisplays the DNS known by systemd-resolved.resolvectl query example.nettests the resolution from the system resolver.cat /etc/resolv.confshows the file presented to traditional applications.
On a server, I would keep Unbound on a documented address and port, then connect the system resolver once the direct tests are validated. On a workstation, systemd-resolved can remain in front of Unbound if this layer simplifies Wi-Fi, VPN, or network profiles.
A local test does not say anything about the public resolution of the domain. Before putting an application behind a Caddy reverse proxy with HTTPS, also check the response seen from the Internet.
The unbound-checkconf documentation covers configuration checks. The official guide for the local resolver details integration with the system. Keep the backup until the direct test and the system test yield the same result.