If you've ever queried a DNSSEC-enabled domain and seen cryptic records labelled DNSKEY and RRSIG, you're looking at the two workhorses of the entire DNSSEC trust chain. Understanding them isn't just academic — misconfigured DNSKEY or missing RRSIG records cause hard validation failures that silently break DNS resolution for millions of users on DNSSEC-validating resolvers. This article tears apart both record types, shows you exactly what every field means, and walks through real-world verification commands so you can diagnose and fix issues fast.

What DNSSEC Actually Does (and Why These Two Records Matter)

DNSSEC — the DNS Security Extensions — adds cryptographic signatures to DNS responses so resolvers can verify that the data hasn't been tampered with in transit. It does not encrypt DNS traffic; it authenticates it. The two records at the heart of this system are:

  • DNSKEY — stores the public key used to verify signatures on a zone's DNS records.
  • RRSIG — stores the actual cryptographic signature over a specific Resource Record Set (RRset).

Every other DNSSEC record type (DS, NSEC, NSEC3, CDS, CDNSKEY) exists to support or extend the trust relationships built by DNSKEY and RRSIG. If you understand these two, the rest falls into place naturally.

For the authoritative specification, see RFC 4034, which defines DNSKEY and RRSIG record formats.

The DNSKEY Record: Your Zone's Public Key

A DNSKEY record publishes a public cryptographic key in DNS. Resolvers use it to verify RRSIG signatures attached to other records in the same zone. Every signed zone has at least one DNSKEY, and most have two — one for each key role.

DNSKEY Record Wire Format

A DNSKEY record looks like this in a zone file:

example.com. 3600 IN DNSKEY 257 3 13 ( mdsswUyr3DPW132mOi8V9xESWE8jTo0d xCjjnopKl+GqJxpVXckHAeF+KkxLbxIL fDLUT0rAK9iUzy1L53eKGQ== )

Each field has a precise meaning:

  • Flags (257 or 256) — This is a bitmask. The critical bit is bit 8 (the Zone Key flag), which must be set for any key used to sign a zone. The other important bit is bit 15 (the Secure Entry Point flag). When both are set, the decimal value is 257. A key with flags=257 is a Key Signing Key (KSK). Flags=256 means Zone Key only — that's a Zone Signing Key (ZSK).
  • Protocol (3) — Always 3 for DNSSEC. Any other value makes the key invalid.
  • Algorithm (13) — Identifies the cryptographic algorithm. Common values: 5=RSA/SHA-1 (deprecated), 7=RSASHA1-NSEC3-SHA1, 8=RSA/SHA-256, 13=ECDSA P-256/SHA-256, 14=ECDSA P-384/SHA-384, 15=Ed25519, 16=Ed448. Algorithm 13 (ECDSA P-256) is the current recommended default for new zones.
  • Public Key (base64 blob) — The raw public key material encoded in base64.

KSK vs ZSK: Why Two Keys?

The two-key model exists for operational security. The KSK (flags=257) signs only the DNSKEY RRset itself and is referenced by the parent zone's DS record. Because changing the KSK requires a DS record update at the parent (a slower, more coordinated operation), KSKs are changed infrequently — typically annually or less. The ZSK (flags=256) signs all other RRsets in the zone (A, MX, AAAA, CNAME, etc.) and can be rolled over frequently — every 30 to 90 days — because it doesn't require parent zone coordination. This separation lets you rotate keys aggressively without constantly contacting your registrar.

💡 Want to see the live DNSKEY records for any domain right now? Use our DNS Lookup tool — select record type DNSKEY and query the authoritative nameserver directly to bypass caching.

The RRSIG Record: The Actual Signature

An RRSIG record contains a cryptographic signature over one specific RRset (all records of the same type at the same name). Every RRset in a signed zone gets its own RRSIG. A zone with 50 A records across 10 subdomains will have at least 10 RRSIG records just for the A type, plus more for MX, AAAA, NS, SOA, and so on.

RRSIG Record Wire Format

example.com. 3600 IN RRSIG A 13 2 3600 ( 20261231235959 20261201000000 12345 example.com. abc123DEF456ghi789JKL012mno345PQR 678stu901VWX234yz567ABC890def123== )

Breaking down each field:

  • Type Covered (A) — The DNS record type this signature covers. This RRSIG protects the A RRset at example.com.
  • Algorithm (13) — Must match the algorithm of the DNSKEY used to create the signature.
  • Labels (2) — The number of labels in the original owner name. For example.com, that's 2 ("example" and "com"). Used to detect wildcard expansion.
  • Original TTL (3600) — The TTL of the signed RRset at the time of signing. Stored here so the TTL can't be extended maliciously as records age in cache.
  • Signature Expiration (20261231235959) — After this timestamp, the signature is invalid. Format is YYYYMMDDHHmmSS in UTC.
  • Signature Inception (20261201000000) — Before this timestamp, the signature is also invalid. Prevents replaying old signatures.
  • Key Tag (12345) — A 16-bit integer that identifies which DNSKEY was used. Not a cryptographic value — it's a hint to help resolvers find the right key without testing all of them.
  • Signer's Name (example.com.) — The zone that holds the signing DNSKEY.
  • Signature (base64 blob) — The actual cryptographic signature.

