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.

1. Check the parent's NS delegation for the child and verify every child authoritative nameserver is already serving the intended signed zone.
2. Determine who controls the actual parent. Use the registrar for a registered-domain DS, or the parent DNS operator for an ordinary delegated subdomain.
3. 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.
4. 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.
5. Query the parent directly for the child DS and then validate a normal record inside the child through a trusted validating resolver.

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 +answer

Read 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 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.

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.

• 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

• RFC 4034
• RFC 4035

• ISC BIND: dig and delv reference