What is DNSSEC? How DNS Signing Protects Your Domain

What problem does DNSSEC solve?

The original DNS protocol was designed in the 1980s with no authentication. When a recursive resolver asks an authoritative name server for a record, it simply trusts the answer it receives. This creates three well-known attack vectors:

• DNS spoofing (cache poisoning).An attacker injects a forged response into a resolver's cache. Every user of that resolver is then directed to the attacker's server instead of the real one. The famous Kaminsky attack of 2008 demonstrated that this was far easier to exploit than previously believed.
• Man-in-the-middle interception. An attacker on the network path between the resolver and the authoritative server intercepts the query and returns a fraudulent answer before the legitimate response arrives.
• Pharming attacks. A combination of DNS spoofing and phishing, where visitors are redirected to a convincing clone of your website. Because the URL in the browser looks correct, victims are far more likely to enter credentials or payment details.

DNSSEC (Domain Name System Security Extensions) solves these problems by letting the owner of a DNS zone sign every record with a cryptographic key. Resolvers that support DNSSEC validation can then verify that the response is authentic and unmodified. If the signature does not match, the resolver rejects the answer and returns an error instead of serving poisoned data.

You can check whether your domain already has DNSSEC enabled using our free DNSSEC Checker.

How DNSSEC works: the chain of trust

DNSSEC relies on a hierarchical chain of trust that mirrors the structure of DNS itself. Each level in the hierarchy vouches for the level below it, all the way from the DNS root zone down to your individual domain.

Think of it like a notarised document. The root zone is the government authority, the TLD registry is a regional notary, and your domain's signature is the stamp on the document itself. A resolver checks each stamp in order. If any stamp is missing or invalid, the entire chain fails and the answer is rejected.

Key types explained: KSK, ZSK, DS, and RRSIG

DNSSEC introduces several new DNS record types. Understanding what each one does is essential for setup and troubleshooting.

To inspect these records for any domain, use our DNS Lookup tool. It queries authoritative servers directly and displays all record types, including DNSKEY, DS, and RRSIG.

How to enable DNSSEC

Enabling DNSSEC is a two-sided process. You need your DNS provider to sign your zone, and you need your domain registrar to publish the DS record in the parent zone. Here is a step-by-step overview:

1. Check provider support. Confirm that your DNS hosting provider supports DNSSEC signing. Most major providers do, including Cloudflare, AWS Route 53, Google Cloud DNS, and Hetzner. Some providers handle the entire process with a single toggle.
2. Enable zone signing.In your DNS provider's dashboard, enable DNSSEC. The provider will generate a KSK and ZSK, sign all records in your zone, and provide you with the DS record details (key tag, algorithm, digest type, and digest value).
3. Add the DS record at your registrar. Log into your domain registrar (this may be the same company or a different one) and add the DS record to the parent zone. You will need to enter the exact values your DNS provider gave you.
4. Wait for propagation. DS record changes propagate through the DNS hierarchy. This typically takes minutes but can take up to 48 hours depending on TTL values.
5. Validate. Once propagation is complete, run a check with our DNSSEC Checker to confirm that the full chain of trust is intact from root to your domain.

If your DNS provider and registrar are the same company (e.g. Cloudflare or Google Domains), the process is often as simple as clicking a single “Enable DNSSEC” button. The provider handles both zone signing and DS record publication automatically.

DNSSEC and email security

DNSSEC is not just about website security. It plays a critical role in protecting email infrastructure by ensuring that the DNS records underpinning email authentication cannot be forged.

• DMARC, SPF, and DKIM.All three protocols rely on DNS lookups. SPF records, DKIM public keys, and DMARC policies are all stored in DNS TXT records. Without DNSSEC, an attacker who can poison a resolver's cache could serve a forged SPF record that includes their own sending IP, or a fake DKIM key that validates their spoofed signature. DNSSEC ensures these records are authentic. For more on DMARC, see our complete DMARC guide.
• MTA-STS.MTA-STS tells sending servers to use TLS when delivering email to your domain, preventing downgrade attacks. The MTA-STS policy itself is fetched over HTTPS, but the initial MX record lookup still relies on DNS. DNSSEC protects that MX lookup from being redirected to an attacker's mail server. For more detail, read our guide on MTA-STS and TLS-RPT.
• DANE (DNS-Based Authentication of Named Entities). DANE uses TLSA records in DNS to bind a TLS certificate to a specific domain and port. It is increasingly used for SMTP (RFC 7672) to guarantee that email is encrypted with the correct certificate. DANE explicitly requires DNSSEC; without it, TLSA records cannot be trusted and DANE will not function.

