Guides DNSSEC
What is DNSSEC?
DNSSEC (Domain Name System Security Extensions) puts a mark of authenticity on your DNS answers, like a watermark on a banknote. Plain DNS has no such check: a resolver (the service that turns domain names into addresses) believes the answer that comes back, whoever sent it. With DNSSEC every answer carries a signature the resolver can verify. If it doesn't check out, the resolver returns nothing rather than an address that may have been tampered with.
How does the check work?
Your DNS zone (all of your domain's records) is signed with a set of keys. Each group of records then gets a signature (RRSIG). One level up, at the party that runs your TLD (e.g. .nl), sits a small DS record holding a 'fingerprint' of your key. This forms an unbroken chain of trust, all the way from the DNS root through the TLD down to your domain.
A 'validating' resolver walks that chain. If everything checks out, it returns the answer. If a signature doesn't match, it returns an error (SERVFAIL) instead of a possibly forged address.
The records at a glance
DNSKEY: your zone's public keysDS: sits one level up (at your registrar/TLD) and anchors your key into the chainRRSIG: the signature attached to each group of recordsNSEC/NSEC3: prove, in a signed way, that a record specifically does not exist
In practice you mainly deal with two things: your DNS provider signing the zone, and the DS record you place at your registrar.
Why you need this
Without DNSSEC an attacker can forge DNS answers (a trick called 'cache poisoning') and silently send your visitors to a fake server, for instance to a phishing copy of your login page. DNSSEC makes such tampering detectable.
It's also a prerequisite for DANE/TLSA, which lets you declare in DNS which TLS certificate is valid. For mail servers in particular that's a strong extra layer of security.
Watch out: strict and unforgiving
DNSSEC is secure, but unforgiving. If the chain no longer checks out, for instance because the DS record doesn't match your key anymore, validating resolvers answer with SERVFAIL. For everyone using such a resolver your domain isn't 'unsecured' but really gone: no website, no mail. The large public resolvers do validate, so that hits nearly all your visitors.
This most often happens during a move to a different DNS provider or a failed key change. So only enable DNSSEC if your provider and registrar support the linkage well, and check after every change.
Turning it on step by step
- Have your DNS provider sign the zone (often a single button or switch)
- Get the
DSrecord (or key data) from your provider - Place that
DSrecord at your registrar: the party where you registered the domain - Wait for it to propagate and check that the chain is valid (the DNS Radar scan shows this)
- Ever want to turn it off? Do it in the right order: remove the
DSfirst, and only then unsign the zone. The other way around breaks the chain
Frequently asked questions
Is DNSSEC mandatory?
No, but it's strongly recommended for domains where integrity matters. Many governments and banks now require it.
What's the difference between DNSKEY and DS?
DNSKEY are the keys in your own zone. The DS record lives in the parent zone (at your registrar) and anchors those keys into the chain of trust.
Does DNSSEC encrypt my DNS traffic?
No. DNSSEC guarantees integrity and authenticity, not confidentiality: answers stay readable. For privacy of your DNS queries you use DoH or DoT.
Why is my domain unreachable after a provider switch?
Most likely the DS record at your registrar no longer matches the new DNSKEY, breaking the chain so resolvers return SERVFAIL. Update the DS or remove it temporarily.
How do I check that DNSSEC works?
The DNS Radar scan shows whether your zone is signed and whether the chain validates. For the hands-on reader: a validating resolver sets the AD flag on a correctly verified answer.