There’s a settings toggle in Chrome called “Use secure DNS,” and the word doing the heavy lifting there is “secure,” because most people read it as “safe” and it means something much narrower. Flip it on and Chrome sends your DNS queries over HTTPS — DoH — instead of the old plaintext UDP that anyone on the path could read. That’s real. Your ISP can no longer sit there logging every hostname you look up. The eavesdropper is gone.
The forger is not. And that’s the part the word “secure” quietly papers over.
Encryption and authentication are two different problems, and they get conflated constantly because both sound like “security.” Encryption hides the conversation. Authentication proves the other party is who they claim and the message wasn’t tampered with. Secure DNS does the first one. It does not do the second. When Chrome fetches yourbank.com over an encrypted DoH channel and the resolver answers 203.0.113.9, Chrome has a cryptographic guarantee that nobody read or altered that answer in transit between Chrome and the resolver. It has no guarantee whatsoever that 203.0.113.9 is actually your bank’s address. The channel is sealed. The contents are taken on faith.
The mechanism that would fix this exists, and browsers don’t run it
We have a protocol whose entire job is authenticating DNS answers: DNSSEC. It signs records so a validator can prove a response genuinely came from the zone’s owner and wasn’t forged along the way. If you want the thing that “secure DNS” sounds like it should be, DNSSEC validation is it.
Chrome doesn’t do it. Firefox doesn’t do it. No mainstream browser validates DNSSEC, and this isn’t an oversight they haven’t gotten to — it’s a decision they made and stuck with. Chrome actually shipped something close once: a mechanism to carry DNSSEC-authenticated records for DANE, so the browser could pin a certificate through DNS. They ripped it out. Adam Langley, who worked on Chrome’s TLS stack, laid out the reasoning back in 2015 in a post bluntly titled “Why not DANE in browsers.” The short version: it was a pile of parsing code living outside the sandbox, almost nobody used it, it fought with the direction TLS was heading, and DNSSEC leaned on 1024-bit RSA — including in the root zone — which Google was actively trying to get out of the browser. So it went.
The reasoning has aged fine, honestly. But the consequence is that the two things a normal person would assume “secure DNS” bundles together — a private channel and a trustworthy answer — were split, and browsers shipped exactly one of them under a name that implies both.
So what does turning it on actually buy you
It moves your trust, and it’s worth being clear-eyed about where it lands.
Before Secure DNS, you trusted whatever resolver your network handed you (usually your ISP’s), and everyone on the wire could watch. After Secure DNS, the wire is dark, and you trust your chosen DoH provider — Cloudflare, Google, Quad9, whoever — completely and totally, because they resolve your queries and hand you answers you cannot independently verify. You’ve swapped a transparent, snoopable relationship with your ISP for an opaque, encrypted relationship with a DoH operator. That’s a genuine privacy upgrade against the guy sniffing coffee-shop Wi-Fi. It is not integrity. If the resolver is wrong, compromised, or lying — or if the unsigned zone it’s querying got poisoned upstream — Chrome will render the forged answer over a beautiful encrypted connection and show you a padlock once TLS completes.
And here’s the piece that keeps this from being purely academic: the overwhelming majority of domains aren’t signed. Global DNSSEC adoption has been stuck under a fifth of domains for years. So for most of the internet, there is no signature to validate even if browsers wanted to. Turning on Secure DNS for an unsigned domain gives you an encrypted pipe carrying an answer that nothing, anywhere in the stack, has cryptographically vouched for. The confidentiality is real. The authenticity was never on the table.
Where the actual checking happens (if it happens at all)
DNSSEC validation, when it occurs, happens at the resolver, not the browser. A validating resolver — 1.1.1.1, 8.8.8.8, 9.9.9.9 and most serious ones do this — checks signatures on signed zones and refuses to return answers that fail validation (you get a SERVFAIL instead of a lie). That’s good, and it’s the layer actually doing authentication today. But notice what it means: the security you’re getting isn’t from Chrome’s toggle at all. It’s from your resolver choosing to validate, on the minority of zones that are signed, and then you trusting that the resolver did it honestly over your encrypted channel. The browser is a passenger. It encrypts the ride and validates nothing.
I don’t think Secure DNS is bad. I run it. Encrypting DNS was overdue, and closing the passive-surveillance hole is a real win. What bothers me is the label, and the mental model it installs. A generation of users is going to flip on “secure DNS,” see the word “secure,” and file DNS under “handled” — the same way the padlock icon convinced everyone that HTTPS meant a site was trustworthy rather than merely encrypted. We made that mistake once already with the lock. We’re about to make it again with the resolver.
Encrypting a channel and authenticating its contents are not the same act. Chrome does one and named it after both. If you want the answer to be true, not just private, that job still belongs to a validating resolver and a signed zone — and most of the internet has neither.