What is DNSSEC and how does it protect your website?

DNSSEC (Domain Name System Security Extensions) is a set of extensions to DNS that adds cryptographic signatures to your domain's DNS records. When a visitor's DNS resolver looks up your domain, it can check those signatures and confirm that the answer really came from your domain's authoritative nameservers and wasn't altered on the way. That protects your website and email from attacks such as DNS cache poisoning and spoofed responses, which could otherwise send visitors to a fake server without them noticing.

DNS was designed decades ago, when trust between systems on the internet was assumed. It has no built-in way to prove an answer is genuine, and DNSSEC fills that gap. In this article you'll learn how DNS lookups work, what problem DNSSEC solves, how the chain of trust fits together, what it doesn't protect against, and how to turn it on for your own domain without breaking anything.

A Quick Refresher on How DNS Works

When someone types example.com into a browser, their device needs the server's IP address. It asks a recursive resolver, usually run by their ISP, their company, or a public service such as Cloudflare (1.1.1.1), Google (8.8.8.8), or Quad9 (9.9.9.9).

The resolver finds the answer by walking down the DNS hierarchy:

1. Root servers: The resolver asks a root server where to find .com.
2. TLD servers: The .com servers reply with the nameservers responsible for example.com.
3. Authoritative nameservers: Your DNS provider's servers return the actual record, such as an A record with the IP address.
4. Caching: The resolver caches the answer for the record's TTL (time to live), so later lookups are faster.

Traditional DNS answers are plain, unsigned data, usually sent over UDP. A resolver has no reliable way to tell a genuine answer from a forged one that arrives first and looks correct.

What Problem Does DNSSEC Solve?

Because unsigned DNS answers can't be verified, several attacks are possible.

DNS Cache Poisoning

In a cache poisoning attack, an attacker tricks a recursive resolver into caching a forged record, for example one that points yourbank.example at an attacker-controlled IP address. Every user of that resolver then gets the fake answer until the cached entry expires. Resolvers have added defences over the years, such as randomising source ports and query IDs, but these make poisoning harder rather than impossible.

Spoofed Responses and On-Path Attacks

An attacker who can see or intercept network traffic, such as on a compromised router or a hostile Wi-Fi network, can reply to DNS queries with forged answers. Without signatures, the resolver simply accepts them.

Why It Matters for Your Website

If visitors are sent to the wrong server, the consequences can include:

• Phishing pages that look identical to your login or checkout page.
• Malware downloads served from what appears to be your domain.
• Intercepted email if your MX records are spoofed.
• Loss of trust and reputation when customers are harmed.

HTTPS does help here, because an attacker usually can't present a valid certificate for your domain. But not every service uses TLS correctly, users sometimes click through warnings, and email delivery between servers often doesn't validate certificates strictly. DNSSEC protects the lookup itself, before any connection is made.

How DNSSEC Works

DNSSEC doesn't encrypt DNS. Anyone can still see which domains are being looked up. Instead, it adds authentication and integrity: proof that the records came from the right source and weren't modified.

The Key DNSSEC Record Types

DNSSEC introduces a few new record types:

• DNSKEY: Holds the public keys for your zone. Resolvers use these to verify signatures.
• RRSIG: A digital signature for a set of records (for example, all A records for www). Every signed record set has a matching RRSIG.
• DS (Delegation Signer): A hash of your zone's key, published in the parent zone (for example, in .com). It links your zone to its parent.
• NSEC / NSEC3: Signed proof that a record doesn't exist, so an attacker can't forge a "this domain doesn't exist" answer.

Zone Signing and Key Signing Keys

Most setups use two kinds of keys:

• Zone Signing Key (ZSK): Signs the everyday records in your zone, such as A, AAAA, MX, and TXT.
• Key Signing Key (KSK): Signs the DNSKEY record set that contains the ZSK. The hash of the KSK is what goes into the DS record at your registrar.

Splitting the roles lets your DNS provider rotate the ZSK regularly without having to update the DS record at the parent each time. Some providers use a single combined key (a Combined Signing Key), which works the same way from your point of view.

The Chain of Trust

Verification works from the top of the DNS tree downwards:

1. The root zone is signed: Validating resolvers ship with the root zone's trust anchor, the public key they trust by default.
2. The TLD is signed: The root zone publishes a DS record for .com, which vouches for the .com keys.
3. Your domain is signed: The .com zone publishes a DS record for example.com, which vouches for your KSK.
4. Your records are signed: Your KSK signs your ZSK, and your ZSK signs your records.

If every link checks out, the resolver marks the answer as authentic. If any signature is invalid or missing where one is expected, a validating resolver refuses to return the answer and gives the user a SERVFAIL error instead. That's the key protection: a forged answer simply fails.

What DNSSEC Doesn't Protect Against

DNSSEC is valuable, but it's narrowly focused. It doesn't:

• Encrypt DNS queries: For privacy, look at DNS over HTTPS (DoH) or DNS over TLS (DoT), which encrypt the connection between a device and its resolver.
• Protect against a compromised registrar or DNS account: If an attacker logs in to your DNS provider and changes a record, the provider will sign the malicious record just like a real one. A registrar lock and strong account security handle that risk.
• Protect your web server or website: Vulnerable plugins, weak passwords, and server misconfigurations are separate problems.
• Work if the resolver doesn't validate: Protection only applies to users whose resolver checks signatures. Many large public resolvers and ISPs do, but not all.

