DNSSEC Information & TLDRs

Quick reference guides, explanations, and everything you need to know about DNSSEC

TLDRs - Quick Answers

What is DNSSEC?

Basics

DNSSEC (DNS Security Extensions) is a suite of extensions to DNS that adds cryptographic authentication to DNS responses. It prevents DNS spoofing and cache poisoning attacks by allowing DNS resolvers to verify that DNS data has not been tampered with. Think of it as SSL/TLS for DNS - it provides authenticity and integrity, but not confidentiality.

How does DNSSEC work?

Basics

DNSSEC uses public-key cryptography to sign DNS records. Each zone has a private key to sign records and a public key (DNSKEY) published in DNS. Resolvers use these keys to verify that responses are authentic and haven't been modified. The chain of trust starts at the root zone and extends down through TLDs to your domain.

What are DS records?

Records

DS (Delegation Signer) records are published in the parent zone and contain a hash of the child zone's DNSKEY. They create a chain of trust from the root zone down to your domain. When you enable DNSSEC, you get DS records that must be added to your domain's parent zone (usually your registrar).

What are DNSKEY records?

Records

DNSKEY records contain the public keys used for DNSSEC. There are two types: Key Signing Keys (KSK) for signing other keys, and Zone Signing Keys (ZSK) for signing DNS records. The KSK is used to sign the ZSK, and the ZSK signs the actual DNS records.

What are RRSIG records?

Records

RRSIG (Resource Record Signature) records contain cryptographic signatures for DNS record sets. Each RRSIG covers a specific record type (A, AAAA, MX, etc.) and proves that the records are authentic and haven't been tampered with. Resolvers verify these signatures using the corresponding DNSKEY.

NSEC vs NSEC3

Records

