The Problem: Plain DNS Hides Nothing
When a device asks “what’s the IP for example.com?”, that query and its answer are readable by anyone who can see the traffic: your ISP, anyone on the same Wi-Fi, a coffee-shop router, a man-in-the-middle. It has some serious implications:
- Privacy. Every domain you look up is visible in transit, even if the connection that follows is HTTPS. DNS is the part of “secure browsing” that historically wasn’t secure at all.
- Tampering. Because there’s no authentication, a network in the middle can rewrite the answer - redirecting
bank.comsomewhere else, or just returning a “not found” response to block access. This is how some ISPs implement parental controls, and how some governments implement censorship.
Encrypted DNS fixes the first problem and, as a side effect of using TLS, gets you most of the second one too (the response is coming from a server whose certificate you can verify).
DNS-over-TLS (DoT)
DoT does exactly what it says: takes the same DNS protocol and wraps it in a TLS session, on its own dedicated port.
- Port 853, separate from everything else.
- The DNS query/response format is unchanged - just encrypted in transit.
- Because it’s a dedicated port, a network operator can trivially identify and block it: firewall off 853 and DoT is dead in the water (falling back to plain port 53, if the client allows it).
That last point is DoT’s defining trade-off - clean and simple, but easy to spot and easy to block.
DNS-over-HTTPS (DoH)
DoH takes the same idea - encrypt the query - but tunnels it inside a normal HTTPS request instead of giving it its own protocol.
- Port 443, same as every other HTTPS website.
- A DNS query becomes an HTTP request to a URL like
https://1.1.1.1/dns-query(that URL you set as AdGuard’s upstream in the previous post). Google runs one too at https://dns.google/ - open it in browser, get JSON API for manual lookups, not just the DoH endpoint.
Want to see DoH firsthand? Open https://dns.google/, type facebook.com in search box. That page fires DoH query itself and shows raw JSON answer back.
- To a network watching traffic, a DoH lookup is indistinguishable from any other HTTPS request. There’s no separate port to block, and blocking it means blocking the whole resolver’s IP - which, when that IP is Cloudflare or Google, means blocking a lot of collateral traffic too.
This is also why browsers embraced DoH directly: Firefox and Chrome can ship their own hardcoded DoH resolver and quietly bypass whatever DNS the OS or router hands out, because from the network’s perspective it’s just another HTTPS connection to Cloudflare.
DoT vs DoH, Side by Side
| DoT | DoH | |
|---|---|---|
| Port | 853 (dedicated) | 443 (shared with HTTPS) |
| Identifiable on the wire | Yes - distinct port | No - blends with normal web traffic |
| Easy to block at a firewall | Yes | Only by blocking the resolver’s IP entirely |
| Typical user | Network admins, routers, resolvers (AdGuard, Pi-hole) | Browsers, OS-level “Private DNS” |
| Protocol shape | Native DNS-over-TLS | DNS wrapped in HTTP(S) |
Neither is “more encrypted” than the other - same TLS underneath. The difference is entirely about what the traffic looks like to an observer, and that’s the whole reason DoH exists: to make encrypted DNS unblockable-in-practice.
Where This Fits Into the AdGuard Setup
Worth being precise about which leg of the journey actually gets encrypted, because it’s easy to assume “AdGuard does DoH” means the whole chain is encrypted end to end. It doesn’t - there are two separate legs:
- Device → AdGuard. Every phone, laptop, and TV on the LAN still talks to AdGuard over plain old UDP port 53, unencrypted. That’s fine - it’s your own trusted network, and AdGuard needs to see these queries in the clear anyway, since filtering domains and logging them is the entire point of running it.
- AdGuard → upstream. This is the leg that’s actually encrypted. When AdGuard doesn’t already know the answer, it forwards the query to Cloudflare or Quad9 over DoH/DoT - so what your ISP sees is one encrypted HTTPS-shaped connection from your home lab to
1.1.1.1, not a stream of plaintext lookups for every domain your household visits.
So the mental model from the previous post holds: AdGuard is a trusted local resolver you’re choosing to let see everything (that’s how ad-blocking works), and DoH/DoT’s job is only to protect the second half of the trip, out on the public internet.
The browser bypass, explained. In the previous post we flagged that Android’s “Private DNS” and some browsers quietly skip whatever DNS your router hands out. Now the mechanism is obvious: those features point straight at a DoH/DoT resolver of their own (Google, Cloudflare) instead of the DHCP-provided one, so the query never reaches AdGuard at all - no filtering, no *.home.arpa resolution, and it looks identical to normal HTTPS traffic, so you can’t even block it at the router without blocking the resolver’s whole IP range.
Fix is the same as before: turn Android’s Private DNS to Automatic, and in Firefox disable “Enable DNS over HTTPS” under Settings → Privacy & Security (Chrome: Settings → Privacy and security → Security → Use secure DNS → off, or set it to “With your current service provider” so it defers to AdGuard).
Configuring AdGuard Home
Turning on DoH/DoT for the upstream leg is a Settings → DNS settings change, no restart needed.
- Open AdGuard Home web UI, go to Settings → DNS settings.
- In Upstream DNS servers, replace plain entries with DoH/DoT strings, one per line:
https://dns.cloudflare.com/dns-queryhttps://dns.google/dns-queryhttps://dns.quad9.net/dns-querytls://9.9.9.9tls://unfiltered.adguard-dns.comhttps://...lines are DoH.tls://...lines are DoT.- Keep more than one line - AdGuard falls back to the next upstream if one fails.
- Scroll down, click Test upstreams to confirm each one resolves.
- Click Apply.
To confirm AdGuard is actually using DoH/DoT and not silently falling back to plain port 53, open Query Log, click any entry, check the DNS server field in the response details - it should show the full https://.../dns-query or tls://... upstream, not a bare IP on port 53.
Wrap-Up
Plain DNS is cleartext and trivially snooped or tampered with. DoT fixes that on its own dedicated port - simple, but blockable. DoH fixes the same thing while disguising itself as ordinary web traffic - unblockable in practice, which is exactly why browsers adopted it directly and why it occasionally fights with a home DNS setup instead of cooperating with it. In an AdGuard Home setup, DoH/DoT only ever protects the AdGuard-to-internet leg; the LAN-to-AdGuard leg stays plain by design, because AdGuard has to see those queries to do its job.
