A DS record belongs in the parent of the signed zone it authenticates. For a registered domain, the registrar usually submits DS data to the registry. For a delegated child such as shop.example.com, the DS normally belongs in the authoritative example.com zone.
IN THIS ARTICLE
Check access and requirements
Confirm that the child is a separate delegated zone with its own DNSKEY and signatures. For the normal root-based trust chain, its parent must also be signed and securely delegated; adding DS inside an unsigned parent does not make the child securely validated. Obtain DS data from the child signing provider and record the complete key tag, algorithm, digest type and digest.
01 Publish a child zone's DS record in the correct parent zone
- Check the parent's NS delegation for the child and verify every child authoritative nameserver is already serving the intended signed zone.
- Determine who controls the actual parent. Use the registrar for a registered-domain DS, or the parent DNS operator for an ordinary delegated subdomain.
- Add the supplied DS at the child owner name in that parent. Check whether the form expects shop, shop.example.com or separate fields, avoiding a duplicated zone suffix.
- Publish only DS values that the child provider currently supports and instructs you to use. An obsolete key tag or wrong digest can invalidate the chain.
- Query the parent directly for the child DS and then validate a normal record inside the child through a trusted validating resolver.
02 Example: compare a child DNSKEY with its parent DS record
For a signed child zone, collect the DNSKEY published by the child and the DS published by its actual parent. Replace shop.example.com and ns1.parent.example with the child name and an authoritative server for example.com.
dig shop.example.com DNSKEY +dnssec +noall +answer
dig @ns1.parent.example shop.example.com DS +norecurse +dnssec +noall +answerRead the result: The DS belongs in the parent zone, while the signing keys belong to the child. Compare the parent's key tag, algorithm, digest type and digest with the exact DS set supplied by the child DNS operator. Merely seeing both record types does not prove that their cryptographic relationship is correct.
Use the provider's DS export and a validating diagnostic for the final check. Do not invent a digest or publish a sample key tag. Coordinate key changes so the parent never points only to a key that the child has already removed.
Confirm the expected result
Confirm that the parent DS and child DNSKEY match and that a record such as www.shop.example.com validates. Check the result after any relevant negative DS cache has expired.
Resolve setup problems
If the DS exists only inside the child zone, move the change to the correct parent control point. A DS visible in the wrong dashboard does not establish the parent-to-child chain of trust.
A common question
Should I put the shop.example.com DS in the registrar form for example.com?
Not as a substitute for the child's parent-zone DS. That registrar form usually authenticates example.com itself at the registry. Publishing a child's key there can break the registered domain. Confirm the exact domain shown in the form before saving.
Related articles
- Delegate a subdomain to another authoritative DNS provider
- Diagnose DNSSEC validation failures that appear as SERVFAIL
- Coordinate a DNSSEC key rollover with the registrar's DS update
- Query authoritative nameservers directly when diagnosing DNS
- Publish an SRV record using the service's priority, weight and port