DNSSEC

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS responses, allowing resolvers to verify that the data they receive is authentic and has not been modified in transit. It protects against cache poisoning and man-in-the-middle attacks on DNS.

How DNSSEC Works

A zone operator generates a key pair and uses the private key to sign every record set in the zone. Each signature is published alongside the records as an RRSIG record. When a validating resolver receives a response, it uses the zone's public key (published as a DNSKEY record) to verify the RRSIG. If the signature is valid and not expired, the resolver knows the data is authentic.

To prevent attackers from substituting a fake DNSKEY, the zone's public key is itself authenticated by the parent zone through a DS (Delegation Signer) record. This creates a chain of trust from the root zone down to your domain.

Key Records

• DNSKEY - contains the zone's public signing key. There are typically two: a Key Signing Key (KSK) used to sign the DNSKEY record set, and a Zone Signing Key (ZSK) used to sign all other records.
• RRSIG - the cryptographic signature covering a specific record set. Every record type in a signed zone has a corresponding RRSIG. Signatures have an expiration date and must be regenerated before they expire.
• DS - a hash of the child zone's KSK, stored in the parent zone. This is what links the child zone's trust to the parent. You configure the DS record at your domain registrar.
• NSEC / NSEC3 - provide authenticated denial of existence. When a queried name does not exist, the server returns an NSEC or NSEC3 record proving that no such name exists in the zone. NSEC3 uses hashed names to prevent zone walking (enumeration of all names in the zone).

Chain of Trust

DNSSEC validation starts at the root zone, which is signed with a well-known key (the root trust anchor). The root zone contains DS records for each TLD. Each TLD zone is signed and contains DS records for its child zones. This chain continues until it reaches your domain.

For example, validating www.example.com involves:

1. The root zone's DNSKEY validates the DS record for .com
2. The .com zone's DNSKEY (verified via the DS) validates the DS record for example.com
3. The example.com zone's DNSKEY (verified via the DS) validates the RRSIG on the A record for www.example.com

If any link in this chain is broken, validation fails and the resolver returns a SERVFAIL to the client.

Should You Enable DNSSEC?

Yes, if your registrar and DNS provider both support it. DNSSEC prevents a class of attacks where an attacker intercepts DNS queries and returns forged responses to redirect traffic. It is particularly important for domains that handle financial transactions, email, or authentication.

Caveats to be aware of:

• Key rotation complexity. ZSKs should be rotated regularly (every 1-3 months). KSKs are rotated less frequently but require updating the DS record at the registrar, which is a coordination step that can go wrong.
• Can break resolution if misconfigured. An expired RRSIG, a missing DS record, or an algorithm mismatch will cause validating resolvers to return SERVFAIL, making your domain unreachable for users behind those resolvers. This is worse than not having DNSSEC at all.
• Larger responses. DNSSEC adds RRSIG, DNSKEY, and NSEC/NSEC3 records to responses, increasing their size. This can cause issues with UDP fragmentation, though EDNS0 and TCP fallback mitigate this in practice.

Common Issues

• Expired signatures. RRSIG records have explicit expiration timestamps. If your signing system stops re-signing (due to a crash, misconfigured cron job, or provider outage), signatures expire and validation fails. Monitoring signature expiration is critical.
• Missing DS record at registrar. You can sign your zone all you want, but if the DS record is not published in the parent zone, resolvers have no way to build the chain of trust. This is a common oversight when migrating DNS providers.
• Algorithm mismatch. The DS record must reference the correct algorithm used by your DNSKEY. If you change algorithms during a key rollover without updating the DS, the chain of trust breaks.
• Dangling DS after disabling. If you disable DNSSEC at your DNS provider but leave the DS record at the registrar, validating resolvers will expect signed responses and fail when they receive unsigned ones. Always remove the DS record first, wait for TTL expiry, then disable signing.

Check your domain's DNSSEC with the DNS lookup tool →