DNS Over HTTPS (DoH): What, Why, and How It Works

You’re at a coffee shop. You join the free Wi-Fi, type bank.example.com, and start checking your balance. The connection to your bank is locked behind that reassuring little padlock — TLS, encrypted, private.

Except the question you asked first wasn’t private at all.

Before your browser could open that encrypted tunnel, it had to ask a simple question:

“What’s the IP address for bank.example.com?"

That question — a DNS lookup — left your laptop unencrypted, in a 40-year-old format (RFC 1035), for anyone on that Wi-Fi (and your ISP, and a few hops in between) to read, log, or quietly change.

The padlock protects what you say. For decades, nothing protected who you were talking to. That’s the problem DNS over HTTPS (DoH) tries to fix.

The problem: classic DNS is a postcard

DNS is the internet’s phone book: it turns names humans remember (bank.example.com) into addresses machines route to (203.0.113.10).

It’s brilliant, essential — and it was designed in 1983, when the network was a trusting place.

By default, classic DNS travels as plaintext UDP on port 53. That creates three concrete problems:

• Eavesdropping. Every lookup is readable on the wire. Even with HTTPS everywhere, your DNS history can reveal the sites, apps, and services you touch - a surprisingly complete map of your behavior. Network operators and ISPs can log it, analyze it, and in some places even monetize it.
• Tampering. Classic DNS has no built-in confidentiality or integrity protection. Anyone who can interfere with the network path can change the answer. That is the mechanism behind ISP NXDOMAIN ad pages, captive portals, some forms of censorship, and DNS hijacking that tries to send users somewhere they did not intend to go.
• Easy blocking. DNS is a convenient chokepoint. Blocking, redirecting, or filtering traffic on port 53 is simple, which makes DNS a favorite control point for surveillance, policy enforcement, and censorship.

The uncomfortable summary: you can encrypt the contents of every connection and still leak the intent behind many of them through DNS.

What DoH is (and how you’d use it)

DNS over HTTPS (DoH) does exactly what the name says: it wraps your DNS queries inside an ordinary HTTPS request to a DNS resolver. Standardized as RFC 8484 in 2018, it gives DNS the two things it always lacked:

• Confidentiality — queries are encrypted with TLS, so the coffee shop, the ISP, and the hops in between see only that you’re talking to some HTTPS server, not what you asked.
• Integrity — TLS prevents on-path answers from being silently rewritten.

In practice you already have it:

• Browsers: Firefox and Chrome can send DNS over HTTPS to a resolver of your choice (Cloudflare, Google, NextDNS, etc.).
• Operating systems: Windows 11, macOS, iOS, and Android all support encrypted DNS profiles.
• Apps & tooling: anything that can speak HTTPS can do DoH — which is why it’s great for resolving names reliably on hostile or filtered networks.

One honest caveat up front: DoH is dual-use. The same property that hides your lookups from a snooping network also hides them from a defensive one — so malware increasingly uses DoH for stealthy command-and-control, and enterprises lose the DNS visibility they rely on for threat detection. A privacy win for users is a monitoring headache for blue teams.

The technology: how DoH actually works

Under the hood, DoH is less “new protocol” and more “old protocol in a better envelope.” DoH does not replace DNS. It wraps DNS in HTTPS.

The pieces that make it work:

1. A DoH endpoint.

Resolvers expose an HTTPS URL, by convention https://resolver.example/dns-query.

A DoH endpoint is simply the URL where a DNS-over-HTTPS resolver accepts DNS questions. In classic DNS, your device sends a DNS packet to a resolver’s IP address on port 53, like:

8.8.8.8:53

In DoH, your device sends the DNS query as an HTTPS request to a web URL, like:

https://resolver.example/dns-query

So instead of saying - “Send this DNS query to this DNS server over UDP." - DoH says - “Send this DNS query to this HTTPS URL."

The /dns-query path is a convention used by many DoH resolvers. For example, a resolver may expose:

https://cloudflare-dns.com/dns-query
https://dns.google/dns-query
https://dns.quad9.net/dns-query

The important thing is: the endpoint is not a normal website page meant for humans. It is an API endpoint. Your browser, OS, or DNS client sends a DNS query there, and the server returns a DNS response.

2. Port 443, not 53.

