DNS Security — DNSSEC, DoT, DoH
Classic DNS was designed in an era that assumed a friendly network. A query goes out as plaintext UDP on port 53, and the resolver believes whatever answer arrives first that matches the question — no signature, no encryption, no proof the answer came from the right server. That trust-the-first-reply design is the root of every DNS attack, and two separate defenses grew up to plug two separate holes.
DNSSEC signs records so a forged answer is detectable — it protects integrity. DoT and DoH encrypt the query in transit so the path cannot read or tamper with it — they protect privacy. The two are constantly confused, but they solve different problems and do not replace each other: DNSSEC proves the answer is genuine but sends it in the clear; DoH hides the question but says nothing about whether the answer is real.
Cache Poisoning and Spoofing
Because a resolver accepts the first matching reply, an attacker who can guess the query's parameters can race a forged answer ahead of the real one. The 2008 Kaminsky attack showed how cheap this was: the only secrets protecting a query were a 16-bit transaction ID and the source port, and by flooding guesses an attacker could land a poisoned answer in the resolver's cache — redirecting every client behind it to a malicious address until the TTL expired.
The stopgaps were source-port randomization and the 0x20 case-mixing trick, which add entropy the attacker must also guess. They raise the cost but do not close the hole — a forged answer that happens to match is still accepted, because plain DNS has no way to tell a real record from a fake one. That is precisely the gap DNSSEC was built to fill.
DNSSEC and the Chain of Trust
DNSSEC adds cryptographic signatures to records. Each zone signs its records with a private key and publishes the matching public key; a resolver validates a signature and, crucially, checks that the public key is vouched for by the parent zone — a DS record in the parent, signed by the parent, all the way up to the root's trust anchor. That unbroken chain from root to your zone is what lets a resolver reject a forged answer: a forgery cannot produce a valid signature down the chain.
Two things DNSSEC does not do trip people up. It does not encrypt — signed records travel in plaintext, so DNSSEC gives you no privacy at all, only authenticity. And it does not fail gracefully: if your signatures expire or the DS record in the parent doesn't match your key, validating resolvers treat every answer as bogus and return SERVFAIL, taking the domain fully offline for anyone whose resolver validates — a self-inflicted outage with no attacker involved.
# the AD flag means the resolver validated the DNSSEC chain dig +dnssec example.com # ;; flags: qr rd ra ad; <- 'ad' = Authenticated Data # example.com. 3600 IN A 93.184.216.34 # example.com. 3600 IN RRSIG A ... (the signature over the A record) # a SERVFAIL here instead usually means expired/broken signatures
DNS over TLS and DNS over HTTPS
DoT and DoH attack the other problem: the query itself is visible to anyone on the path between your machine and the resolver — your ISP, the coffee-shop Wi-Fi, any middlebox. DoT wraps DNS in a TLS connection on port 853; DoH tunnels it inside ordinary HTTPS on port 443, making DNS traffic indistinguishable from web traffic. Both encrypt only the stub-to-resolver hop — the leg from your device to its recursive resolver — not the resolver's onward queries to authoritative servers.
The distinction from DNSSEC is the whole point: DoT/DoH stop the path from reading or altering your question, but they say nothing about whether the resolver's answer is genuine — a malicious or compromised resolver can still lie over a perfectly encrypted DoH channel. Encryption secures the channel; DNSSEC secures the record. For the strongest posture you want both, and many deployments still run neither.
The Privacy and Operations Tension
DoH in particular creates a real conflict. Because it rides port 443 alongside web traffic and is often configured inside the browser rather than the OS, it can bypass the local resolver entirely — sending queries straight to a public DoH provider, invisible to the network operator. That is a privacy win for the user and a headache for any operation that relies on DNS for policy.
Enterprises filter malware domains, enforce split-horizon internal names, and log lookups for incident response — all at the local resolver. A browser doing DoH to an outside provider sidesteps every one of those controls, and the operator may not even see it happening. The fix is organizational, not technical: provide a trusted internal DoH/DoT resolver and configure clients to use it, so you keep both the encryption and the control.
DNSSEC signs records so a resolver can prove an answer is genuine and reject forgeries — it protects the authenticity of the record. It does not encrypt anything; the signed answer travels in plaintext. Deploy it when you care that nobody can spoof your zone.
DoT / DoH encrypt the query between client and resolver so the path cannot read or tamper with it — they protect the privacy of the question. They do not authenticate the record, so a lying resolver still lies. Deploy them when you care that the path cannot snoop or rewrite queries — and run both alongside DNSSEC for full coverage.
- Assuming DNSSEC encrypts your DNS traffic. It signs records for authenticity but sends them in plaintext, so anyone on the path still reads every query and answer — you have integrity, not privacy.
- Assuming DoH authenticates the data. It secures the channel to the resolver but not the record, so a compromised or hostile resolver can return forged answers over a perfectly encrypted connection.
- Letting DNSSEC signatures expire. Validating resolvers return SERVFAIL on a broken chain, so an expired RRSIG or a stale DS record in the parent takes the whole domain offline with no attacker involved.
- Rolling a DNSSEC key without updating the parent DS record. The chain of trust breaks the moment the published key no longer matches the parent's DS, and every validating resolver starts rejecting your zone.
- Trusting source-port randomization alone against poisoning. It only raises the attacker's guessing cost; a forged answer that matches is still accepted, because plain DNS cannot distinguish a real record from a fake one.
- Sign your zone with DNSSEC and confirm the parent DS record matches your key, so validating resolvers can reject any spoofed answer for your domain.
- Automate DNSSEC signing and key rollover so signatures never expire by hand, because a lapsed RRSIG triggers SERVFAIL and a full self-inflicted outage.
- Run DoT or DoH for the stub-to-resolver hop to keep the path from snooping or rewriting queries, and treat it as complementary to DNSSEC, not a substitute.
- Provide a trusted internal DoH/DoT resolver and point clients at it, so users get encryption without browser-level DoH bypassing your filtering and logging.
- Monitor your domain for SERVFAIL from validating resolvers after any DNSSEC change, so you catch a broken chain before users do instead of from a flood of support tickets.
Knowledge Check
A team enables DNSSEC and assumes their DNS queries are now private from their ISP. What did they actually get?
- Authenticity only — records are signed but still sent in plaintext
- Full encryption of every single query, hiding all of their lookups from the ISP entirely
- Encrypted web sessions, since DNSSEC also covers the TLS handshake
- Smaller, compressed responses that the ISP cannot parse
A domain's DNSSEC signatures expire over a weekend. What do users on validating resolvers experience?
- SERVFAIL — the domain is offline for them, a self-inflicted outage
- Nothing — the resolver ignores the bad signature and serves the record
- Slower lookups that recover automatically once caches refresh
- A warning prompt asking whether to trust the unsigned answer
Why does browser-level DoH frustrate an enterprise that filters malware domains at its local resolver?
- It sends queries to an outside provider over 443, bypassing the local resolver
- It disables DNSSEC validation on the client, so forged malware answers slip through to the user unchecked
- It changes record formats so the filter can no longer parse them
- It makes every query so slow the resolver times out before filtering
You got correct