DNSSEC Records: How Signing Keys and Delegation Records Fit Together

Ordinary DNS answers can be forged, because the original protocol did not ask a resolver to verify who produced an answer. DNSSEC, the DNS Security Extensions, adds signatures so that a resolver can check that an answer came from the zone owner and was not altered on the way. The system rests on keys: a zone publishes its public keys in DNSKEY records, signs its records with the matching private keys, and the parent zone publishes a DS record, a delegation signer, which is a fingerprint of the child's key. A resolver that trusts the parent can follow that fingerprint down to the child, and then trust the child's signatures. Break any link in that chain and validation fails, even if every individual record looks fine on its own.

The DNSSEC Checker takes DNSKEY or DS records you paste in and checks whether their fields are well formed. A DNSKEY record carries flags, a protocol value, an algorithm number, and the public key material itself, encoded in base64. The flags distinguish a zone-signing key from a key-signing key: the value 257 marks a key-signing key, while 256 marks a zone-signing key, and the distinction matters because only the key-signing key is normally fingerprinted by the parent. A DS record carries a key tag, an algorithm, a digest type, and the digest itself, in hexadecimal. The checker reads those fields and reports whether the shape is right; it does not perform a live validation, and it cannot confirm that the parent actually publishes the DS record you pasted.

Algorithm numbers are a frequent source of confusion. Algorithm 8 means RSA with SHA-256, algorithm 13 means ECDSA with P-256 and SHA-256, and algorithm 15 means Ed25519. These numbers are not interchangeable, and a DS record whose algorithm does not match the DNSKEY it fingerprints describes a different key. Digest types matter in the same way: type 2 means SHA-256, and a digest computed with one type cannot be compared against a digest of another type. Key tags are short numeric identifiers derived from the key, and they exist so that a resolver can quickly find the right key among several, but a key tag alone proves nothing, because two different keys can share a tag by chance.

Worked example

Worked example with sample values. Suppose you paste a sample DNSKEY record with flags 257, protocol 3, algorithm 13, and a base64 key, plus a sample DS record with key tag 12345, algorithm 13, digest type 2, and a 64-character hexadecimal digest. Counting the digest characters gives 64, and 64 divided by 2 equals 32 bytes, which is exactly the length of a SHA-256 digest, so the length matches digest type 2. Counting the DNSKEY fields gives 4 fields before the key material, and the flags value 257 confirms a key-signing key, which is the kind a parent fingerprints. The algorithm numbers agree, both 13, so the two sample records at least describe the same kind of key. These are sample values only, invented to show the field checks, not keys copied from a live zone, and a real key must never be pasted from a production zone into an untrusted page.

Now suppose the DS digest is changed by a single character, from ending in a to ending in b. The record still has 64 hexadecimal characters and still passes a shape check, but the fingerprint no longer matches the key, and a validating resolver would reject the zone. That is why shape checking is only the first step: the digest must be generated from the actual key by the registrar or the signing software, never typed by hand, and any re-signing or key rollover must update the DS record at the parent in the same maintenance window, or the zone will fail validation until the two sides agree again.

Mistakes to avoid

The first mistake is treating a well-formed record as a validated zone. Shape is necessary but not sufficient; the parent DS record, the child DNSKEY record, and the signatures must all agree, and only a validating resolver can confirm that agreement. The second mistake is rolling a key, generating a new DNSKEY record, and forgetting to update the DS record at the registrar, which leaves the parent pointing at a retired key. The third mistake is pasting a private key instead of a public key, which is a serious disclosure: DNSKEY records contain public keys only, and a private key must never leave the signing system. The fourth mistake is mixing algorithm numbers between the DNSKEY and DS records, which makes the fingerprint describe a key it does not belong to.

A further trap is assuming that DNSSEC protects the content of a website. It protects the DNS answers, not the traffic that follows, and a site still needs its own transport security for that. DNSSEC also does not hide queries or prevent a resolver from being asked in the first place. Judge it for what it does, which is to let a resolver detect forged or altered DNS answers, and pair it with the other controls that protect the connection itself.

Putting it into practice

Use the checker when preparing a DNSSEC deployment, when auditing a zone after a key rollover, and when a validation failure needs to be narrowed down to a record problem rather than a resolver problem. Paste the DNSKEY and DS records separately, confirm the flags, algorithm and digest type on each, and compare the key tag and digest against the values your registrar and your signing software report. Keep the key material in the system that generated it, update parent and child together, and re-check after every change. A chain of trust is only as strong as its weakest link, and in DNSSEC that link is usually a record that was updated on one side and forgotten on the other.

Related tools and reading: the DNSSEC Validator, the DNS Lookup cover neighbouring checks that pair naturally with this one, and the guide at [/blog/caa-lookup-guide/] extends the same topic with further background and examples for readers who want to go deeper.

Key points

  • DNSKEY publishes the public key; DS fingerprints it at the parent
  • Flags 257 marks a key-signing key, 256 a zone-signing key
  • Algorithm and digest type must agree on both records
  • Shape checks never prove a zone validates

In short: DNSSEC links a child zone to its parent through a key fingerprint. The checker reads pasted DNSKEY or DS records. Matching algorithms, key tags and digests keep the chain intact. Shape alone never proves validation.

One habit ties all of this together: re-check after every change. A result from the DNSSEC Checker is only as current as the input it was run on, so a fix, a redesign, or a new version of the underlying material deserves a fresh run rather than reliance on an old report. Keep the previous result alongside the new one, note what changed between them, and treat any new finding as a question to investigate rather than a verdict to accept or dismiss. That loop of checking, fixing, re-checking and recording is what turns a one-off test into a reliable routine, and it costs far less time than debugging a problem that a second check would have caught early.