DNSSEC: Signed DNS Answers for Your Domain
Every visit to your site starts with a DNS lookup that turns your domain name into an IP address. Plain DNS has no way to prove that an answer is genuine. An attacker who can inject a forged answer, for example through cache poisoning at a resolver, can send visitors to their own server. HTTPS limits the damage for websites, because the attacker cannot present a valid certificate, but DNS also directs email, certificate validation and other services that are less well protected.
DNSSEC adds cryptographic signatures to DNS records. A validating resolver checks the signatures and rejects answers that have been tampered with.
How the chain of trust works
- Your DNS provider signs the records in your zone with your zone’s keys.
- A DS record (Delegation Signer), a fingerprint of your zone’s key, is published in the
parent zone, for example
.com, through your registrar. - The parent zone is signed in turn, up to the DNS root, whose key resolvers already trust.
The DS record is what turns DNSSEC on for the outside world. Signing the zone without a DS record at the parent does nothing; publishing a DS record that does not match the zone’s keys makes your domain fail to resolve for validating resolvers.
How to enable it
Cloudflare DNS: DNS → Settings → Enable DNSSEC. Cloudflare signs the zone and shows the DS record values. If the domain is registered with Cloudflare Registrar, the DS record is added automatically. Otherwise, copy the values into your registrar’s DNSSEC settings.
Other DNS providers (Route 53, Google Cloud DNS, Azure DNS, most hosting panels) follow the same two steps: enable signing at the DNS provider, then add the DS record at the registrar. When the registrar and DNS provider are the same company, it is often a single switch.
Your own name servers (BIND, Knot, PowerDNS) can sign zones automatically with managed keys; follow your server’s DNSSEC documentation, and automate key rollovers rather than doing them by hand.
The DS record usually has four parts: key tag, algorithm, digest type and digest:
example.com. 3600 IN DS 2371 13 2 1F987CC6583E92DF0890718C42...
Algorithm 13 (ECDSA P-256 with SHA-256) is the common modern choice.
Avoiding outages
DNSSEC failures make a domain disappear for users of validating resolvers, which include large public resolvers. The risky moments are changes:
- Moving to another DNS provider. Remove the DS record at the registrar first, wait until the old DS record has expired from caches (its TTL, often a day or two), then move the name servers, and enable DNSSEC again at the new provider. Some providers support a signed migration without that gap, but follow their documented procedure exactly.
- Changing registrars. Check that the DS record is carried over.
- Key rollovers done by hand.
After any change, test with a DNSSEC analyser such as DNSViz, or from the command line:
dig DS example.com +short
dig example.com A +dnssec
The second command should return RRSIG records next to the answer, and a validating resolver
shows the ad (authenticated data) flag.
How PerfoMetrix checks this
We look up the DS record for your registrable domain (for www.shop.example.co.uk, that is
example.co.uk) through a public DNS-over-HTTPS resolver. This is a DNS query only; we send no
requests to your site.
| Result | When |
|---|---|
| Pass | a DS record exists |
| Needs attention | no DS record |
| Couldn’t test | the DNS lookup failed |
We check that DNSSEC is switched on at the parent, not that the whole chain validates. A domain with a DS record that does not match its keys would still pass here but fail for visitors, so test with a DNSSEC analyser after any change.
Further reading: RFC 4033: DNS Security Introduction and Requirements.