DNS: The Quiet Surveillance Layer

HTTPS encrypts the body of your web request. DNS, the protocol that turns a domain name into an IP address, runs in plaintext on UDP port 53 by default — and almost nobody talks about it. Your ISP sees every domain you visit in cleartext. Your router sees it. Anyone running a captive portal sees it. Here's the full layer cake, what fixes it, and what doesn't.

What DNS actually leaks

When you type https://example.com into your browser, the browser performs roughly this sequence:

1. Ask the OS resolver for example.com
2. OS resolver forwards to the configured DNS server (usually your ISP's, e.g. 71.252.0.12 on Verizon FiOS)
3. Server returns an A or AAAA record
4. Browser opens a TCP+TLS connection to that IP

Step 2 is plaintext. The query QUESTION: example.com IN A travels over the wire visible to every router between you and the resolver. Even after you upgrade to HTTPS for the connection itself, your ISP already knows where you went — they sold you the lookup.

Run this on Linux to see it in real time:

$ sudo tcpdump -i any -n port 53
21:14:02.001 IP 10.0.0.42.38291 > 1.1.1.1.53: 28471+ A? cryptok.me. (28)
21:14:02.018 IP 1.1.1.1.53 > 10.0.0.42.38291: 28471 1/0/0 A 108.244.21.92 (44)

Every browser tab, every app phone-home, every ad SDK — all of it appears here in cleartext. ISPs in the US are legally allowed to log and sell this data; many do.

The two encryption fixes

DNS over HTTPS (DoH) — RFC 8484

DoH wraps DNS queries in an HTTPS connection to a known resolver. From the network's perspective, your DNS lookups become indistinguishable from regular HTTPS traffic to 1.1.1.1 or dns.google. The ISP sees you talking to Cloudflare; it does not see which domains.

Firefox enables DoH in many regions by default (using NextDNS or Cloudflare). Chrome enables "Secure DNS" if your existing DNS server supports it. iOS 14+ and Android 9+ both support DoH at the OS level via configuration profiles.

DNS over TLS (DoT) — RFC 7858

DoT runs encrypted DNS on TCP port 853. It's cleaner from a protocol-design standpoint than DoH (no HTTP overhead), but the dedicated port makes it trivial to block at the network. DoH hides among normal HTTPS traffic; DoT raises a flag.

Android 9+ ships DoT as "Private DNS" — the user-visible setting at Settings → Network → Private DNS → Hostname. Type 1dot1dot1dot1.cloudflare-dns.com or dns.quad9.net and every DNS query from every app on the device upgrades.

The leaks that survive encryption

Encrypting DNS does not make your browsing unobservable. Three big leaks remain even with DoH/DoT enabled.

1. SNI (Server Name Indication)

When your browser opens the TLS connection to the resolved IP, the very first packet of the handshake includes the hostname you're connecting to in plaintext — the SNI extension. This was added so a single IP address could host many TLS sites; the consequence is that even with encrypted DNS, your ISP can read cryptok.me off the wire from the TLS ClientHello.

The fix is Encrypted Client Hello (ECH), which encrypts the SNI under the server's public key. Cloudflare, Mozilla, and Chrome shipped ECH support in 2024. It only works when both the client and the server's CDN support it — currently meaning sites fronted by Cloudflare, Fastly, or Cloudfront with ECH enabled. Outside those, SNI still leaks.

2. The destination IP itself

Even with ECH, the IP packet header has the destination address in clear. If example.com resolves to a unique IP, the IP alone identifies the site. This is mitigated by IP sharing (most CDNs serve thousands of sites from a single IP) but remains an issue for any self-hosted service on a dedicated address.

3. OCSP and certificate transparency lookups

Some browsers still do live certificate revocation checks (OCSP) over plaintext HTTP, which leaks the certificate's serial number — and therefore the site you visited — to the CA. Modern browsers have largely moved to OCSP stapling and CRLite, but the leak remains in some configurations.

Choosing a resolver

Encrypting DNS doesn't help if the resolver itself sells your data. Here's the practical landscape:

Run your own resolver

If you don't trust any of the public options, you can run a recursive resolver yourself — it queries the root servers directly and never sends a list of your lookups to any third party. The lightweight option is dnscrypt-proxy as a forwarder; the full option is Unbound as a recursor on your home server.

Minimal Unbound config running locally:

server:
    interface: 127.0.0.1
    interface: 10.0.0.1            # LAN
    access-control: 10.0.0.0/24 allow
    hide-identity: yes
    hide-version: yes
    qname-minimisation: yes        # send only what's necessary
    aggressive-nsec: yes
    use-caps-for-id: yes
    prefetch: yes
    do-not-query-localhost: no

Set your router's DNS to 10.0.0.1, point Unbound at the root hints, and your queries never go through Cloudflare or Google. The trade-off is that you become a uniquely identifiable resolver to every authoritative server you query — which is fine for a household, less fine if you're trying to blend into a crowd.

The practical recipe

1. On every device, enable encrypted DNS: Android Private DNS to dns.quad9.net, iOS profile from NextDNS or AdGuard, desktop browser DoH to Cloudflare or Quad9.
2. On the router, set DoT upstream: OpenWrt + stubby or https-dns-proxy. Devices that don't support DoH/DoT (smart TVs, IoT) get covered automatically.
3. Block DNS port 53 outbound at the firewall after step 2 so misconfigured apps can't fall back to plaintext.
4. Enable ECH in Firefox (network.dns.echconfig.enabled) and Chrome (default since 117). On compatible sites, SNI is now encrypted too.
5. Test it. dnscheck.tools and 1.1.1.1/help both report whether your queries are encrypted, what resolver is being used, and whether ECH is in play.

Privacy isn't only about content. The shape of your traffic — which sites, when, for how long — is most of what surveillance economies trade in. DNS is where that shape used to be free for the taking. Close it.