Your browser encrypted your DNS queries. It also decided who gets to read them.

DNS queries have been transmitted in cleartext since 1983. Every resolver in the path — your ISP, the hotel router, the airport Wi-Fi box, your corporate gateway — can read, log, and rewrite them. That’s not theoretical. DNS hijacking for ad injection was a cottage industry for ISPs for over a decade. Nation-state DNS manipulation is documented well enough that OONI Probe has tests for it. The cleartext DNS problem is real and it has been real for forty years.

RFC 7858 (DNS over TLS, 2016) and RFC 8484 (DNS over HTTPS, 2018) are the correct answers. Wrap DNS in an encrypted channel. Same protocol, same data, the eavesdropper sees that you’re making DNS queries but not what they are. The resolver at the other end still sees everything — that’s how DNS works, you have to ask someone — but now the path between you and the resolver is opaque to third parties.

That’s the correct part. Here’s where it got complicated.

The browser as trust re-router

Firefox rolled out DoH in the US in 2020 with Cloudflare’s 1.1.1.1 as the default resolver. Chrome followed with its own list. The implementation decision: if the user hasn’t configured an encrypted resolver, pick one. The defaults were Cloudflare, Google, and a short list of “Trusted Recursive Resolvers” vetted under a contractual framework Mozilla published but approximately nobody read.

The stated justification: most users have no DNS resolver configuration and will never make one, so pointing them to a better option by default is a net privacy improvement. This is technically accurate. It is also a decision to redirect a substantial fraction of internet DNS queries to two companies.

Your ISP’s resolver saw your queries. You didn’t think about it. Now Cloudflare’s resolver sees your queries. You still aren’t thinking about it.

The queries travel over TLS — that’s real. Cloudflare still sees every hostname you visit — also real. “Your queries are encrypted in transit” and “your queries are private” are different claims, and the browser marketing did not always make that distinction clearly. Encrypted-in-transit-to-Cloudflare is better than cleartext-to-your-ISP on a hostile network. It is not the same as private.

What running your own resolver actually looks like

This is a solved problem if you control the machine. unbound has shipped in FreeBSD base for years. Configure it to validate DNSSEC and forward over TLS:

server:
    interface: 127.0.0.1
    interface: ::1
    access-control: 127.0.0.1/32 allow
    access-control: ::1/128 allow
    do-not-query-localhost: no

    # DNSSEC validation — on, always
    auto-trust-anchor-file: "/var/unbound/root.key"

forward-zone:
    name: "."
    forward-tls-upstream: yes
    # Quad9 — Swiss legal jurisdiction, audited no-logging policy
    forward-addr: 9.9.9.9@853#dns.quad9.net
    forward-addr: 149.112.112.112@853#dns.quad9.net

Set your system resolver to 127.0.0.1, configure your browser to use system DNS, and DoH in the browser routes to your unbound instance — not Cloudflare, not Google. The upstream connection from unbound to Quad9 is TLS. You’ve made an actual choice about who sees your queries rather than accepting the browser vendor’s default.

Quad9 operates under Swiss data protection law and publishes third-party audit results. I’m not endorsing them over all other options — read the Cloudflare and NextDNS privacy policies yourself and decide — but “I made a choice after reading the options” is categorically different from “my browser picked for me.”

If you’re verifying the TLS setup, the OpenSSL s_client approach works here too: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net and verify the certificate. Trust but verify, especially for infrastructure you’re routing all your DNS through.

The enterprise split-horizon blowup

Split-horizon DNS is common in any organization larger than about ten people: internal hostnames resolve internally, external hostnames resolve normally, the resolver knows which is which based on the domain and the query source. It works because someone controls the resolver.

DoH in browsers, sending queries to an external resolver, breaks split-horizon by design. The browser asks Cloudflare about db.internal.corp and Cloudflare has no record of it because that name doesn’t exist in public DNS. The browser sees NXDOMAIN. The user sees a connection failure. Nobody gets a useful error message.

Mozilla shipped a canary domain mechanism — use-application-dns.net — where if the network’s resolver returns NXDOMAIN for that specific domain, Firefox disables DoH on the assumption that the network is managed. Google implemented a similar check. These mechanisms require the IT department to configure their resolver to signal the browser, which is the tail wagging the dog. IT has to opt out of the browser’s default behavior rather than the browser defaulting to respecting the network’s resolver.

Enterprise policy controls eventually got added — Firefox has network.trr.mode lockable via enterprise configuration, Chrome has Group Policy. They work. They require knowing they exist before the browser starts quietly bypassing your DNS infrastructure and generating confusing failures that take a while to trace back to the actual cause.

DNS over QUIC is next

RFC 9250 (DNS over QUIC, 2022) is the third entrant — DNS over the QUIC transport that HTTP/3 uses. Lower latency than DoT for the first query, better connection migration, same encryption story. It’s shipping in knot-resolver and a few other implementations. The browser vendors will eventually deploy it.

The fundamental situation doesn’t change: QUIC transport for DNS is correct engineering. Who the resolver is, and who made that choice, is still the question that matters.

The actual state of things

The DoH deployments have improved. Enterprise controls exist and are documented. More browsers now honor system-configured DoT/DoH resolvers rather than overriding them with vendor defaults. The first rollouts were blunt instruments; they got refined under pressure from the enterprise community and from network operators who were suddenly invisible to a meaningful fraction of user traffic.

The broader TLS ecosystem has its own certificate lifecycle pressures — certificate lifetimes are collapsing toward 90 days and eventually shorter, which affects every TLS-based system including your DoT resolver connections. That’s a separate fight.

Encrypted DNS is unambiguously better than cleartext DNS. Encrypted DNS to a resolver you chose is better than encrypted DNS to a resolver your browser vendor chose. The gap between “encrypted” and “private” is not subtle, and it got glossed over in the rollout. Most users still don’t know which resolver their browser is talking to.

You do now. Go check. Then go set up unbound.