A DS record is parent-side DNSSEC delegation data. It identifies a child
DNSKEY through a key tag, algorithm, digest type, and digest. Validators use
that relationship to continue authenticated trust from a signed parent into a
signed child.
Purpose and type code
IANA registers DS as type code 43
[1]. RFC 4034
defines the DS fields and how the digest is calculated from the child owner
name and DNSKEY RDATA
[2].
The four fields are:
- key tag: a 16-bit identifier calculated from the DNSKEY;
- algorithm: the DNSKEY algorithm number;
- digest type: the algorithm used to construct the digest; and
- digest: the resulting hexadecimal value.
The key tag is a lookup aid, not a unique or secret identifier. Compare every field and the underlying DNSKEY.
Presentation format
example.com. 86400 IN DS 12345 13 2 (
49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE26F6B8A780D1F50D91A3E0F6
)This example illustrates field placement only. Do not copy its values. Obtain or derive DS data for the actual child DNSKEY and use algorithms supported by the parent, registrar, authoritative provider, and validation policy.
Whitespace and parentheses can be presentation formatting. The digest is one field in DNS RDATA.
Owner-name and coexistence rules
The DS owner is the delegated child name, but the authoritative copy lives in the parent zone. A registrar or registry workflow commonly submits it. A DS shown in the child zone does not establish the parent chain.
Several DS records can coexist as one RRset during a supported algorithm or key transition. The RRset can offer multiple authentication paths; the transition plan must preserve at least one validator-usable chain.
DS is delegation data. Do not confuse it with DNSKEY at the child apex, and do not copy a provider’s DS from one domain to another.
Caching and changes
Parent DS records are cached independently of child DNSKEY and signature records. Removing or replacing DS at the registrar does not instantly remove copies already held by validating resolvers.
RFC 6781 describes parent-child coordination and rollover timing [4]. Keep old and new key material available for the transition required by the chosen procedure. An intentional insecure interval requires removing DS and waiting for cached parent data before serving unrelated child keys.
Security and operational limits
An incorrect DS can make the child bogus to validating resolvers even while authoritative servers remain reachable. RFC 4035 defines how validators use DS and DNSKEY to authenticate the delegation [3].
DS authenticates DNS data through the chain of trust. It does not encrypt DNS, secure the registrar account, test application health, or prove that the domain holder intended the change.
Treat DS publication and removal as availability-impacting changes. Require independent value comparison and an emergency parent-removal path.
Verify
Use the DNS Lookup pathway for named resolver observations and the Domain Registration Lookup pathway only for registrar context. Then:
- query the parent authorities directly for DS;
- query every child authority directly for DNSKEY;
- compare key tag, algorithm, digest type, and derived digest;
- inspect DNSKEY and RRSIG availability and timing;
- test at least one named validating resolver;
- record the parent DS TTL and observation time; and
- distinguish secure, insecure, and bogus results.
One control-panel “enabled” label does not prove the public parent and child data match.
Next step
Read the DNSKEY record reference for the child-side key material, then use Enable or migrate DNSSEC safely before changing the chain.