DNSSEC
Also known as: DNS Security Extensions, Domain Name System Security Extensions, signed DNS
DNSSEC, short for Domain Name System Security Extensions, adds digital signatures to DNS, the internet's address book.
It lets resolvers check that the answer to 'where is this website?' really came from the domain's owner and wasn't forged along the way. While DNSSEC protects against certain attacks that redirect people to fake sites, it doesn't encrypt your lookups, and adoption remains uneven because it adds complexity for domain owners.
DNSSEC, explained at three levels
At home
DNSSEC works like a tamper-evident seal on a medicine bottle. DNS is the internet's address book, turning a name like mybank.ca into a numeric address. DNSSEC adds a digital signature to each answer, made with a key only the domain's owner controls. Your resolver checks the seal, and if it is broken or missing when it should be there, the answer is thrown away instead of sending you to a fake site.
At work
DNSSEC is a set of extensions that adds cryptographic signatures to a domain's DNS records. When a customer's resolver looks up your website or mail server, it can confirm the answer was published by you and not injected by an attacker along the way. For a business, that closes off cache poisoning and redirect attacks that could send customers to a convincing fake login page.
At home
DNSSEC works through a chain of signatures. Your domain's records are signed with a private key, and the matching public key is published in DNS too. The level above, such as .ca, vouches for that key with a small fingerprint record, and the root zone vouches for .ca. A validating resolver, such as the one your ISP or Cloudflare runs, follows that chain up to the root. If any link fails, you get an error instead of a forged address.
At work
A signed zone uses two key types. The zone-signing key (ZSK) signs each set of records, producing RRSIG records. The key-signing key (KSK) signs the DNSKEY set, and a hash of it is published as a DS record in the parent zone through your registrar. NSEC or NSEC3 records prove that a name does not exist, so attackers cannot fake a 'no such domain' answer. Validation happens at the recursive resolver, not usually on the laptop itself.
At home
While DNSSEC proves an answer is genuine, it does nothing for privacy. The signatures travel in plain view, so your ISP or anyone on the coffee shop Wi-Fi can still see which names you look up. Protection also depends on the last step: most devices trust their resolver to validate and simply accept its verdict, so tampering between you and the resolver is not covered. In my view, DNSSEC and encrypted DNS solve different halves of the same problem, and you want both.
At work
DNSSEC's main failure mode is self-inflicted. Signatures carry expiry dates, so if automated re-signing stops, or a KSK rollover leaves a stale DS record at the registrar, validating resolvers treat the whole domain as bogus and it vanishes for many users. Algorithm choice matters too: ECDSA P-256 (algorithm 13) keeps responses small, while large RSA keys can cause fragmentation. Signed zones also enable DANE, which publishes TLS certificate pins for mail servers. Managed DNS with automatic signing and CDS records for DS updates removes most of the risk.
Real-world examples
At home
Aisha read about a scam where criminals redirected a bank's website address. She learned that DNSSEC helps prevent that kind of forgery when the domain owner turns it on.
At work
Thomas manages domains for a Quebec credit union. He enabled DNSSEC through the company's DNS provider and registrar, adding protection against redirect attacks on online banking.
How it compares
| feature | DNSSEC | DNS over HTTPS |
|---|---|---|
| Protects | Authenticity of DNS answers | Privacy of DNS lookups |
| Stops | Forged or tampered records | Snooping on which sites you visit |
| Set up by | Domain owner and resolver | Browser or device and resolver |
| Encrypts lookups | No | Yes |
DNSSEC proves answers are real. Encrypted DNS hides the questions.
For analysts
For domains customers rely on, such as banking or login pages, I'd enable DNSSEC through a provider that automates key management. The protection is worth it once the risk of manual mistakes is removed.
History & origin
DNS was designed in the 1980s without any way to verify answers. Engineers began work on DNS security extensions in the 1990s, and the modern version was published in 2005. Urgency jumped in 2008 when security researcher Dan Kaminsky revealed a flaw that made DNS cache poisoning much easier, letting attackers redirect users to fake sites. The DNS root zone was signed in July 2010, allowing a chain of trust from the top of the system down. Many country domains, including Canada's .ca run by CIRA, support DNSSEC, but signing rates among individual domains vary widely. In my view, DNSSEC is important but underused, mostly because nobody notices it until it breaks a website through a configuration mistake.