In short, DNSSEC is a foundational layer. It does not replace email authentication protocols, but it makes them significantly harder to circumvent. Organisations that care about email deliverability and anti-spoofing should treat DNSSEC as a prerequisite, not an afterthought.

Common pitfalls

DNSSEC is powerful, but it introduces operational complexity that catches many organisations off guard. These are the pitfalls we see most often:

• Expired RRSIG signatures. Every RRSIG record has an expiry timestamp. If your DNS provider fails to re-sign the zone before the signatures expire, validating resolvers will treat every response as bogus and your domain will effectively go offline. Most managed DNS providers handle re-signing automatically, but self-hosted DNSSEC setups require careful monitoring.
• DS record mismatch. If you change your DNS provider or roll your KSK but forget to update the DS record at your registrar, the chain of trust breaks. The parent zone points to an old key that no longer matches the new one, and validation fails for every query.
• Key rollover failures. Both the KSK and ZSK need to be rotated periodically (ZSK every few months, KSK less frequently). A failed rollover, where the new key is not yet published or the old DS record is removed too early, causes validation failures. Automated key management (as offered by Cloudflare and other providers) significantly reduces this risk.
• NSEC zone walking. The original NSEC record type allows anyone to enumerate every record in your zone by following the NSEC chain. If you want to prevent this, ensure your provider uses NSEC3, which hashes record names to make enumeration impractical.
• Forgetting to remove DS records when disabling DNSSEC. If you turn off zone signing but leave the DS record at the registrar, resolvers will still expect signed responses and fail validation. Always remove the DS record first, wait for propagation, and then disable signing.
• Increased DNS response size. DNSSEC signatures add significant data to DNS responses. This can cause issues with firewalls or middleboxes that block large UDP packets. Ensure your network infrastructure supports EDNS0 and TCP fallback for DNS.

How to check your DNSSEC status

Verifying your DNSSEC configuration should be a regular part of your domain health routine. Here is what to check:

1. DS record presence. Confirm that a DS record exists in the parent zone for your domain. Without it, DNSSEC validation cannot begin.
2. DNSKEY record presence. Confirm that your authoritative name server publishes both a KSK and ZSK in the DNSKEY record set.
3. Signature validity. Check that RRSIG records are present and have not expired. Expired signatures cause immediate validation failures.
4. Chain of trust integrity. Verify that the DS record at the parent matches the KSK published in your zone. Any mismatch breaks the chain.
5. Algorithm consistency. Ensure the algorithm specified in the DS record matches the algorithm used in the DNSKEY and RRSIG records. Mismatches cause subtle validation failures that can be difficult to diagnose.

Our DNSSEC Checker performs all of these checks automatically. Enter your domain and it will verify the full chain from root to your zone, flag any broken links, expired signatures, or mismatched keys, and provide clear guidance on what to fix.

For a broader view of your domain's security posture, including DNSSEC alongside SPF, DKIM, DMARC, MTA-STS, and TLS certificates, run a Security Grade check. It scores every layer of your domain's security in a single scan.

Next steps

Now that you understand how DNSSEC works and why it matters, here is where to go next:

• Check your domain's DNSSEC status with our free DNSSEC Checker to see whether your chain of trust is intact.
• Run a Security Grade check to assess DNSSEC, DMARC, SPF, DKIM, MTA-STS, and TLS in one scan.
• Use the DNS Lookup tool to inspect your DNSKEY, DS, and RRSIG records directly.
• Read our complete guide to DMARC to understand how email authentication and DNSSEC work together.
• Learn about SSL certificate monitoring to ensure your TLS certificates never expire unexpectedly.
• Explore our MTA-STS and TLS-RPT guide to enforce encrypted email delivery alongside DNSSEC.