How DNSKEY and RRSIG Work Together: The Chain of Trust

Understanding the relationship between these records requires tracing the full validation path from root to leaf:

  1. A validating resolver already trusts the root zone's public key (hardcoded as a trust anchor, currently a 2048-bit RSA key for the root KSK).
  2. The root zone publishes a DS record for .com. The DS record is a hash of .com's KSK DNSKEY. The root zone's RRSIG signs this DS record, and the resolver verifies it using the root DNSKEY.
  3. .com publishes a DS record for example.com. The .com zone's RRSIG signs it, verifiable via .com's DNSKEY.
  4. example.com publishes its own DNSKEY records. The DS record at .com hashes example.com's KSK — this is how the trust chain connects.
  5. example.com's KSK signs the DNSKEY RRset via an RRSIG (type covered = DNSKEY).
  6. example.com's ZSK signs all other RRsets (A, MX, AAAA, etc.).
  7. A resolver querying example.com's A record fetches the A RRset and its RRSIG, fetches the DNSKEY to get the ZSK, verifies the ZSK signature on the DNSKEY RRset using the KSK, verifies the KSK matches the DS record at .com — and the whole chain holds.

If any link breaks — expired RRSIG, wrong algorithm in DNSKEY, mismatched DS hash — DNSSEC-validating resolvers return SERVFAIL, and the domain appears completely unreachable to those users.

Querying DNSKEY and RRSIG Records with dig

Always use dig with +dnssec to request RRSIG records alongside your query. Without it, most resolvers suppress them.

# Fetch DNSKEY records for a zone dig example.com DNSKEY +dnssec +multiline # Fetch A record plus its RRSIG dig example.com A +dnssec +short # Query directly against authoritative NS to avoid caching issues dig @ns1.example.com example.com DNSKEY +dnssec +multiline # Check the DS record at the parent to verify the chain link dig example.com DS +dnssec +short # Request DNSSEC validation status from a validating resolver dig example.com A +dnssec @8.8.8.8 # Look for 'ad' flag in the flags line — means Authenticated Data

The ad (Authenticated Data) flag in the dig output header is the key indicator. If you see flags: qr rd ra ad, the validating resolver confirmed the chain of trust is intact. Missing ad means either the zone isn't signed or validation failed silently.

# Using nslookup (Windows-friendly) nslookup -type=DNSKEY example.com 8.8.8.8 # Linux systemd-resolved status resolvectl query example.com resolvectl status # Check RRSIG expiry field manually dig example.com RRSIG +short | awk '{print $5, $6}'

Common DNSKEY and RRSIG Failures (Ranked by Frequency)

1. Expired RRSIG (Most Common)

RRSIG records have explicit expiration timestamps. If your signing software or automation fails to re-sign the zone before existing RRSIGs expire, every validating resolver will start returning SERVFAIL. This is the single most common DNSSEC outage cause. Many operators set re-signing intervals too close to expiration with no alerting.

Fix: Re-sign the zone immediately. In BIND 9: rndc sign example.com. In PowerDNS: pdnsutil rectify-zone example.com. After fixing, verify with dig example.com RRSIG +short and confirm the expiration timestamp is in the future.

2. Mismatched DS Record After Key Rollover

After rolling your KSK, the new DNSKEY is published but the DS record at the parent registrar still points to the old key hash. The chain breaks. This is the second most common failure and it's entirely operational, not cryptographic.

Fix: Log in to your registrar's DNS management panel and update the DS record to match your new KSK. Most registrars have a DNSSEC section under domain settings. Paste the new key tag, algorithm, digest type, and digest value exactly. Wait for the parent zone's negative TTL to expire (usually 24–48 hours) and monitor with dig example.com DS @a.gtld-servers.net.

3. Algorithm Mismatch Between DNSKEY and RRSIG

The algorithm field in the RRSIG must match the algorithm field in the signing DNSKEY. If you migrate signing infrastructure and accidentally publish DNSKEY records with algorithm 13 while existing RRSIGs were created with algorithm 8, validation fails. Dig output will show RRSIGs with one algorithm number and DNSKEY records with another.

4. Clock Skew Causing Inception/Expiration Failures

If the signing server's clock is significantly off, generated RRSIGs may have inception times in the future from the perspective of resolvers, making them immediately invalid. Run timedatectl status on Linux or check NTP sync status. Maximum allowable clock skew per RFC 4034 is practically defined by the inception/expiration window — but most operators leave 5-minute leeway in inception times to handle minor drift.

