DNS over HTTPS Explained: What It Does and Does Not Protect

Classic DNS has a privacy quirk that surprises people: your lookups travel as plain, readable text. Any network between you and the resolver (the coffee shop router, your provider, a compromised hotspot) can see which names you ask about, and in principle alter the answers. DNS over HTTPS, usually shortened to DoH, wraps those lookups in the same encryption your browser already uses for websites.

DoH is genuinely useful, but it is also widely oversold. It protects one specific segment of one specific conversation. Understanding exactly which segment tells you both what it is worth and what it was never going to do for you.

The three ways a lookup can travel

Your device does not usually speak to the internet's DNS directly. An application asks the operating system's stub resolver, and the stub asks a recursive resolver, the service your network assigned or one you chose. How DNS resolution works walks through that chain in full. DoH changes how the stub talks to the resolver:

The practical difference between DoT and DoH is mostly about blending in and about who controls the setting. DoT announces itself on a dedicated port, so a network can allow or block it deliberately. DoH rides inside normal web traffic, which makes it harder for a network to single out, and it is commonly configured per application (a browser can use DoH while the rest of the system does not) rather than only system-wide.

What DoH protects

With DoH on, the hop between your device and the resolver is encrypted and authenticated: the local network can no longer read the names you look up, and it cannot silently rewrite the answers on their way back. On an untrusted network (public Wi-Fi is the textbook case) that is a real improvement, because the local network was previously the easiest place to watch or tamper with lookups.

DoH also authenticates the resolver itself, in the same way HTTPS authenticates a website. Your stub knows it is really talking to the resolver it intended, and not to an impostor the local network inserted. With classic DNS, that assurance simply does not exist; a forged answer that arrives first is accepted.

What DoH does not protect

Three limits matter, and no honest explanation should skip them:

• The resolver still sees everything. Encryption runs between you and the resolver, so the resolver necessarily reads every query to answer it. DoH moves your trust from the local network and your provider to the resolver operator; it does not remove the need for trust.
• The destination is still visible. After the lookup, your device connects to the site's IP address, and networks can observe which addresses you connect to even when they cannot see the names. Encrypted DNS hides the question, not the journey that follows.
• Only that one hop is covered. Once the resolver has your query, it fetches the answer from authoritative servers on your behalf. DoH says nothing about that side of the conversation, and it does not encrypt the web traffic itself: that remains the job of HTTPS and TLS on the connection to the site.

DoH is not DNSSEC, and neither replaces the other

These two technologies are confused constantly because both involve DNS and security, but they solve opposite problems. DoH provides confidentiality: it keeps the conversation between you and the resolver private. DNSSEC provides authenticity: it lets a resolver verify that an answer really came from the domain's owner and was not altered anywhere along the way, using digital signatures published in DNS itself.

An encrypted channel carrying a forged answer is still a forged answer, which is why DoH alone cannot prove an answer true. And a signed, verifiable answer can still travel in plain sight, which is why DNSSEC alone keeps nothing private. Used together, they cover each other's gaps; how DNSSEC works covers the signing side in detail.

A quiet detail: what happens when DoH fails

Encrypted DNS implementations generally choose between two behaviours when the encrypted path fails. In an opportunistic mode, the device quietly falls back to classic DNS, so lookups keep working but lose their protection without any visible complaint. In a strict mode, the device refuses to fall back, and names simply stop resolving until the encrypted service is reachable again. Neither is a defect: the first trades privacy for reliability, the second makes the opposite trade. But it is worth knowing which behaviour your browser or system uses, because an opportunistic fallback means your protection can vanish on exactly the hostile networks where you wanted it most, and you would never be told.

Where DoH is configured

DoH lives wherever the stub resolver is configured, which in practice means the browser and the operating system. Many browsers have their own encrypted DNS setting and may turn it on by default, using a resolver the browser chose; operating systems increasingly offer a system-wide encrypted DNS option as well. That split explains a common confusion: a browser can be using DoH while other applications on the same machine still use classic DNS, so a network-level check can show both at once.

Should you turn it on?

For most people, yes, with eyes open. On networks you do not control, encrypted lookups remove the easiest eavesdropping and tampering point for almost no cost. Just keep the ledger straight: you are choosing a resolver operator to trust with your queries, and the rest of your traffic's privacy still depends on the sites themselves using HTTPS. DoH is one solid improvement to one hop of the resolution chain, and that, neither more nor less, is what it promises.