Does DNSSEC Slow Down Your Website?

In practice, the performance impact is small. Signed responses are larger, because they include signatures, and validating resolvers do a little extra work. Modern algorithms such as ECDSA P-256 (algorithm 13) produce compact signatures, and resolvers cache the keys and results, so most visitors won't notice any difference. Your web pages, images, and scripts load exactly as before, since DNSSEC only affects the DNS lookup.

Is DNSSEC Right for Your Domain?

For most websites, enabling DNSSEC is worthwhile when your DNS provider and registrar both support it well, because it closes a real gap at little cost. It's especially useful for:

• Sites that handle logins, payments, or personal data.
• Domains used for business email.
• Organisations that are likely phishing targets.
• Domains used with DANE for email security, which depends on DNSSEC.

The main risk is operational. A misconfigured DNSSEC setup, such as a stale DS record after changing DNS providers, can make your entire domain unreachable for users of validating resolvers. That's not a reason to avoid DNSSEC, but it is a reason to understand the process before you change anything.

How to Enable DNSSEC

The process has two parts: signing your zone at your DNS provider, and publishing the DS record at your registrar. If your registrar also hosts your DNS, it may do both with a single toggle.

Step 1: Turn On Signing at Your DNS Provider

Log in to wherever your DNS is hosted, which may be your registrar, a dedicated DNS provider like Cloudflare, or your hosting company. Look for a DNSSEC option in the DNS settings and enable it. For example, in Cloudflare it's under DNS > Settings, where you click Enable DNSSEC.

The provider generates the keys, signs your zone, and shows you the DS record details. A DS record looks something like this (values are illustrative):

example.com. 3600 IN DS 2371 13 2 1F987CC6583E92DF0890718C42C4D1B4D7D7F1E3A2C1B9E8D7C6B5A4F3E2D1C0

The four fields after DS are:

• Key tag: 2371, a short identifier for the key.
• Algorithm: 13, meaning ECDSA P-256 with SHA-256.
• Digest type: 2, meaning SHA-256.
• Digest: The hash of your public key.

Step 2: Add the DS Record at Your Registrar

Now log in to your registrar, open the domain's settings, and find the DNSSEC or DS Records section. Enter the key tag, algorithm, digest type, and digest exactly as your DNS provider shows them. Some registrars ask for the public key (DNSKEY) instead of, or as well as, the digest.

If your DNS provider and registrar are the same company, or if they support automatic DS updates (CDS and CDNSKEY records), this step may happen for you.

Step 3: Wait and Verify

Changes to the parent zone can take anywhere from a few minutes to a day or two to appear, depending on the TLD and TTLs. Once they're live, verify the setup using dig from a terminal:

# Check the DS record published in the parent zone
dig example.com DS +short

# Check your DNSKEY records
dig example.com DNSKEY +short

# Ask a validating resolver and look for the "ad" flag
dig @1.1.1.1 example.com A +dnssec

In the output of the last command, look at the flags line. If it includes ad (Authenticated Data), the resolver validated the answer successfully:

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

You can also use visual tools such as Verisign's DNSSEC Debugger or DNSViz, which show every link in the chain of trust and highlight any broken ones.

Common DNSSEC Mistakes and How to Avoid Them

Most DNSSEC outages come from a handful of avoidable mistakes:

1. Changing DNS providers without updating DS: If you move your DNS to a new provider while the old DS record is still at your registrar, validating resolvers will reject every answer. The safe approach is to disable DNSSEC and remove the DS record at your registrar first, wait for the old DS record's TTL to expire (often a day or two), switch providers, then re-enable DNSSEC with the new provider's DS record.

2. Typing the DS record incorrectly: A single wrong character in the digest breaks validation. Copy and paste values rather than typing them.

3. Leaving a DS record after disabling signing: If you turn off DNSSEC at your DNS provider, remove the DS record at the registrar first and wait before turning off signing.

4. Mismatched algorithms: Make sure the algorithm number at the registrar matches what your provider uses.

5. Expired signatures on self-managed servers: If you run your own authoritative nameservers with BIND or Knot, signatures have expiry dates. Use automated signing and key rollover rather than manual processes.

If you ever see a sudden SERVFAIL for your domain from public resolvers while your nameservers are answering normally, a broken DNSSEC chain is a likely cause. You can confirm by querying with validation disabled:

dig @1.1.1.1 example.com A +cd

The +cd flag (checking disabled) tells the resolver to skip validation. If this works while the normal query fails, the problem is almost certainly DNSSEC.

---

FAQ: DNSSEC

---

Conclusion

DNSSEC adds something DNS never originally had: a way to prove that an answer is genuine. By signing your records and linking your keys to the parent zone through a DS record, it lets validating resolvers reject forged or tampered responses, protecting your visitors from cache poisoning and spoofing before they ever connect to your site.

Turning it on is usually a matter of flipping a switch at your DNS provider and adding one record at your registrar. The main thing to respect is the order of operations, particularly when changing DNS providers. Verify your setup with dig or DNSViz after enabling it, keep your registrar and DNS accounts well protected, and DNSSEC will quietly add a strong layer of trust to every lookup of your domain.