DNSSEC Technical Reference (RFC 4033/4034/4035)

What This Reference Covers

DNSSEC — DNS Security Extensions — is defined across three companion RFCs, all published in March 2005:

• RFC 4033 — Introduction and requirements
• RFC 4034 — Resource record definitions (DNSKEY, RRSIG, DS, NSEC)
• RFC 4035 — Protocol modifications for validation

These three RFCs supersede the original DNSSEC specification (RFC 2535) and have been updated by RFC 6840 (clarifications and implementation notes) and RFC 9276 (NSEC3 guidance). Together they define how DNS responses can be cryptographically authenticated — proving that the data came from the zone owner and has not been modified in transit.

This reference is organized by topic rather than by RFC number. When a concept spans multiple RFCs, the relevant section numbers are cited inline.

---

The Problem DNSSEC Solves (RFC 4033 §1–§3)

"The Domain Name System (DNS) [...] is not designed to provide authentication or integrity assurance. [...] The DNS Security Extensions were designed to address these deficiencies." — RFC 4033 §1

DNS was designed in 1983 as a distributed naming system. It has no built-in mechanism to verify that a DNS response is authentic — that it actually came from the authoritative server and was not modified by an intermediary. This leaves DNS vulnerable to several attacks:

• Cache poisoning — An attacker injects forged records into a recursive resolver's cache, causing all clients of that resolver to receive false data. The Kaminsky attack (2008) demonstrated that this could be done at scale against unprotected resolvers.
• On-path modification — An attacker positioned between a resolver and an authoritative server modifies responses in transit.
• Resolver impersonation — An attacker responds to queries faster than the legitimate server, providing forged data that the resolver accepts and caches.

What DNSSEC Does

DNSSEC adds data origin authentication and data integrity protection to DNS. When a zone is signed, every record set (RRset) gets a cryptographic signature. A validating resolver can verify that:

1. The data was signed by the zone owner's private key
2. The data has not been modified since signing
3. The zone owner's key is vouched for by the parent zone, all the way up to the DNS root

What DNSSEC Does Not Do

"DNSSEC does not provide confidentiality." — RFC 4033 §1

DNSSEC does not encrypt DNS queries or responses. All data remains visible in plaintext. DNSSEC answers the question "is this data authentic?" — not "is this data private?" DNS encryption is addressed by separate protocols: DNS over HTTPS (DoH, RFC 8484) and DNS over TLS (DoT, RFC 7858).

DNSSEC also does not protect against denial-of-service attacks, does not authenticate the resolver itself, and does not prevent zone enumeration (though NSEC3 provides limited mitigation).

---

The Chain of Trust (RFC 4033 §5, RFC 4035 §5)

"A security-aware resolver can use [...] an authenticated chain of trust from a preconfigured trust anchor to the data." — RFC 4033 §5

DNSSEC authentication follows the DNS hierarchy. Each signed zone publishes its public keys and signs its records. The parent zone publishes a DS (Delegation Signer) record that hashes the child zone's key, creating a cryptographic link. This chain extends from the target domain all the way up to the DNS root zone, which serves as the global trust anchor.

Chain of Trust: Root to Leaf

  ┌─────────────────────────────┐
  │  Root Zone (.)              │
  │  DNSKEY: Root KSK + ZSK    │
  │  RRSIG: signs all RRsets    │
  │  DS for .com → ─────────┐  │
  └─────────────────────────│──┘
                            │
  ┌─────────────────────────▼──┐
  │  .com Zone                 │
  │  DNSKEY: .com KSK + ZSK   │
  │  RRSIG: signs all RRsets   │
  │  DS for example.com → ──┐  │
  └─────────────────────────│──┘
                            │
  ┌─────────────────────────▼──┐
  │  example.com Zone          │
  │  DNSKEY: example.com keys  │
  │  RRSIG: signs all RRsets   │
  │  (MX, A, TXT, etc.)       │
  └────────────────────────────┘

Validation proceeds top-down:

1. The resolver trusts the root zone's KSK (preconfigured trust anchor — published by IANA, known to all validating resolvers)
2. The root zone's DS record for .com is signed by the root ZSK — the resolver verifies this signature
3. The .com zone's DNSKEY is verified against the root's DS record
4. The .com zone's DS record for example.com is signed by .com's ZSK — verified
5. example.com's DNSKEY is verified against .com's DS record
6. example.com's data records (MX, A, TXT) are verified against example.com's RRSIG using example.com's DNSKEY

