DNSSEC Chain of Trust Broken: DS Record Missing or Mismatched

What This Error Means

A broken DNSSEC chain of trust means the cryptographic link between your domain and its parent zone is severed. This happens in two ways:

• DNSSEC_NO_DS — Your zone has DNSKEY records (DNSSEC is enabled on your nameservers), but no DS record exists at the parent zone. The parent cannot vouch for your zone's keys, so the chain of trust never starts.
• DNSSEC_DS_MISMATCH — A DS record exists at the parent zone, but it does not match any DNSKEY record published at your zone. The parent is vouching for a key that no longer exists.

In both cases, DNSSEC-validating resolvers cannot verify your zone's signatures. They return SERVFAIL instead of your DNS records. Your domain effectively disappears for every user, application, and mail server that relies on a validating resolver.

Why This Matters

DNSSEC validation is no longer optional infrastructure used only by security-conscious organizations. Major public resolvers enforce it by default:

When these resolvers encounter a broken chain of trust, they do not fall back to unsigned resolution. They return SERVFAIL. The practical consequences:

• Website unreachable for users on validating resolvers
• Email bounces — MX lookups fail, so receiving servers cannot route mail to your domain
• API failures — Any service that resolves your domain via a validating resolver gets connection errors
• Monitoring blind spots — Health checks that use validating resolvers report the domain as down, triggering false incidents

The failure is silent and partial. Users on non-validating resolvers (some ISP resolvers) still reach your domain, making it harder to detect. You see intermittent complaints rather than a clean outage.

How to Diagnose

Step 1: Run the DNSSEC Validator

Use the mxio DNSSEC Validator to check your domain. The tool walks the chain of trust from the root zone through your TLD to your zone, checking each link. It reports exactly where the chain breaks — missing DS, mismatched DS, or other issues.

Step 2: Check the DNSKEY at Your Zone

Query your authoritative nameservers directly for the DNSKEY record:

dig DNSKEY example.com +dnssec

This returns the public keys published at your zone. The Key Signing Key (KSK) — identified by flag 257 — is the one that must match the DS record at the parent.

Step 3: Check the DS Record at the Parent

Query for the DS record at the parent zone:

dig DS example.com

Compare the DS record's key tag, algorithm, and digest with your KSK. If the DS record references a key tag that does not appear in your DNSKEY response, you have a mismatch. If no DS record is returned, you have DNSSEC_NO_DS.

Step 4: Check Delegation Health

Use the mxio DNS Delegation Health tool to verify your nameservers are responding correctly and serving consistent records. Delegation issues can compound DNSSEC problems.

How to Fix

Scenario 1: DS Record Missing (DNSSEC_NO_DS)

Your zone has DNSSEC enabled (DNSKEY records exist), but no DS record has been published at the parent. This commonly happens when:

• Your DNS provider enabled DNSSEC signing on the zone, but you never added the DS record at your registrar
• You migrated registrars and the DS record was not transferred

Fix:

1. Get the DS record from your DNS provider. Most providers that manage DNSSEC display the DS record in their dashboard (Cloudflare, Route 53, Google Cloud DNS all expose this).
2. Log into your domain registrar and add the DS record. The registrar interface typically asks for: key tag, algorithm, digest type, and digest value.
3. Wait for the parent zone TTL to expire (typically 1-24 hours for TLD zones).
4. Verify with the mxio DNSSEC Validator.

Scenario 2: DS Record Mismatched (DNSSEC_DS_MISMATCH)

The DS record at the parent references a key that your zone no longer publishes. Common causes:

• Key rollover without DS update. You or your DNS provider rotated the KSK but did not update the DS record at the registrar. The parent still points to the old key.
• DNS provider migration. You moved to a new DNS provider that generated new DNSSEC keys, but the old DS record is still at the registrar.
• Registrar auto-enabled DNSSEC with wrong keys. Some registrars attempt to enable DNSSEC automatically and publish DS records that do not match the actual zone keys.

Fix:

1. Query your zone for the current KSK: dig DNSKEY example.com — look for the record with flag 257.
2. Generate the correct DS record from the KSK. Your DNS provider usually provides this. If you need to generate it manually: dnssec-dsfromkey -2 Kexample.com.+013+12345.key (algorithm 2 = SHA-256).
3. Replace the old DS record at your registrar with the new one.
4. Wait for the old DS record's TTL to expire. During this window, some resolvers may still cache the old DS and return SERVFAIL. This is unavoidable.
5. Verify the complete chain with the mxio DNSSEC Validator.

Scenario 3: You Do Not Need DNSSEC

If you enabled DNSSEC accidentally or no longer want it, remove it cleanly. The order matters:

1. Remove the DS record at the parent first. Log into your registrar and delete the DS record.
2. Wait for full propagation. The parent zone's TTL must expire so all resolvers stop expecting DNSSEC for your zone. Wait at least 24-48 hours.
3. Then remove DNSKEY records from your zone. Only after the DS is fully propagated out can you safely remove the zone-side DNSSEC configuration.

Removing DNSKEY first while the DS still exists at the parent makes the problem worse — resolvers see the DS, expect signed responses, get unsigned responses, and return SERVFAIL.

Scenario 4: Managed DNSSEC (Cloudflare, Route 53)

If your DNS provider manages DNSSEC signing automatically (Cloudflare, AWS Route 53, Google Cloud DNS), the DNSKEY is generated and maintained by the provider. Your only responsibility is the DS record at the registrar.

• Cloudflare: Navigate to DNS > Settings > DNSSEC. Cloudflare displays the DS record to add at your registrar. If you recently enabled DNSSEC, copy this DS record and add it at your registrar.
• Route 53: After enabling DNSSEC signing on the hosted zone, Route 53 provides the DS record details. Add them at your registrar through the Route 53 console or the associate-hosted-zone-to-vpc workflow if using Route 53 as registrar.
• Google Cloud DNS: Enable DNSSEC on the managed zone, then publish the DS record shown in the Cloud Console at your registrar.

Prevention and Ongoing Monitoring

A broken chain of trust is one of the most damaging DNS misconfigurations because it affects all record types simultaneously. Prevention comes down to process discipline around key management:

1. Monitor DNSSEC status continuously. Use mxio Domain Health Monitoring to detect chain-of-trust breaks before users report them. Automated monitoring catches issues within minutes rather than days.
2. Use managed DNSSEC when possible. Providers like Cloudflare and Route 53 handle key rotation and zone signing automatically. You still own the DS record at the registrar, but the zone-side complexity is eliminated.
3. Document your DNSSEC configuration. Record which DNS provider manages signing, where the DS record is published, and who has registrar access to update it. Key rollovers require registrar access — if only one person has those credentials, that is a single point of failure.
4. Test after any DNS migration. Whenever you change DNS providers, verify DNSSEC end-to-end. Migration is the most common trigger for chain-of-trust breaks because the new provider generates new keys that do not match the old DS record.
5. Test after registrar changes. Registrar migrations can drop DS records silently. Verify DNSSEC status immediately after any registrar transfer completes.

Related Issues

• DNSSEC Signatures Expired — Chain of trust intact but signatures have expired, causing the same SERVFAIL behavior
• DNSSEC Query Failures — Infrastructure issues preventing DNSSEC validation from completing
• DNS Delegation Health — Verifying nameserver configuration and delegation consistency