Everything rides the same port as normal web traffic. That’s deliberate: DoH traffic is indistinguishable from any other HTTPS (I mean it can be, DoH can still be identified by known resolver IPs, SNI/hostname, certificate metadata, and traffic patterns. But it’s still better than plaintext DNS.), so it can’t be cheaply singled out and blocked (unlike its sibling, DoT — DNS over TLS — which uses a dedicated port 853 and is easier to spot and filter).

3. Two ways to carry the DNS query

Once the client knows the DoH endpoint, it still needs to put the DNS question into the HTTPS request. There are two common ways you will see this.

Wireformat - RFC 8484 : the real DoH standard

The client creates a normal DNS message, the same kind of binary DNS packet that would usually go over port 53. Then it places that DNS message inside an HTTPS request.

With POST, the DNS message goes in the request body:

POST /dns-query HTTP/2
Host: resolver.example
Content-Type: application/dns-message
Accept: application/dns-message

<binary DNS query>

With GET, the same binary DNS message is base64url-encoded and placed into the URL:

GET /dns-query?dns=<base64url-encoded-dns-query> HTTP/2
Host: resolver.example
Accept: application/dns-message

This is the proper DoH format. A compliant DoH resolver is expected to understand application/dns-message.

The important idea: DoH does not reinvent the DNS message. It takes the normal DNS packet and carries it inside HTTPS.

JSON: a convenience extension from Google/Cloudflare

Some providers also expose a JSON API for convenience.

Instead of sending a binary DNS message, you send something easier to read:

GET /dns-query?name=example.com&type=A
Accept: application/dns-json

And the resolver returns a JSON response.

This is nice for debugging, demos, and quick scripts because you can call it with a browser or curl and read the result easily but it’s not universal (e.g. Quad9’s main endpoint speaks only wireformat).

4. TLS does the heavy lifting.

The HTTPS handshake does the heavy lifting. It authenticates the DoH resolver, negotiates encryption keys, and creates a protected channel between your device and that resolver.

From that point on, the DNS query and response travel inside HTTPS. Observers on the local network, ISP path, or Wi-Fi hotspot cannot casually read or modify the DNS exchange.

But the protection is only for that first hop: client to resolver. Once the resolver receives the query, it still performs normal recursive DNS resolution on your behalf.

5. HTTP/2 (and HTTP/3) multiplexing.

Because DoH uses real HTTP, many DNS queries can share the same encrypted connection and run in parallel. Instead of creating a fresh connection for every lookup, the client can reuse one already-open HTTPS connection.

That helps offset the TLS overhead and can make DoH fast in practice, especially after the first connection is established.

6. The resolver does the rest.

On the far side, the DoH resolver behaves like a normal recursive resolver. It may answer from cache, or it may perform the usual DNS resolution process by walking the DNS hierarchy and querying authoritative nameservers.

The answer then comes back through the same encrypted HTTPS connection.

The wider DNS system does not change. DoH mainly protects the first hop: the path between your device and your resolver.

What DoH does not hide

DoH encrypts the DNS question between your device and the resolver, but it does not make your browsing invisible.

A network observer may no longer see the exact DNS query, but they can still learn things from other metadata:

• The resolver you use. They can see that you are connecting to a DoH provider such as Cloudflare, Google, Quad9, or NextDNS.
• The destination IP. After DNS resolution, your device still connects to the website’s IP address.
• TLS metadata. In some cases, fields like SNI can still reveal the hostname unless Encrypted Client Hello is used.
• Traffic patterns. Timing, packet sizes, and connection behavior can still say a lot.
• The resolver still sees your queries. DoH shifts trust from the local network or ISP to the resolver you choose.

So DoH is not anonymity. It is not Tor. It does not hide everything.

What it does is narrower and still important: it prevents the local network and on-path observers from casually reading or modifying your DNS lookups.

DNS, DoT, and DoH at a glance

The takeaway

DNS was one of the last big pieces of everyday browsing still traveling in the open. DoH closes that gap with no new infrastructure and no new ports - just the DNS we’ve always used, sealed inside the HTTPS we already trust.

It is not a privacy silver bullet. You are now trusting whichever resolver you choose. It can concentrate a lot of visibility in a few large providers. And it can make legitimate network defense, debugging, and policy enforcement harder.

But for the person on coffee shop Wi-Fi, the trade-off is simple and overdue: the question asked before every connection finally gets the same kind of protection as the connection itself.

The postcard, at last, has an envelope.