If any link in this chain is missing, expired, or invalid, validation fails. The resolver returns a SERVFAIL response — the data is not trusted.

Check it: The mxio DNSSEC Checker walks the entire chain from root to your domain and reports any broken links. See DNSSEC Chain Broken if validation fails.

---

Resource Record Types (RFC 4034)

DNSSEC introduces four new DNS record types. Understanding what each one does and where it lives is essential for deployment and troubleshooting.

DNSKEY — Public Keys (RFC 4034 §2)

"A DNSKEY record holds a public key that is associated with a zone." — RFC 4034 §2

The DNSKEY record publishes the zone's cryptographic public keys. A signed zone typically has two keys, each serving a different role:

The two-key model exists for operational reasons. The KSK is referenced by the parent zone's DS record, so changing it requires coordination with the parent (registrar). The ZSK is internal to the zone and can be rotated without any external coordination.

Example DNSKEY Record

example.com.  3600  IN  DNSKEY  257  3  13  (
    mdsswUyr3DPW132mOi8V9xESWE8jTo0dxCjj
    dnopKl+GqJxpVXckHAeF+KkxLbxILfDLUT0r
    AQKkGoSMDMJPOPahJ+aq
)

• 257 — flags field, indicating this is a KSK (bit 7 set = Secure Entry Point)
• 3 — protocol field (always 3 for DNSSEC)
• 13 — algorithm number (13 = ECDSA P-256 with SHA-256)
• The remaining data is the base64-encoded public key

RRSIG — Signatures (RFC 4034 §3)

"An RRSIG record contains the signature for an RRset with a particular name, class, and type." — RFC 4034 §3

Every RRset (a set of DNS records with the same name, class, and type) in a signed zone has a corresponding RRSIG record. The RRSIG contains the cryptographic signature that a resolver uses to verify the data has not been tampered with.

Example RRSIG Record (Annotated)

example.com.  3600  IN  RRSIG  MX  13  2  3600  (
    20260501000000    ; Signature expiration (UTC)
    20260401000000    ; Signature inception (UTC)
    12345             ; Key tag (identifies which DNSKEY signed this)
    example.com.      ; Signer's name
    oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
    PYGv07h108dUKGMeDPKijVCHX4bSqMxgqYS
)

Key fields:

The expiration and inception fields are critical operational parameters. If signatures expire and the zone is not re-signed, validation fails for the entire zone. This is the most common cause of DNSSEC outages. See DNSSEC Signatures Expired for remediation.

DS — Delegation Signer (RFC 4034 §5)

"The DS Resource Record refers to a DNSKEY RR and is used in the DNS DNSKEY authentication process." — RFC 4034 §5

The DS record is the glue between parent and child zones. It is published in the parent zone and contains a hash of the child zone's KSK. This is how .com vouches for example.com, and how example.com vouches for sub.example.com.

Example DS Record

example.com.  3600  IN  DS  12345  13  2  (
    49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
)

