Skip to content
Control Plane Labs

DS record

Published in the parent zone, fingerprints a child zone's key and links the DNSSEC chain of trust.

Last updated July 27, 2026

Zone-file example

example.com.  86400  IN  DS  60485 13 2 D4B7D520E7BB5F0F67674A0CCEB1E3E0614B93C4...

Typical uses

  • Enabling DNSSEC validation for a zone, by lodging the digest at the registrar
  • Linking a delegated subdomain's own signing key into the parent chain
  • Publishing two DS records during a key-signing-key rollover
  • Removing DNSSEC cleanly, by deleting the DS before unsigning the zone

When it breaks, check

  • A DS that no longer matches any DNSKEY makes the whole zone SERVFAIL for validating resolvers
  • You cannot fix a bad DS in your own zone — it lives in the parent, edited via the registrar
  • Parent TTLs are long, so a broken DS outage lasts as long as resolvers keep caching it
  • Publish the new DS and wait out the TTL before retiring the old key, never the other way round

What the DS record does

DNSSEC trust is a chain of these records. Resolvers hold the root’s key directly; the root publishes a DS for com, com publishes one for example.com, and each commits the parent to a specific key in the child.

That is the whole risk profile. DNSSEC does not degrade gracefully. If the DS points at a key your zone no longer uses, validating resolvers return SERVFAIL rather than falling back, and every name in the zone disappears at once. Non-validating resolvers keep working, which is what makes the incident confusing to triage.

Zone-file and wire format

The RDATA is four fields: key tag, algorithm, digest type, digest. The key tag is a 16-bit checksum over the DNSKEY RDATA, a matching hint rather than an identifier, since collisions are legal. Algorithm must match the referenced DNSKEY exactly. Digest type selects the hash: 1 is SHA-1, no longer acceptable for new delegations, 2 is SHA-256 and the default, 4 is SHA-384. The digest covers the child’s fully qualified owner name concatenated with the DNSKEY RDATA, so a DS is bound to the name as well as the key. Digests here are truncated; a real SHA-256 value is 64 hex.

; key tag   algorithm   digest type   digest
;   60485       13            2         SHA-256 of owner name + DNSKEY RDATA
;               |             |
;               |             +-- 1=SHA-1 (legacy), 2=SHA-256, 4=SHA-384
;               +---------------- 13 = ECDSA P-256 with SHA-256

example.com.  86400  IN  DS  60485 13 2 D4B7D520E7BB5F0F67674A0CCEB1E3E0614B93C4...

; during a KSK rollover both are published in the parent for one TTL
example.com.  86400  IN  DS  31589 13 2 A1B2C3D4E5F60718293A4B5C6D7E8F90A1B2C3D4...

Common uses

In practice a DS is created once, when you enable DNSSEC, by generating the digest from your DNSKEY and pasting it into the registrar’s control panel. After that it is touched only during key-signing-key rollovers. Because that handoff is manual and out-of-band, RFC 7344 defines CDS and CDNSKEY: records the child publishes to signal the DS it wants, so the parent can poll and update automatically. If your registrar supports CDS, use it.

Troubleshooting

Diagnose in one direction: fetch the DS from the parent, fetch the DNSKEY set from the child, and confirm a key exists whose tag, algorithm and digest match. If nothing matches, the domain is already dark for validating resolvers and the fix is at the registrar. Lowering TTLs in your own zone does not help; the stale record is the parent’s.

The usual root cause is ordering: someone rolls the KSK, removes the old key immediately, and the DS still fingerprints it. Publish the new DNSKEY, add the second DS, wait out the parent’s TTL, then remove the old key.

# the DS lives in the parent — ask the parent's servers
dig @a.gtld-servers.net example.com DS +noall +authority +answer

# the keys it is supposed to match
dig example.com DNSKEY +dnssec +multiline

# does the whole chain validate, and if not, where does it break?
delv +rtrace example.com A
dig +trace +dnssec example.com A | grep -E 'DS|DNSKEY|RRSIG'

The defining RFC

DS is type 43, defined in RFC 4034 §5, with validation rules in RFC 4035 §5. Digest types are the IANA DS RR Type Digest Algorithms registry; SHA-256 came from RFC 4509. Automated maintenance from the parent is RFC 8078. Check a chain with the DNS lookup tool.

Reference and tooling

Every record type and its assigned numeric value is listed in theIANA DNS Parameters registry. To query a live zone from the browser, use theDNS lookup tool. If the record you are chasing is TLS-related, the TLS inspector andCertificate Transparency lookup are usually the next two stops.

Other record types