DNSSEC Explained: What It Is and Whether You Need It

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS responses, allowing resolvers to verify that the answer they received came from the authoritative nameserver and hasn't been tampered with. It solves a genuine security problem in standard DNS, but comes with operational complexity that catches people out when they change nameservers without handling DNSSEC correctly.

The Problem DNSSEC Solves

Standard DNS has no authentication built in. A resolver asks a nameserver for an IP address and gets an answer, but nothing in the protocol proves that answer is genuine or hasn't been modified in transit. This vulnerability enables DNS cache poisoning (also called DNS spoofing): an attacker injects false records into a resolver's cache, silently redirecting users to a malicious server while the URL in the browser still shows the legitimate domain.

The Kaminsky attack, publicly disclosed in 2008, demonstrated that DNS cache poisoning could be executed far more easily than the security community had assumed. This prompted widespread adoption of source port randomisation as a partial mitigation, and accelerated DNSSEC deployment as the long-term solution.

DNSSEC closes the authentication gap by letting resolvers cryptographically verify that every DNS response in the chain was produced by the legitimate authoritative server and hasn't been modified.

How DNSSEC Works

DNSSEC uses public key cryptography. Each DNS zone has two key pairs:

• Zone Signing Key (ZSK): signs the actual DNS records in the zone. The private ZSK signs the data; the public ZSK is published in the zone as a DNSKEY record.
• Key Signing Key (KSK): signs the ZSK. The private KSK signs the DNSKEY records; the public KSK is published both in the zone and, as a DS (Delegation Signer) record, in the parent zone.

When a DNSSEC-validating resolver looks up a record, it retrieves the DNS data plus RRSIG (Resource Record Signature) records. It then fetches the DNSKEY records to verify the RRSIG, checks the KSK against the DS record in the parent zone, and traces the chain of trust all the way up to the root zone (which publishes its own keys). If every signature in the chain validates, the response is authenticated. If any signature fails, the resolver returns SERVFAIL rather than an unverified answer.

What DNSSEC Does Not Do

DNSSEC provides authenticity and integrity, it proves the DNS answer is genuine. It does not provide confidentiality. DNS queries and responses are still transmitted in plaintext and visible to anyone monitoring the network. For encrypted DNS queries, see DNS over HTTPS.

DNSSEC also doesn't protect traffic between your visitors and your server (that's HTTPS), prevent access by unauthorised users, or defend against application-layer attacks. It's specifically a defence against DNS-level spoofing and cache poisoning.

Should You Enable It?

For most personal and small business websites, DNSSEC is a worthwhile security measure with low marginal cost once it's configured. The main operational risk is making a nameserver change without updating the DS record: if the DS record at your registrar points to an old KSK that no longer exists at your new nameservers, DNSSEC-validating resolvers will return SERVFAIL for your domain, a complete outage for users on those resolvers (Google and Cloudflare's public resolvers both validate DNSSEC).

DNSSEC is most valuable for domains where DNS hijacking would cause serious harm: financial services, healthcare portals, critical infrastructure, or any domain where being redirected to a malicious server could result in credential theft or fraud. For a simple blog or brochure site, the risk is lower, but enabling DNSSEC is still a reasonable hardening step.

How to Enable DNSSEC

The process has two parts: enable DNSSEC at your DNS provider (which generates and signs the zone), then publish the DS record at your registrar (which activates the chain of trust).

1. Enable DNSSEC in your DNS provider's settings. This generates the Zone Signing Key and Key Signing Key, and begins signing all records in your zone.
2. Your DNS provider gives you a DS record value. It contains: a key tag number, an algorithm number, a digest type number, and a hex digest string.
3. Log in to your domain registrar and find the DNSSEC section (sometimes called "DS Records"). Add the DS record values provided by your DNS provider.
4. Wait for propagation. The DS record needs to spread to the TLD nameservers and be picked up by resolvers, which can take a few hours.

Cloudflare makes this particularly straightforward: their dashboard has a one-click DNSSEC enablement button under DNS > Settings. It generates the DS record values and provides them in the exact format needed for your registrar.

To verify DNSSEC is working correctly after enabling it:

dig yourdomain.com A +dnssec

Look for an RRSIG record in the answer section. You can also use our DNS Lookup to query the RRSIG and DNSKEY records directly and confirm the chain is intact.

The Golden Rule: DS Records and Nameserver Changes

The most important operational rule for DNSSEC is this: if you change nameservers, remove the DS record at your registrar first. Only add the new DS record after the new DNS provider has fully signed the zone and you've verified the new nameservers are responding correctly.

The sequence for a safe nameserver change with DNSSEC enabled:

1. Remove the DS record from your registrar. This disables DNSSEC validation for your domain temporarily (DNS will still work, just without DNSSEC).
2. Wait for the DS record removal to propagate (a few hours).
3. Change the nameservers to the new provider.
4. Enable DNSSEC at the new DNS provider and get the new DS record values.
5. Add the new DS record at your registrar.

Skipping step 1 and 2, changing nameservers while the old DS record is still active, will make your domain unresolvable for all DNSSEC-validating resolvers. This is one of the most common and impactful DNS misconfigurations.