• 12345 — key tag (matches the key tag of the child's KSK)
• 13 — algorithm of the referenced DNSKEY
• 2 — digest type (2 = SHA-256)
• The remaining data is the hash digest of the child's KSK

The DS record is the only DNSSEC record that requires coordination with the parent zone. When you enable DNSSEC for your domain, you generate the KSK and provide the DS record (or its parameters) to your registrar, who publishes it in the parent zone. If the DS record is missing, the chain of trust is broken at your domain.

Check it: The mxio Delegation Health tool verifies that DS records are correctly published at the parent and match the child zone's DNSKEY.

NSEC and NSEC3 — Authenticated Denial of Existence (RFC 4034 §4, RFC 5155)

"The NSEC record is used to prove that a name does not exist in a zone." — RFC 4034 §4

DNSSEC must be able to prove not only that data is authentic, but also that a queried name does not exist. Without this, an attacker could forge NXDOMAIN responses to redirect traffic or deny service.

NSEC (Next Secure) records form a chain of all existing names in a zone, in canonical order. Each NSEC record says "the next name after X is Y, and X has records of types A, MX, TXT." If a queried name falls between X and Y, the resolver can prove it does not exist.

The problem with NSEC is that it enables zone walking — an attacker can enumerate every name in the zone by following the NSEC chain.

NSEC3 (RFC 5155) addresses this by hashing the domain names. Instead of revealing the actual names, NSEC3 records chain hashes. This makes zone enumeration computationally harder (though not impossible with offline dictionary attacks).

RFC 9276 provides current guidance on NSEC3 deployment: it recommends using NSEC3 with zero additional iterations and no opt-out, or using plain NSEC if zone enumeration is not a concern. High iteration counts were once recommended but are now discouraged because they increase CPU cost for both signers and validators without providing meaningful additional protection against enumeration.

---

Algorithm Numbers (RFC 4034 §A.1)

DNSSEC supports multiple cryptographic algorithms, identified by number. Algorithm choice affects security strength, signature size, and compatibility with resolvers.

For new deployments, algorithm 13 (ECDSA P-256) is the recommended choice. It provides strong security with small key and signature sizes, reducing DNS response sizes and the risk of UDP fragmentation. Algorithm 8 (RSA/SHA-256) remains widely deployed and is fully acceptable, but produces larger responses.

Algorithm 5 (RSA/SHA-1) should be treated as end-of-life. Zones still using it should plan a migration to algorithm 13 or 8. The mxio DNSSEC Checker flags deprecated algorithms.

Algorithm Rollover

Changing the DNSSEC algorithm for a zone is more complex than a routine key rollover. It requires publishing keys and signatures for both the old and new algorithms simultaneously during a transition period, because resolvers that know about the zone's DS record will expect signatures from the algorithm specified in that DS. An algorithm rollover typically follows the same general process as a KSK rollover, with the additional constraint that both algorithm sets must coexist.

---

Signature Validation (RFC 4035 §4–§5)

"A security-aware resolver MUST be able to perform the following functions: [...] verify the cryptographic signatures in RRSIG RRs." — RFC 4035 §4

When a validating resolver receives a DNS response, it performs the following steps to authenticate the data:

1. Fetch the DNSKEY RRset for the signer's zone
2. Verify the RRSIG over the data using the corresponding DNSKEY (matched by key tag and algorithm)
3. Check signature validity window — current time must fall between inception and expiration
4. Check the labels field — detects if the response was generated from a wildcard (the labels count will be less than the query name's label count)
5. Verify the DNSKEY against the parent zone's DS record — confirm the key is authorized
6. Walk the chain — repeat steps 1–5 up through each parent zone until reaching the trust anchor (root zone)

If any step fails — expired signature, missing DS record, algorithm mismatch, key tag not found — the resolver returns SERVFAIL and the data is not delivered to the client. This is a hard failure. Unlike SPF or DMARC, where failures are policy decisions, a DNSSEC validation failure means the resolver refuses to return the data at all.

The AD Flag

When a resolver successfully validates a response, it sets the AD (Authenticated Data) flag in the DNS response header. Stub resolvers (like the one on your workstation) can check this flag to determine whether the data was DNSSEC-validated — but only if they trust the path to their recursive resolver.

The mxio DNSSEC Checker performs its own full chain validation rather than relying on the AD flag, ensuring accurate results regardless of the resolver path.

---

Key Rollover (RFC 4035 §Appendix, RFC 6781)

"Zone administrators should plan for key replacement." — RFC 4035 §4.4

DNSSEC keys must be changed periodically — to limit the exposure if a key is compromised, to follow cryptographic best practices, and because some algorithms have recommended key lifetimes.

ZSK Rollover

ZSK rollovers are zone-internal operations. The most common approach is the pre-publication method:

1. Pre-publish: Add the new ZSK to the DNSKEY RRset alongside the old one. Wait for the old DNSKEY RRset's TTL to expire so all caches have the new key.
2. Sign with new key: Re-sign all RRsets with the new ZSK. The old ZSK remains in the DNSKEY RRset.
3. Remove old key: After the longest RRSIG TTL has expired, remove the old ZSK from the DNSKEY RRset.

No coordination with the parent zone or registrar is needed because the DS record references the KSK, not the ZSK.

KSK Rollover

KSK rollovers require coordination with the parent zone because the DS record must be updated. The double-DS method is commonly used:

1. Generate new KSK and add it to the DNSKEY RRset
2. Submit new DS record to the parent zone (via registrar) while keeping the old DS
3. Wait for the parent's DS RRset TTL to expire — both old and new DS records are in the parent
4. Sign DNSKEY RRset with new KSK only — remove the old KSK
5. Remove old DS from the parent zone

The critical risk in KSK rollover is timing. If the old DS is removed before all resolvers have cached the new DNSKEY, or if the new DS is published before the new DNSKEY propagates, validation fails and the zone becomes unreachable. RFC 6781 provides detailed guidance on rollover timing.

---

Operational Considerations

Signature Lifetime and Re-signing

RRSIG records have explicit expiration times. When a signature expires, the data it covers can no longer be validated — resolvers treat it as bogus. This means zones must be re-signed regularly, before existing signatures expire.

Typical signature lifetimes range from 1 to 4 weeks. The zone should be re-signed well before expiration — at least 2–3 days early to account for propagation delays and operational issues. Automated signing (available in most modern DNS hosting platforms, including Cloudflare, AWS Route 53, and Google Cloud DNS) eliminates the risk of manual re-signing failures.

If your signatures expire, all DNSSEC-validating resolvers will return SERVFAIL for your domain — effectively taking your domain offline for anyone using a validating resolver. See DNSSEC Signatures Expired for emergency remediation.

Response Size and Fragmentation

DNSSEC adds significant data to DNS responses — DNSKEY records, RRSIG records, and NSEC/NSEC3 records. Signed responses are typically 2–5x larger than unsigned responses. This can cause UDP fragmentation or exceed the 512-byte traditional UDP limit.

EDNS0 (RFC 6891) extends the UDP payload size, and most modern resolvers support buffer sizes of 1232–4096 bytes. If a response exceeds the negotiated buffer size, the server sets the TC (Truncated) flag and the resolver retries over TCP. Firewalls that block DNS over TCP or strip EDNS0 options break DNSSEC. See DNSSEC Query Failures for troubleshooting.

Using ECDSA (algorithm 13) instead of RSA (algorithm 8) significantly reduces response sizes. An ECDSA P-256 signature is 64 bytes versus 256+ bytes for RSA-2048.

What Breaks When DNSSEC Fails

DNSSEC failures are binary — there is no "soft fail" mode. When validation fails, the resolver returns SERVFAIL. The querying application receives no data. For a mail domain, this means:

• MX lookups fail — sending servers cannot find your mail servers
• SPF lookups fail — receivers cannot evaluate your SPF record
• DKIM key lookups fail — receivers cannot verify DKIM signatures
• DMARC lookups fail — receivers cannot find your policy

A DNSSEC outage is effectively a complete DNS outage for all clients behind validating resolvers. The recovery path depends on the cause: re-sign the zone if signatures expired, fix the DS record if the chain is broken, or remove DNSSEC entirely as a last resort (by removing DS records from the parent and waiting for propagation).

---

DNSSEC and Email Authentication

DNSSEC does not directly participate in email authentication — it does not check message content, headers, or sender identity. But it provides the foundation on which email authentication DNS lookups depend.

What DNSSEC Protects

Every email authentication check starts with a DNS lookup:

Without DNSSEC, all of these lookups are vulnerable to cache poisoning. An attacker who can poison a resolver's cache can effectively disable SPF, DKIM, and DMARC for any domain — or worse, redirect mail delivery entirely by poisoning MX records.

DNSSEC as Foundation for DANE

DANE (RFC 7672, RFC 6698) uses DNSSEC-signed TLSA records to publish TLS certificate expectations for SMTP. DANE requires DNSSEC — without it, TLSA records cannot be trusted and are ignored. For organizations that want the strongest possible SMTP transport security, DNSSEC is a prerequisite, not an option.

Practical Considerations

DNSSEC adoption for email domains remains uneven. Most large email providers (Gmail, Microsoft 365, Yahoo) validate DNSSEC when resolving DNS for incoming mail, meaning they will reject responses that fail DNSSEC validation. But many domains do not sign their zones, so these providers cannot validate what is not signed.

For domain owners, the decision to deploy DNSSEC involves weighing the security benefit (authenticated DNS for all lookups) against the operational risk (signature expiry and key management can cause outages if not automated). If your DNS hosting provider offers managed DNSSEC (automatic signing, key rotation, DS record management), the operational burden is minimal and the security benefit is real.

Check it: Use the mxio Domain Health check to see how DNSSEC status interacts with your overall email authentication posture. The DNSSEC Checker provides detailed chain validation, algorithm inspection, and signature expiry monitoring.

---

Quick Reference

---

This reference covers RFC 4033, RFC 4034, and RFC 4035 — DNS Security Introduction and Requirements, Resource Records for the DNS Security Extensions, and Protocol Modifications for the DNS Security Extensions — authored by R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Supplementary RFCs referenced: RFC 5155 (NSEC3), RFC 6781 (DNSSEC operational practices), RFC 6840 (clarifications), RFC 9276 (NSEC3 guidance), RFC 7672 (DANE for SMTP). Content on this page is an editorial interpretation; see the original RFCs for normative text. RFC content is subject to the IETF Trust's Legal Provisions.