5. Missing RRSIG for a Newly Added Record Type

If you add a new record type (say, a CAA record) without triggering a zone re-sign, that RRset exists unsigned. DNSSEC-validating resolvers may treat an unsigned record in a signed zone as a failure, depending on configuration. Always re-sign after any zone change.

💡 After making changes to DNSSEC records, use our DNS Propagation Checker to verify that both the DNSKEY and RRSIG records have propagated across global resolvers — especially important after a key rollover when timing is critical.

Verifying the Full Chain: Step-by-Step

  1. Query the zone's DNSKEY RRset and note the key tags for flags=257 (KSK) and flags=256 (ZSK).
  2. Query the DS record at the parent zone. Confirm the key tag and digest match the KSK DNSKEY.
  3. Query an A record with +dnssec. Confirm an RRSIG is present and that the key tag in the RRSIG matches the ZSK DNSKEY.
  4. Query the DNSKEY RRset with +dnssec. Confirm an RRSIG is present with a key tag matching the KSK.
  5. Confirm the RRSIG expiration timestamps are all in the future.
  6. Send the query through a validating resolver (8.8.8.8 or 1.1.1.1) and check for the ad flag.
# Quick one-liner chain check dig example.com A +dnssec @1.1.1.1 | grep -E 'flags:|RRSIG|SERVFAIL' # Compute the expected DS record from a DNSKEY # (using ldns-tools if available) ldns-key2ds -n -2 <(dig example.com DNSKEY +short | head -1)

2026 Considerations: IPv6, DoH, DoT, and Algorithm Agility

Several trends in 2026 directly affect DNSKEY and RRSIG operations:

  • Algorithm migration to Ed25519 (15): ECDSA P-256 (algorithm 13) remains the mainstream choice, but Ed25519 (algorithm 15) is gaining traction for new zones due to smaller key sizes and faster signing. If you're provisioning new zones in 2026, consider Ed25519. Just ensure your registrar supports DS records with algorithm 15 before committing.
  • DNS over HTTPS (DoH) and DNS over TLS (DoT): Encrypted transport doesn't eliminate the need for DNSSEC — it solves a different threat model (eavesdropping vs. data integrity). RRSIG validation still happens at the resolver end regardless of transport. If you're running your own DoH/DoT resolver (e.g., Unbound, Knot Resolver), confirm DNSSEC validation is enabled separately from transport encryption.
  • Automated DNSSEC with CDS/CDNSKEY: RFC 7344 CDS and CDNSKEY records allow automated DS updates at supporting registrars. If your registrar supports this (Cloudflare, INWX, many ccTLD registries), enabling it eliminates the most painful manual step in key rollovers. The signing software publishes a CDS record, the registrar's automation detects it and updates the DS. This dramatically reduces the risk of DS/DNSKEY mismatches.
  • IPv6 AAAA record signing: With IPv6 adoption accelerating, ensure your AAAA records have valid RRSIGs just like your A records. Many misconfigured zones sign A records but neglect AAAA RRsets after adding IPv6 addresses.

Preventing Recurrence: Operational Best Practices

  • Set RRSIG validity periods to no more than 21 days, with automatic re-signing triggered at 7 days remaining. Never rely on manual re-signing.
  • Configure alerting when any RRSIG expiration is within 3 days. Tools like Nagios, Zabbix, and the check_dnssec_expiry monitoring plugin handle this natively.
  • After every zone file change, trigger an immediate re-sign and verify with dig before considering the change complete.
  • During key rollovers, always use the double-DS / double-DNSKEY rollover procedure (RFC 6781) — publish the new key alongside the old one and wait for TTL to expire before removing the old key.
  • Document your key tags and algorithm numbers. When a DS update is needed in an emergency at 3 AM, you want this information in your runbook, not buried in a config file on a signing server.

Common Misdiagnoses to Avoid

Blaming propagation for DNSSEC failures: A SERVFAIL caused by an expired RRSIG or broken DS chain looks identical to a propagation delay from the end user's perspective — the domain just doesn't resolve. Always check the DNSSEC chain first with a direct +dnssec dig query before assuming it's a propagation issue.

Thinking SERVFAIL means the authoritative server is down: DNSSEC validation failures return SERVFAIL from the recursive resolver, not from the authoritative server. The auth server may be responding perfectly. Always test with +cd (checking disabled) to bypass validation and see if the authoritative data is actually there.

# Query with DNSSEC checking disabled to isolate auth vs. validation failure dig example.com A +dnssec +cd @8.8.8.8 # If this returns data but without +cd it returns SERVFAIL, the issue is DNSSEC

Ignoring the key tag field: The key tag is not the key ID, key fingerprint, or a hash. It's a simple 16-bit checksum. Two different keys can theoretically have the same key tag (collision). Resolvers use it as a hint, not a unique identifier. When debugging, always compare the full base64 key material, not just the tag.