DNSSEC Basics: What It Protects and Whether You Need It
DNSSEC adds digital signatures to DNS answers so tampering can be detected. Learn how it works, what it does not do and the risks of enabling it badly.
DNS was designed in the early days of the internet, when little thought was given to attackers. By default, a resolver that receives a DNS answer has no way to prove that the answer is genuine. An attacker who can inject a false response, for example through a poisoned cache, could send visitors to a fake site. DNSSEC, the DNS Security Extensions, adds a way to check. It is valuable, but it also has sharp edges, so it helps to know what you are switching on.
What DNSSEC does
DNSSEC lets a zone owner sign their DNS records with cryptographic keys. A validating resolver can then check the signature to confirm two things: the answer came from the real owner of the zone, and it was not modified on the way. If the signature does not verify, the resolver refuses to return the answer.
It protects the integrity and authenticity of DNS data. It is a defence against forged answers, not a general security feature for your website.
What DNSSEC does not do
- It does not encrypt DNS queries, so observers can still see what is asked.
- It does not encrypt your web traffic. You still need HTTPS.
- It does not protect you if your registrar or DNS account is compromised, because an attacker with access can change records and sign them.
- It does not stop phishing sites that use look-alike domain names.
- It only helps visitors whose resolvers perform validation.
How it works, in simple terms
Keys and signatures
Your zone has keys published in DNSKEY records. The records in the zone are signed, and the signatures appear in RRSIG records. A validating resolver fetches the keys and checks the signatures.
The chain of trust
How does a resolver know the keys are real? The parent zone vouches for them. A DS (delegation signer) record, published in the parent zone, such as the registry for your extension, holds a fingerprint of your key. The parent is in turn signed by its own parent, up to the root of DNS. A broken link anywhere in this chain makes validation fail.
| Record | Purpose | Where it lives |
|---|---|---|
| DNSKEY | Public key for the zone | In your zone |
| RRSIG | Signature over a set of records | In your zone |
| DS | Fingerprint of your key, linking to the parent | At the registry, via your registrar |
| NSEC or NSEC3 | Proof that a name does not exist | In your zone |
Enabling DNSSEC
- Check that your DNS host supports DNSSEC signing and that your registrar and the registry for your extension accept DS records. Not every extension supports it.
- Turn on signing at the DNS host. It generates the keys and publishes
DNSKEYrecords. - Copy the DS record details, such as key tag, algorithm, digest type and digest, from the DNS host to your registrar's DNSSEC settings.
- Wait for the DS record to appear at the registry, and test with a DNSSEC checking tool.
The order matters. Publishing a DS record before the zone is correctly signed makes the domain fail validation, and visitors using validating resolvers will not be able to reach it.
The risks
- A misconfiguration can take the domain offline for validating users, which includes large parts of the internet.
- Moving DNS providers is more delicate. If the new provider does not sign the zone or use the same keys while the old DS record is still published, validation fails. The usual approach is to remove the DS record, wait for it to expire, move, and then re-enable.
- Key rollovers need care. Reputable DNS hosts automate them. Manual management is for specialists.
- Expiring signatures. If signing stops working, signatures can expire and take the domain down.
Do you need it?
For many small business sites, DNSSEC is optional. It is a sensible hardening step if your DNS host makes it a one-click, fully managed feature, and you are not about to move the domain. It matters more for banks, government and organisations where redirecting traffic would be seriously harmful. If your provider offers managed DNSSEC and you understand the move process, enabling it is reasonable. If setup requires manual key handling and you do not have expertise, spend that effort first on stronger basics: two-step sign-in on your registrar and DNS accounts, registry lock on the domain, and HTTPS everywhere.
Before transfers and migrations
If DNSSEC is on and you plan to change DNS providers or transfer the domain, plan the DNSSEC step in advance. Disable it cleanly, wait for the old DS record's TTL to expire, make the change, and re-enable at the new provider. This is the most common reason for unexplained outages after a DNS move.
DNS security and Zebra Hosting
Securing your DNS accounts, using HTTPS and keeping your site updated are the practical foundations. Zebra Hosting provides free SSL certificates and Cloudflare CDN on hosted sites, and support in 17 languages can advise on DNS changes. See the security page, learn about SSL, or open the knowledge base.
