DNS Security: Configuring DNS-over-HTTPS & DNS-over-TLS

DNS is the phonebook of the internet — every time your browser resolves a domain name, that query goes to your configured DNS resolver. The problem is the transport: a standard query is sent unencrypted over port 53. Your ISP, your hotel Wi-Fi, and anyone running a packet sniffer on the same network can see every site you visit before you even load the first page.

We first ran this stack during a network privacy audit in 2024, and the encryption itself was the easy part. The real work was hunting the bypass paths that still leaked plaintext: a browser with its own DoH profile that ignored the system resolver, a mobile OS that quietly fell back to the carrier's nameservers on cellular, and a resolver daemon that let DHCP rewrite its config file on every reboot. None of those are bugs. Every one of them is a default that assumes nobody is listening.

Below is the exact path we run on Ubuntu 24.04 and Debian 12 servers, plus Android and desktop clients. Start from a clean state: snapshot your current configuration first, then apply changes one at a time.

1. Network Architecture & Data Flow

On a Linux desktop or server the stub resolver is usually systemd-resolved, and everything it does is declared in /etc/systemd/resolved.conf.

# Edit the resolver configuration
$ sudo nano /etc/systemd/resolved.conf

[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
FallbackDNS=8.8.8.8#dns.google
DNSSEC=true
DNSOverTLS=yes
Cache=yes

After saving, restart the resolver and verify:

$ sudo systemctl restart systemd-resolved
$ resolvectl status

Each line in the status output confirms a layer of protection. The key ones to check: DNSSEC: yes, DNS Over TLS: yes, and the DNS Servers line pointing at your chosen encrypted resolver — not the ISP default.

For applications that ignore the system resolver (Firefox, custom VPN clients), configure DoH directly:

# Firefox about:config — set these prefs:
network.trr.mode = 5          # 5 = TRR first, no fallback
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.trr.custom_uri = https://mozilla.cloudflare-dns.com/dns-query

2. Protocol & Configuration Deep-Dive

Verification must happen on the wire, not in theory. The table below covers the most common failure modes when deploying encrypted DNS.

Threat Vector	Impact	Remediation Action
Local DNS Cache Poisoning	Stub resolver returns wrong records from poisoned cache	Flush local cache after resolver changes. Validate with resolvectl flush-caches then re-run dig.
Split-Tunnel / Bypass Paths	Firefox, VPN clients, or Docker bypass DoH/DoT	Freeze /etc/resolv.conf with chattr +i, drop systemd-resolved's auto-fallback, then trace each application's resolver calls individually.
TLS Certificate Pinning Failure	DoT handshake aborts on expired resolver cert	Use resolver hostname with valid certs (not IP-only), or prefer DoH which has more flexible cert handling.

Run a live packet capture to confirm no plaintext DNS leaks. The command below captures any traffic to port 53 (plaintext DNS) or port 853 (DNS-over-TLS) for 10 packets:

$ sudo tcpdump -i any -n '(port 53 or port 853)' -c 10

If you see traffic to port 53 reaching your ISP's resolver IPs (like 192.168.1.1 or a carrier-grade address), that is a plaintext leak. Encrypted DNS traffic should only appear on port 853, destined for your chosen resolver (1.1.1.1, 9.9.9.9, or 8.8.8.8).

After the capture, run an external validation from a browser-based DNS leak test (like dnsleaktest.com). The results should show only your chosen resolver — never your ISP's name or any local network address.

3. Traffic Verification & Leak Testing

Before trusting the setup, verify these seven points:

• Confirm DNSOverTLS=yes and DNSSEC=true in resolved.conf. Run resolvectl status and read each line.
• Lock /etc/resolv.conf with chattr +i to prevent overwrite by NetworkManager or DHCP client.
• Run a 60-second tcpdump capture filtering for port 53. No packets should reach your ISP's resolver.
• Back up resolver and resolved.conf before modifying systemd-resolved or NetworkManager settings.
• Disable unused local caches — systemd-resolved, dnsmasq, or unbound running in parallel can route queries outside DoT.
• Validate Firefox DoH separately — check about:networking for TRR status, not just system DNS.
• Reboot and re-verify — the most-skipped step. DHCP renewals and package updates can silently revert DNS settings.

The difference between a working DNS encryption setup and a fragile one is that single bypass path you forgot to close. The packet capture tells you if queries are actually leaving over TLS; the resolver status tells you the system is using your chosen provider; the Firefox check tells you no application is overriding the system-level configuration. Treat every layer as pass/fail, not advisory.

4. Troubleshooting Failure Modes

Sources & References

• RFC 8484: DNS Queries over HTTPS (DoH) — the IETF standard defining encrypted DNS over HTTPS
• RFC 7858: Specification of DNS over Transport Layer Security (TLS) — the IETF standard for DoT
• RFC 3842: PKCS #11 URI Scheme for Hardware Tokens — relevant for DNSSEC key storage
• Cloudflare DNS: https://developers.cloudflare.com/1.1.1.1/ — DoH/DoT documentation and resolver details
• Quad9 DNS: https://www.quad9.net/ — security-focused recursive resolver with malware blocking
• systemd-resolved: resolved.conf documentation — official configuration reference

DNS over HTTPS Pi-hole DNS Cloudflare DNS

---

Disclaimer: Each step is validated before publication. DNS configurations vary by OS version and network environment. Test all changes on a non-production system first.