DNSSEC
DNS Security Extensions. A way to cryptographically sign DNS records so resolvers can verify they haven't been tampered with in transit.
DNSSEC (DNS Security Extensions, RFCs 4033–4035) adds cryptographic signatures to DNS records so resolvers can verify that the answer they got is the answer the zone owner actually published. Without DNSSEC, anyone in the network path can return a fake DNS response, and there's no way for the resolver to tell.
What DNSSEC fixes
DNS spoofing / cache poisoning. Without DNSSEC, an attacker who can intercept DNS queries (or poison a cache) can redirect users to a malicious IP. DNSSEC makes this detectable because signatures don't verify.
What it doesn't fix
- Doesn't encrypt DNS queries. (That's DoH/DoT.)
- Doesn't hide the fact that you're looking up a domain.
- Doesn't prevent compromised authoritative servers from publishing bad data; just prevents tampering in transit.
The chain of trust
DNSSEC signatures use keys. Resolvers verify them via a chain:
Root zone → .com → example.com
DS DS
Each parent zone has a DS record confirming the child's key. The root zone's keys are baked into every validating resolver.
Adoption
Globally, ~30% of zones are DNSSEC-signed. Major TLDs are signed (.com, .org, .net, .io). Most major ccTLDs are. Some aren't.
Why most SaaS skip it
- Adds operational complexity (key rotation, DS record management at registrar).
- Hard dependency on your DNS provider supporting it.
- Modern browsers don't validate DNSSEC themselves; they rely on the recursive resolver.
- For a typical web SaaS, the threat model doesn't usually justify the cost.
For banking, government, or regulated industries: DNSSEC is often required. For everyone else: optional.