NSEC and NSEC3 are used for authenticated denial of existence (proving a record doesn't exist). NSEC reveals zone structure by listing all record types, while NSEC3 uses cryptographic hashing to hide zone structure. NSEC3 is generally preferred for security as it prevents zone enumeration attacks.

What is the Chain of Trust?

Concepts

The chain of trust is the hierarchical validation path from the root zone → TLD → your domain. Each level signs the next level down using DS records. The root zone is the trust anchor that everyone trusts. This chain must be unbroken for DNSSEC validation to succeed.

KSK vs ZSK

Concepts

Key Signing Key (KSK) is a long-lived key (rotated every 1-2 years) used to sign Zone Signing Keys. Zone Signing Key (ZSK) is shorter-lived (rotated every 3 months) and signs actual DNS records. This two-key system allows for more frequent ZSK rotation without affecting the parent zone.

Do I need DNSSEC?

Basics

DNSSEC is recommended for all domains, especially those handling sensitive data, financial transactions, or email. It prevents DNS-based attacks like cache poisoning and man-in-the-middle attacks. Many security standards (like PCI DSS) recommend or require DNSSEC.

What algorithms are supported?

Technical

Common DNSSEC algorithms include RSA-SHA256 (algorithm 8), RSA-SHA512 (algorithm 10), ECDSAP256SHA256 (algorithm 13), and ECDSAP384SHA384 (algorithm 14). ECDSA algorithms are preferred for smaller key sizes and better performance. Algorithm 13 is the most common modern choice.

How do I enable DNSSEC?

Setup

Enable DNSSEC through your DNS provider or registrar. They'll generate keys and provide DS records. Add these DS records to your domain's parent zone (usually via your registrar's control panel). The process varies by provider but typically takes a few minutes to propagate.

What happens if DNSSEC validation fails?

Troubleshooting

If DNSSEC validation fails, resolvers will return SERVFAIL or refuse to return the DNS data, preventing users from accessing your site. This protects against tampered responses but means any misconfiguration will break your site. Always test thoroughly before enabling.

Key Concepts

⛓️

Chain of Trust

The hierarchical trust model from root zone → TLD → domain that validates DNSSEC signatures. Must be unbroken for validation to succeed.

🔐

Key Signing Key (KSK)

A long-lived key used to sign Zone Signing Keys. Typically rotated every 1-2 years. Creates DS records for parent zone.

🔑

Zone Signing Key (ZSK)

A shorter-lived key used to sign DNS records. Typically rotated every 3 months. Signs actual DNS data.

🔢

Algorithm

The cryptographic algorithm used for DNSSEC. Common: RSA-SHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14).

📊

Digest Type

The hash algorithm used in DS records. SHA-256 (2) is most common. SHA-1 (1) is deprecated.

⏰

RRSIG Expiration

RRSIG records have expiration times. Records must be re-signed before expiration or validation fails. Typical validity: 2-4 weeks.

🚫

Authenticated Denial

NSEC/NSEC3 records prove a record doesn't exist, preventing attackers from claiming non-existent records.

🚶

Zone Walking

Attack technique to enumerate all records in a zone. NSEC3 prevents this by hashing record names.

⚓

Trust Anchor

The root zone's public key that everyone trusts. This is the starting point of the chain of trust.

DNSSEC Record Types

TypeNamePurpose
DSDelegation SignerLinks child zone to parent, contains hash of DNSKEY
DNSKEYDNS KeyPublic keys for signing (KSK and ZSK)
RRSIGResource Record SignatureCryptographic signatures for record sets
NSECNext SecureAuthenticated denial, reveals zone structure
NSEC3Next Secure v3Authenticated denial with hashing, hides structure
NSEC3PARAMNSEC3 ParametersParameters for NSEC3 hashing algorithm

DNSSEC Algorithms

IDNameStatusNote
1RSA/MD5DeprecatedNot recommended
3DSA/SHA1DeprecatedNot recommended
5RSA/SHA1DeprecatedNot recommended
7RSASHA1-NSEC3-SHA1DeprecatedNot recommended
8RSA/SHA-256CommonWidely supported
10RSA/SHA-512CommonWidely supported
13ECDSAP256SHA256RecommendedModern, efficient
14ECDSAP384SHA384RecommendedModern, higher security
15Ed25519ModernNewer, efficient
16Ed448ModernNewer, higher security

DNSSEC Articles & Deep Dives

Understanding DNSSEC: A Complete Guide

DNSSEC (DNS Security Extensions) is a critical security protocol that adds cryptographic authentication to the Domain Name System. Unlike traditional DNS, which is vulnerable to spoofing and cache poisoning attacks, DNSSEC ensures that DNS responses are authentic and haven't been tampered with.

The protocol uses public-key cryptography, where each DNS zone has a pair of keys: a private key (kept secret) and a public key (published in DNSKEY records). When a DNS resolver receives a response, it can verify the signature using the public key, ensuring the data's integrity and authenticity.

DNSSEC provides three key security properties: authenticity (proves data came from the authoritative source), integrity (proves data hasn't been modified), andauthenticated denial (proves a record doesn't exist). However, it does not provide confidentiality - DNS data remains unencrypted.

The DNSSEC Chain of Trust Explained

The chain of trust is the foundation of DNSSEC validation. It creates a hierarchical path of trust from the root zone (the ultimate trust anchor) down through top-level domains (TLDs) to your specific domain.

Here's how it works:

  1. Root Zone: The root zone's public key is the trust anchor that everyone trusts. This key is hardcoded into DNS resolvers and browsers.
  2. TLD Level: The root zone signs the TLD's (like .com, .org) DNSKEY using a DS record. This creates the first link in the chain.
  3. Domain Level: The TLD signs your domain's DNSKEY using another DS record, completing the chain.

If any link in this chain is broken or missing, DNSSEC validation fails, and resolvers will refuse to return the DNS data, protecting users from potentially malicious responses.

Key Signing Keys vs Zone Signing Keys

DNSSEC uses a two-key system for operational flexibility and security:

Key Signing Key (KSK)

  • • Long-lived (1-2 years)
  • • Signs Zone Signing Keys
  • • Creates DS records for parent zone
  • • Flag 256 (SEP bit set)
  • • Less frequent rotation

Zone Signing Key (ZSK)

  • • Shorter-lived (3 months)
  • • Signs actual DNS records
  • • Creates RRSIG records
  • • Flag 128 (Zone Key bit set)
  • • More frequent rotation

This separation allows for more frequent ZSK rotation without requiring changes to the parent zone's DS records, which would require coordination with your registrar.

NSEC vs NSEC3: Which Should You Use?

Both NSEC and NSEC3 provide authenticated denial of existence, but they differ significantly in their approach to security and privacy.

NSEC (Next Secure) records list all record types that exist for a domain name, creating a chain that proves non-existence. However, this reveals your entire zone structure, making it vulnerable to zone enumeration attacks where attackers can discover all your subdomains.

NSEC3 (Next Secure version 3) solves this problem by using cryptographic hashing. Instead of listing actual domain names, NSEC3 records contain hashed values, making it computationally infeasible to enumerate your zone. NSEC3PARAM records define the hashing parameters.

Recommendation: Use NSEC3 for production domains to prevent zone enumeration. NSEC is acceptable for test environments or when zone enumeration is not a concern.

Common DNSSEC Algorithms: A Comparison

DNSSEC supports multiple cryptographic algorithms, each with different characteristics:

RSA Algorithms (8, 10): Widely supported and well-tested. RSA-SHA-256 (algorithm 8) is the most common. RSA-SHA-512 (algorithm 10) provides stronger security but larger key sizes.

ECDSA Algorithms (13, 14): Modern, efficient algorithms. ECDSAP256SHA256 (algorithm 13) provides equivalent security to RSA-3072 with much smaller keys (256 bits vs 3072 bits). ECDSAP384SHA384 (algorithm 14) offers even stronger security.

Edwards-Curve Algorithms (15, 16): The newest options. Ed25519 (algorithm 15) and Ed448 (algorithm 16) are highly efficient but have less widespread support.

Best Practice: Use algorithm 13 (ECDSAP256SHA256) for new deployments. It offers the best balance of security, performance, and compatibility.

Troubleshooting DNSSEC Issues

Common DNSSEC problems and their solutions:

Validation Failures

If DNSSEC validation fails, check: DS records are correctly added to parent zone, DNSKEY records are published, RRSIG records are present and not expired, and the chain of trust is unbroken.

Expired Signatures

RRSIG records have expiration times. If signatures expire before being re-signed, validation fails. Ensure your DNS provider automatically re-signs records before expiration.

Key Rotation Problems

When rotating keys, maintain both old and new keys during the transition period. Update DS records in the parent zone only after the new key is fully propagated.

Learn More

For detailed implementation guides, check out our Guides section. For hands-on tools to validate, analyze, and manage DNSSEC, visit our Tools page.

Use our DNSSEC Checker to quickly verify if a domain has DNSSEC enabled and properly configured.