The last piece I added to my home DNS stack turned out to be the most important

Earlier in 2026, I finally got around to setting up my own DNS. The whole point was that I wanted to boost my privacy. I swapped out Cloudflare, ditched my ISP's default resolver, and built a stack with AdGuard Home handling filtering and Unbound doing full recursive resolution — meaning my queries went directly to authoritative nameservers with no middleman involved.

But one part of the configuration bothered me.

Full recursion means your DNS queries leave your network in plaintext. Your ISP can see every domain you're resolving as the traffic passes through its infrastructure. So, that was the next step to close.

What DNS-over-TLS actually does

And why is this a tradeoff?

Part of what prompted me to look into this was reading the DNSCrypt-Proxy GitHub, which encrypts DNS requests using the DNSCrypt protocol. More encryption typically equals more privacy from prying eyes, and that's typically a good thing.

But it turns out, Unbound, which is already part of my DNS stack, can do something similar using DNS-over-TLS, encrypting the connection between your resolver and the upstream DNS server it queries. That doesn't mean DNSCrypt-proxy isn't useful, but it's probably overkill for my home solution.

In plain terms, instead of your DNS queries traveling in plaintext over port 53, they're wrapped in a TLS connection on port 853 — the same encryption that protects HTTPS traffic. Your ISP sees encrypted data going to a known DNS server IP, not a readable list of every domain you're visiting.

So, in this case, DoT can forward DNS requests to a third-party resolver like Quad9, which protects your requests from your ISP and other network snooping. However, it's a trade-off. You're effectively replacing trust in one entity with another. Do you trust Quad9 (or another secure DNS provider) or your ISP more?

With full recursion, no single entity sees your complete query history — queries are distributed across hundreds of authoritative nameservers. With DoT forwarding, that changes. The ISP is excluded, but one company now holds the full picture.

How to update your DNS configuration

AdGuard and Unbound stay exactly as they are

For me, nothing about my existing DNS stack really changes, other than the introduction of Quad9. My devices still talk to AdGuard Home, AdGuard still filters and blocks, and AdGuard still forwards clean queries to Unbound.

The only change is what Unbound does with those queries — instead of recursing from root servers in plaintext, it forwards them to Quad9 over an encrypted TLS connection.

Configuring Unbound for DNS-over-TLS

It only takes a few lines added to your configuration to make the changes.

1. First up, open the Unbound configuration file on your DNS container using nano /etc/unbound/unbound.conf.d/local.conf
2. When the configuration file opens, under server:, add the following line: tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt

This tells Unbound where to find the system's CA certificate bundle, which it needs to verify Quad9's TLS certificate during the handshake. Without it, the connection will fail with a certificate verification error.

Then, add the following block at the bottom of the file, after the existing server configuration:

forward-zone:

name: "."

forward-tls-upstream: yes

forward-addr: 9.9.9.9@853#dns.quad9.net

forward-addr: 149.112.112.112@853#dns.quad9.net

forward-first: no

Here's what all of that does:

• name: "." applies this forward zone to all DNS queries — the dot is DNS notation for the root
• forward-tls-upstream: yes tells Unbound to use TLS when connecting to the forwarders
• The two forward-addr lines are Quad9's primary and secondary DoT endpoints — @853 specifies the DoT port, and #dns.quad9.net is the TLS hostname used for certificate verification
• forward-first: no tells Unbound not to try direct recursion if forwarding fails

Now, save the file with Ctrl+O, Enter, Ctrl+X. Then, validate the config with unbound-checkconf. If it returns no errors, restart Unbound with systemctl restart unbound, and everything should be working as normal.

Verify everything is working as it should

The next step is to verify that the whole configuration is working, and Unbound and Quad9 are resolving properly.

In the console, input dig google.com @127.0.0.1 -p 5335.

You should see a NOERROR status with an answer section containing IP addresses. If you get SERVFAIL, check the Unbound logs with the journalctl -u unbound -n 50 --no-pager command.

The most common failure is certificate verify failed, which means the CA bundle path is wrong or the package isn't installed. Run apt install -y ca-certificates and make sure the tls-cert-bundle line points to /etc/ssl/certs/ca-certificates.crt.

Once the dig test returns answers, check your AdGuard Home dashboard under Settings → DNS settings. You should see Quad9 appear in the upstream metrics, which confirms the full chain is working and your queries are flowing through AdGuard, Unbound, and out to Quad9 over TLS.

How to revert your changes

It's okay to change your mind

If you decide full recursion better suits you, or you just want to go back to how things were,the revert is straightforward. Open the config file again and delete the entire forward-zone block, along with the tls-cert-bundle line from the server section. Save, validate, and restart with the following command:

unbound-checkconf && systemctl restart unbound

Unbound goes back to querying root servers directly; no single upstream resolver sees your full query pattern, and your ISP is back to seeing unencrypted fragments in transit. Neither setup is objectively better, as they protect against different things, and the right choice depends on your own threat model.

Whether or not you want to roll back really depends on how you view privacy. In that, the full recursion model with Unbound is strong if you want to stop a single party building a full picture of your online activity. But if your main concern is your ISP, a network admin, or someone intercepting traffic between you and your resolver, DoT closes that gap entirely.