skip to content

How do a DNSSEC DS record's key tag, algorithm, digest type and digest identify one child DNSKEY, and why must new DS records not use SHA-1?

level: seniorimportance: should knowfreq 15%

answer

  1. a fingerprint, not a copy
  2. owner name plus RDATA
  3. 1, 2, 4: SHA-1, SHA-256, SHA-384
  4. registry columns since RFC 9904

basics

~20 s

A DS holds a child key's key tag and algorithm to narrow the search, a digest type, and a digest of the key's owner name and RDATA. SHA-1 (type 1) is MUST NOT under RFC 9904's registry and RFC 9905; use SHA-256 (type 2).

solid answer

~50 s

A `DS` record (RFC 4034 §5) carries four fields: the **key tag** and **algorithm** of the child `DNSKEY` it refers to, a **digest type**, and a **digest** computed as `hash(canonical owner name | DNSKEY RDATA)`, where the RDATA is flags, protocol, algorithm and public key. A validator finds DNSKEYs with that tag and algorithm, hashes each and compares; the referenced key MUST have the Zone Key bit set. Digest types: `1` SHA-1, `2` SHA-256 (RFC 4509), `4` SHA-384 (RFC 6605). In the IANA registry RFC 9904 established, SHA-256 is RECOMMENDED for delegation and SHA-1 is MUST NOT; RFC 9905 repeats that and also forbids DS records for keys using the SHA-1 signing algorithms 5 and 7, which resolvers must treat as insecure. RFC 4509 already told validators to ignore a SHA-1 DS when a SHA-256 one is present.

code

dns · 9 lines
dns
; parent side (net zone) for example.net
example.net. 3600 IN DS 55648 13 2 (
        b4c8c1fe2e7477127b27115656ad6256f424625bf5c1
        e2770ce6d6e37df61d17 )

; child side (example.net zone)
example.net. 3600 IN DNSKEY 257 3 13 (
        GojIhhXUN/u4v54ZQqGSnyhWJwaubCvTmeexv7bR6edb
        krSqQpF64cYbcB7wNcP+e+MAnLr+Wi9xMWyQLc8NAA== ) ; key tag 55648

go deeper

for a junior

Recall that the DS lives in the parent and holds a hash of a child key, not the key itself.

for a middle

Explain the four fields, what goes into the digest, and which digest type numbers map to which hashes.

for a senior

Check a DS against a child key by hand, and explain why a SHA-1 or algorithm 5 or 7 DS now leaves a delegation effectively unsigned.

for a principal

Plan the clean-up of legacy DS records across many delegations, weighing the risk of a silent insecure delegation against a disruptive change.

## The DS record's four fields The `DS` (Delegation Signer, type 43) record sits on the parent side of a delegation and points at one key in the child zone (RFC 4034 §5.1): | Field | Size | Example value | Meaning | |---|---|---|---| | Key Tag | 2 octets | `55648` | Key tag of the referenced DNSKEY | | Algorithm | 1 octet | `13` | That DNSKEY's signing algorithm number | | Digest Type | 1 octet | `2` | Hash used to build the digest | | Digest | variable | `b4c8c1fe...` | Hash of the DNSKEY's owner name and RDATA | The **algorithm** field is easy to misread: it is the *child key's signing algorithm*, the same numbering DNSKEY and RRSIG use, not the hash. The hash is named by the **digest type**. ## How the digest is built RFC 4034 §5.1.4 defines it precisely: `digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA )`, with `DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key`. Three consequences come straight out of that formula: 1. **The owner name is inside the hash.** The same public key published at two zones produces two different digests, so a DS for one zone cannot vouch for that key in another. 2. **The flags are inside the hash.** A key whose flags change (256 to 257, or the RFC 5011 REVOKE bit) no longer matches its old DS, and its key tag changes too. 3. **Only the digest proves the match.** Key tag and algorithm exist to make the search efficient; RFC 4034 Appendix B warns that key tags are not unique. RFC 4034 §5.2 adds that the referenced DNSKEY MUST be a zone key (Zone Key bit set); otherwise neither the DS nor the key may be used for validation. ## Digest types, then and now When RFC 4034 was written, SHA-1 (20-octet digest) was the only digest type. Later documents added: - **Type 2, SHA-256** — RFC 4509, 32-octet digest. Implementations MUST support it, and validators SHOULD ignore a SHA-1 DS when a SHA-256 DS is present in the same RRset, which blocks a downgrade to the weaker hash. - **Type 4, SHA-384** — RFC 6605, 48-octet digest. RFC 9904 (obsoleting RFC 8624) moved the guidance into columns of the IANA "Digest Algorithms" registry: | Type | Hash | Use for delegation | Use for validation | |---|---|---|---| | 1 | SHA-1 | MUST NOT | RECOMMENDED | | 2 | SHA-256 | RECOMMENDED | RECOMMENDED | | 4 | SHA-384 | MAY | RECOMMENDED | The "validation" column keeps validators able to read old DS records; the "delegation" column stops anyone creating new ones. RFC 9905 (November 2025) updated the SHA-1 entry with itself as reference, and went further on the signing side: DS records MUST NOT be created for keys using RSASHA1 (5) or RSASHA1-NSEC3-SHA1 (7), and resolver operators MUST treat such DS records as insecure, and the whole delegation as insecure when no other acceptable DS exists. ## Why SHA-1 has to go RFC 9905's reasoning is operational as much as cryptographic: SHA-1's strength has been eroding, stronger algorithms are universally available, and some systems have already removed SHA-1 validation support, so SHA-1 "is no longer fully interoperable in the context of DNSSEC". A delegation whose only DS uses a hash or algorithm the validator treats as unsupported gives that validator no supported path to the child; RFC 4509 §4 (for an unsupported digest type) and RFC 9905 (for the SHA-1 algorithms) both say the child is then treated as insecure, that is, unsigned. The zone then silently loses its protection rather than failing loudly — which is exactly why an operator should replace a type 1 DS with a type 2 one rather than leaving it in place. ## Reading a DS against its key - Match the key tag and algorithm to a DNSKEY at the child apex. - Check the referenced key has the Zone Key bit (flags 256 or 257). - Recompute the digest over the child's owner name and that key's RDATA, with the named hash. - Prefer type 2; a type 1 DS on a new delegation is a defect to fix.

  • A parent shows both a SHA-1 and a SHA-256 DS for the same DNSSEC child key; what should a validator and the operator do?
    RFC 4509 tells validators to ignore the SHA-1 DS when a SHA-256 DS is present, so validation rests on type 2. The operator should still remove the type 1 record: the IANA registry RFC 9904 set up marks SHA-1 as MUST NOT for delegation, and RFC 9905 reaffirms it.
  • Why does a DS record carry the key tag and algorithm when the digest alone would identify the key?
    RFC 4034 §5 says the digest should be enough, and the tag and algorithm only make finding the key efficient: a validator can skip keys that cannot match. Because tags can collide, a tag match never replaces the digest comparison; it only shortens the list of keys to hash.

saying these in an interview costs you the question

  • The DS record contains a copy of the child's public key.
  • The DS digest covers only the public key, so changing flags is harmless.
  • The DS algorithm field names the hash used for the digest.
  • Keeping a SHA-1 DS beside the SHA-256 one is still recommended practice.
  • A DS may point at any DNSKEY, whether or not its Zone Key bit is set.