For about thirty years, the rule was simple: you don’t trust anything about a connection until TLS says you can. Which cipher, which protocol version, whether the other end is who it claims — all of that got settled inside the handshake, under cryptographic cover, or it didn’t count. DNS handed you an address and then got out of the way. It was the untrusted phone book: good enough to find the building, never something you’d hand your keys to.
Then we started handing it the keys.
The record that front-loads your connection
In late 2023 the IETF published RFC 9460, which defines two new DNS record types: SVCB (type 64) and its HTTP-specific sibling, HTTPS (type 65). The pitch is performance and privacy, and on both counts it delivers. Instead of the old dance — resolve the name to an A record, open a connection, negotiate everything in-band, maybe get told over an Alt-Svc header that you should have used HTTP/3 and reconnect — the HTTPS record lets a browser learn all of that before it opens a single socket.
One DNS answer can now tell your browser: this origin speaks HTTP/3, here are IP hints so you can skip a second lookup, connect on this port, and — the interesting one — here is the public key you should use to encrypt your ClientHello. That last field, the ech parameter, carries the configuration for Encrypted Client Hello, the feature that finally hides the one thing TLS always leaked: the server name you’re asking for.
Browsers already do this. Chrome has honored the HTTPS record for protocol discovery and HTTP-to-HTTPS upgrades, on by default, since 2022; Firefox and Safari query it too. This isn’t a proposal. It’s how a large and growing share of your connections already start.
And it’s genuinely good engineering. Knowing you should speak HTTP/3 before you connect saves a wasted TCP connection and an Alt-Svc round trip. Getting the ECH key from DNS is the only practical way to bootstrap ECH — the whole point is to encrypt the ClientHello, so the key to do it can’t come from inside the ClientHello. It has to arrive out of band. DNS is the out-of-band channel every client already queries. Of course the key goes there.
Here’s the part that should make you pause. For the overwhelming majority of domains, that DNS answer is unauthenticated.
The layer we keep deciding not to sign
DNSSEC — the extension that cryptographically signs DNS records so a resolver can prove an answer wasn’t tampered with — has been available since the 1990s and deployed on a small minority of domains ever since. Adoption estimates hover well under a quarter of zones, and that number has barely moved in a decade. Most names on the internet resolve over plain, unsigned DNS: whatever the resolver hands back, the client believes, because there’s nothing to check the signature against, because there is no signature.
That was a tolerable state of affairs when DNS only told you where to connect. If an attacker who controls your DNS path forges an A record, they point you at a machine they own — but that machine still has to present a certificate your browser trusts for the name you asked for, and TLS catches the lie. The untrusted phone book was backstopped by the trusted handshake.
The HTTPS record quietly changes what’s riding on that phone book. Now the same unsigned answer can carry the parameters of the connection itself. And the failure that matters most isn’t dramatic forgery — it’s silent subtraction.
Consider ECH. Its entire job is to stop an on-path observer from seeing which site you’re visiting, by encrypting the server name inside the handshake. The public key that makes that possible lives in the ech field of the HTTPS record. Now put an attacker on the DNS path — a malicious resolver, a compromised network, a middlebox that rewrites answers. They don’t need to forge anything. They just delete the ech field before it reaches you.
Your browser asks for the HTTPS record, gets one back with no ECH key, and does the only reasonable thing: it connects without ECH. It has to. The vast majority of sites don’t publish an ECH key at all, so “no key” is the normal case, not an alarm. There’s nothing for the client to fail closed against. The privacy feature you thought was protecting you was switched off by a party who did nothing more than remove a field from an unsigned message — and your ClientHello goes out with the server name in the clear, exactly as if ECH had never existed.
That’s the shape of the problem. Not “attacker forges your connection” — TLS still mostly stops that. It’s “attacker downgrades the parts of your connection that were supposed to make it more private, by editing a message no one signed.”
The spec saw it coming — which is the point
To be fair to the people who wrote RFC 9460, none of this is a surprise to them. The security considerations are explicit: if DNS responses are cryptographically protected and SVCB resolution fails in a way that smells like tampering, the client should abandon the connection rather than fall back, precisely so an attacker can’t force a downgrade by denying access to the parameters. The defense against everything I just described is written down. It’s called DNSSEC.
Which is exactly what makes this worth writing about. The mitigation exists, it’s specified, and for most of the internet it isn’t turned on. We designed a system whose privacy guarantees are contingent on a layer being authenticated, and then deployed it on top of a layer we’ve collectively declined to authenticate for twenty-five years. The record is safe if the zone is signed. Most zones aren’t signed. So in practice the guarantee degrades from “cryptographically protected” to “protected as long as nobody on the path bothers to edit the answer.”
This is a pattern, not a one-off. We did a version of it with email: SPF, DKIM, and DMARC all publish security-critical policy in DNS TXT records, and their integrity leans on the same unsigned lookups. We did it with certificate issuance and CAA records. Every few years we discover a new reason DNS is load-bearing for security, add a record type to carry the weight, and route around the fact that the road underneath was never paved.
The HTTPS record is a good idea. Front-loading connection setup is the right move, ECH is overdue, and skipping wasted round trips is real user benefit. But it raises the stakes on a bet we keep making and keep not settling. Every capability we move into DNS is another thing that’s only as trustworthy as the zone is signed — and the zone, for most of the web, still isn’t. We didn’t just optimize away a round trip. We quietly made DNS part of the trusted computing base, and then left it exactly as unauthenticated as it was when it only knew addresses.
Sign your zones. It’s the unglamorous half of every one of these features, and it’s the half almost nobody ships.