Smart Home Privacy
Router DNS: DoT vs DoH for Smart Home Privacy 2026
Compare DNS-over-TLS and DNS-over-HTTPS on routers and Pi-hole: visibility, blocking effectiveness, TLS inspection limits, and how to stop IoT bypassing your resolver.
Quick answer: Should smart home DNS use DoT or DoH on the router?
DoT on port 853 is simpler to firewall and identify. DoH on port 443 hides DNS inside web traffic—harder for ISPs to inspect but also harder for you to block selectively without HTTPS inspection. For IoT control, pair a local resolver (Pi-hole/AdGuard) with firewall rules that redirect hardcoded DNS to your hub.
Source: IETF DoH specification
Executive Summary
DNS-over-TLS (DoT) wraps DNS in TLS on TCP/853. DNS-over-HTTPS (DoH) sends queries as HTTPS to resolvers on 4431. Both encrypt DNS from local eavesdroppers, but they change policy: parental controls, malware blocking, and visibility for network admins.
This guide targets readers running OpenWrt, OPNsense, or ISP routers who want consistent filtering for IoT VLANs. Read Pi-hole vs AdGuard and blocking IoT DNS leaks first.
Bottom line: Use DoT upstream from your recursive resolver when you want clear firewall rules; use DoH when you must traverse hostile networks that block 853—inside the home LAN, DoT + local RPZ is usually simpler.
Protocol mechanics at a glance
| Property | DoT (RFC 7858) | DoH (RFC 8484) |
|---|---|---|
| Transport | TCP 853 | HTTPS 443 |
| Looks like web | No | Yes |
| Easy to block by port | Yes | Harder |
Privacy from ISP vs privacy inside the LAN
DoT/DoH hide query contents from ISP if clients use them end-to-end. However, your Pi-hole still sees plaintext queries before forwarding—by design for filtering2. The privacy win is on-path snooping on Wi-Fi, not hiding data from your own resolver.
Router CPU and TLS overhead
Cheap routers may struggle with many TLS sessions for DoH. DoT can be lighter on some stacks, but both add latency versus plain UDP DNS3. For gigabit LANs with dozens of IoT devices, prefer dedicated Pi/mini-PC resolvers—not the ISP box.
Blocking effectiveness: why DoH complicates policy
Parental controls and malware blocklists traditionally intercept UDP/53. DoH bypasses naive DNS firewalls unless you block known DoH endpoints or use split-horizon TLS inspection (rare on home gear)4. DoT is easier: allow only your resolver’s 853 to trusted upstreams.
| Control goal | DoT | DoH |
|---|---|---|
| Block DoH exfiltration | Easier | Needs domain lists / SNI filtering |
| Guest VLAN safety | Allow only Pi-hole | Same, but more leak vectors |
Integration patterns with Pi-hole and AdGuard Home
Typical stack: Clients → Pi-hole (53) → Unbound recursive OR DoT upstream. AdGuard Home can also proxy DoH upstream while serving plain DNS locally5. Document which hop decrypts traffic for compliance reviews.
OpenWrt and OPNsense deployment notes
OpenWrt dnsmasq + Stubby is a common DoT client pattern; OPNsense can use Unbound with TLS forwarders. Compare firmware flexibility in OpenWrt vs stock before relying on vendor GUIs.
Enterprise-style alternative: DNS filtering without DoH arms race
Some households avoid DoH entirely on IoT VLANs by denying outbound 443 to non-essential IPs—breaks the web, so it is rarely viable. More realistic: allowlist IoT vendor CDNs with automation or segment devices that require DoH (streaming sticks) onto separate SSIDs.
Mobile and browser DoH overrides
Modern browsers may enable DoH independently of OS DNS settings6. That bypasses Pi-hole unless you disable secure DNS in the browser or deploy group policy / managed profiles. Mobile OSes may also use private DNS (Android) pointing straight to dns.google—set Private DNS = Automatic only after you trust DHCP.
Monitoring and logging
Log blocked queries and NXDOMAIN spikes to detect malware DGAs. Export metrics to Grafana or keep 30-day logs minimum for incident review—align retention with your household privacy policy.
Checklist
- Inventory which VLANs must use the local resolver only.
- Create firewall redirects from UDP/53 and TCP/53 to Pi-hole except the resolver host.
- Log blocked DoH providers and review weekly for new endpoints.
- Measure CPU on the router after enabling TLS upstreams.
- Document upstream resolver privacy policies for household transparency.
FAQ
Frequently Asked Questions
Is DoH always more private than DoT?
Both encrypt to the resolver; privacy depends on the resolver’s logging and your threat model, not only the transport.
Can I run DoH only for laptops and DoT for IoT?
Yes—per-VLAN DHCP options and client profiles can split policies; keep documentation so future-you understands the layout.
Does DoH break Pi-hole?
Only if clients skip Pi-hole entirely; force DHCP to hand out Pi-hole as DNS and firewall alternate paths.
Should I enable DNSSEC too?
DNSSEC validates authenticity; pair with encrypted transport—see resolver docs for combined setup.
What about DNS over QUIC?
Emerging transport—evaluate router support and blocking strategy similarly to DoH.
Primary sources
| ID | Source | URL |
|---|---|---|
| 1 | RFC 8484 DoH | ietf.org |
| 2 | RFC 7858 DoT | ietf.org |
| 3 | Mozilla DoH FAQ | support.mozilla.org |
Conclusion
DoT and DoH both raise the bar for passive surveillance, but home policy still flows through your resolver. Start with Pi-hole/AdGuard on a dedicated host, add VLAN firewalling, then choose DoT unless you have a specific reason to blend DNS into HTTPS traffic. For full-stack design, revisit private network stack.
Footnotes
-
DoH encapsulates DNS queries in HTTPS requests; DoT uses a dedicated TLS port 853 per RFC 7858. ↩
-
Local filtering resolvers necessarily observe query names to apply blocklists. ↩
-
TLS handshakes add latency versus UDP DNS; hardware acceleration varies by platform. ↩
-
Selective blocking of DoH providers requires maintained domain/IP lists or advanced middleboxes. ↩
-
AdGuard Home documentation describes upstream encryption options for outbound queries. ↩
-
Browser vendors document optional DNS-over-HTTPS settings that can override system resolver configuration. ↩