DS vs DNSKEY vs RRSIG: DNSSEC Records Explained

DNSSEC lets a resolver check that a DNS answer really came from the zone's owner and was not altered on the way. It does this with three record types that work together: RRSIG, DNSKEY and DS. If you understand how they connect, almost every DNSSEC error message becomes readable.

RRSIG: signatures over record sets

In a signed zone, every set of records with the same name and type (an RRset) has an RRSIG record next to it containing a digital signature.

example.com. 3600 IN A     192.0.2.10
example.com. 3600 IN RRSIG A 13 2 3600 20261120000000 20261020000000 31589 example.com. kq3F…

The important fields are:

• Type covered (A): which RRset this signs.
• Algorithm (13 = ECDSA P-256 with SHA-256).
• Expiration and inception: the signature is only valid between these two timestamps (UTC). Outside that window it is rejected, even if the cryptography is correct.
• Key tag (31589): a short number identifying which key made the signature.
• Signer name: the zone that signed it.

DNSKEY: the zone's public keys (KSK vs ZSK)

To check a signature, a resolver needs the zone's public key. Zones publish these as DNSKEY records at the apex:

example.com. 3600 IN DNSKEY 257 3 13 mdsswUyr3DPW…   ; KSK, key tag 2371
example.com. 3600 IN DNSKEY 256 3 13 oJMRESz5E4gY…   ; ZSK, key tag 34505

The first number is a set of flags. 256 is a zone key; 257 adds the "secure entry point" bit, which marks a key-signing key (KSK). Most zones use two roles:

• the KSK signs only the DNSKEY RRset itself;
• the zone-signing key (ZSK) signs everything else.

Splitting the roles means the ZSK can be rotated without involving the parent zone. Some setups use a single combined key, which is equally valid.

A key tag is not stored in the DNSKEY record. It is calculated from the key's data, which is how a resolver matches an RRSIG or DS to its key.

What is a DS record? The link from the parent

A DNSKEY published by the zone can't vouch for itself—an attacker could publish their own. Trust has to come from above. The parent zone stores a DS (delegation signer) record, which is a hash of the child's KSK:

example.com. 86400 IN DS 2371 13 2 8F09A6…

The fields are the key tag (2371), the key's algorithm (13), the digest type (2 = SHA-256), and the digest itself. Because the DS lives in the parent zone, it is signed by the parent's keys—and so on up to the root, whose key resolvers have built in as a trust anchor.

You publish the DS record through your registrar. Your DNS provider generates it; some registrars ask for the DNSKEY instead and compute the DS themselves.

How the DNSSEC chain of trust is validated

For an A record at www.example.com, a validating resolver checks the chain from the top down:

1. The com zone's DS record for example.com is validly signed by com.
2. One of example.com's DNSKEY records hashes to exactly that DS digest.
3. That key has signed the DNSKEY RRset, so every key in the set is now trusted.
4. The RRSIG over the A record was made by one of the trusted keys, verifies correctly and is within its validity window.

If every step holds, the resolver sets the AD (authenticated data) flag. If a step fails, the answer is bogus: the resolver returns SERVFAIL instead of possibly forged data.

Signed, unsigned and broken

There are three distinct states, and only one of them is a problem:

• Secure: DS in the parent, matching keys and valid signatures. Answers are authenticated.
• Insecure: no DS record in the parent. Resolvers accept answers without validation. This is the normal state of an unsigned domain, not an error.
• Bogus: a DS record exists, but the chain cannot be verified. The domain stops resolving for everyone behind a validating resolver.

A zone can carry DNSKEY and RRSIG records with no DS in the parent—signing is switched on, but the chain is not connected yet. That is insecure, not broken.

The DNSSEC checker fetches the DS from the parent's servers and the DNSKEYs from each of your nameservers, recomputes the digests, and shows where the chain holds and where it breaks. When something is broken, common DNSSEC failures covers the usual causes.