Your frontend passes every local test. The preview deployment loads. Your edge provider reports a successful release. Then you point production at the new platform, and users start seeing DNS errors instead of your application. There is no failed request in your browser’s Network panel. Your edge logs are quiet. The request never reached your frontend.

DNSSEC can cause this kind of outage when a migration breaks the chain between the parent zone and your authoritative DNS service. A stale DS record or a mismatched DNSKEY can make otherwise correct routing records unusable to validating resolvers. The fix starts with tracing that chain, before another deployment distracts everyone from the actual failure.

Separate the Hosting Move From the DNS Move

Start by identifying what actually changed. Moving a frontend to an edge platform does not necessarily move authoritative DNS. You might update an A record, add an AAAA record, or replace a subdomain’s target with a CNAME while keeping the same DNS operator.

That distinction changes the investigation. If your DNS operator stayed the same, its signing system should normally sign the updated records. Missing signatures, expired signatures, or inconsistent authoritative servers become useful leads.

If you also changed nameservers, inspect the parent delegation and DS records early. Changing nameservers does not automatically replace a DS record stored in the parent zone. The parent may still advertise trust in a key that belonged to the previous DNS service.

A signed CNAME can also lead into another zone with its own validation problem. If your zone validates but the complete lookup fails, follow the alias target. An edge migration can expose a broken dependency without breaking your own zone’s keys.

Confirm That Validation Is Blocking Resolution

Use a hostname that fails for users. Replace the example name below with your production hostname. Keep the resolver constant while comparing results, because different resolvers may hold different cached data.

dig @1.1.1.1 www.example.com A +dnssec
dig @1.1.1.1 www.example.com A +dnssec +cdflag

The +dnssec option requests DNSSEC records by setting the DNSSEC OK bit. It does not turn dig into a validator. Validation happens at the recursive resolver used for these queries.

The +cdflag option sets Checking Disabled. It asks that resolver to return data without rejecting it because of failed DNSSEC validation. If the normal query returns SERVFAIL but the second returns your expected address, you have strong evidence of a validation problem.

That comparison is a diagnostic clue, not a complete diagnosis. SERVFAIL has other causes. Read any Extended DNS Error information in the response. A resolver may report a missing DNSKEY, an expired signature, or another validation error. Its wording and level of detail will vary.

Check AAAA records too. Browsers may request both address families, and the relevant responses need valid proofs even when an address does not exist.

dig @1.1.1.1 www.example.com AAAA +dnssec
dig @8.8.8.8 www.example.com A +dnssec

A successful validated response can include ad in its flags. That means the resolver considers the relevant answer data authentic. An RRSIG record by itself proves only that a signature was returned, not that the signature or its chain of trust passed validation.

Trace the Delegation and Inspect the Parent’s DS Records

DNSSEC links a child zone’s signing keys to information published by its parent. For a domain under .com, the .com zone holds the domain’s DS record. Your registrar typically provides the interface for managing that record.

A DS record contains a key tag, a DNSKEY algorithm number, a digest type, and a digest derived from a DNSKEY. It tells validators which child key they should be able to authenticate.

Trace the path to your zone, then inspect the DS record directly at a parent authoritative server:

dig +trace example.com DS
dig @a.gtld-servers.net example.com DS +dnssec +norecurse

The second command is specific to a .com example. For another suffix, use an authoritative server for that parent zone identified during the trace.

Do not treat +trace as a cryptographic validation report. It helps you inspect the delegation path and the records returned along it. You still need to check whether those records form a valid trust chain.

A common migration failure looks straightforward once these records are visible. The parent publishes a DS record from the old provider. The new provider serves the zone with different keys, or serves it unsigned. Validators cannot authenticate the child zone using the parent’s published trust information.

Check DNSKEY Records Across Every Authoritative Server

Next, identify the nameservers currently delegated by the parent. Query each one directly. Use server addresses when you need to avoid relying on potentially broken resolution of the nameserver hostname.

dig @NEW_AUTH_IP example.com DNSKEY +dnssec +norecurse
dig @NEW_AUTH_IP example.com SOA +dnssec +norecurse
dig @NEW_AUTH_IP www.example.com A +dnssec +norecurse

Replace NEW_AUTH_IP with an actual authoritative server address. Repeat these queries for every delegated server. A single healthy response does not establish that the whole service is consistent.

Direct authoritative responses can return usable addresses even while validating recursive resolvers reject them. Authoritative servers serve the zone’s data. They do not establish that the parent’s DS record authenticates that data.

Compare the published DS fields with the DNSKEY material at the active provider. The key tag helps locate a candidate key, but it is not sufficient to establish a match. The digest must match too.

If BIND utilities are installed, you can generate candidate DS records from the returned DNSKEY records:

dig @NEW_AUTH_IP example.com DNSKEY +noall +answer > dnskeys.txt
dnssec-dsfromkey -2 -f dnskeys.txt example.com

The -2 option generates SHA-256 digests. Compare that output with a parent DS record using digest type 2. If the parent uses another digest type, generate the corresponding digest instead. Avoid comparing digest strings produced with different digest types.

Multiple DNSKEY and DS records can be legitimate during a rollover. Their presence alone is not evidence of failure. The question is whether a supported authentication path exists and whether the DNSKEY record set and requested records carry valid signatures.

Use an Outside Check to Test Your Findings

At this point, an independent view helps catch assumptions tied to your workstation or chosen resolver. Run a DNSSEC Check as a supplementary diagnostic, then compare any reported findings with your direct parent and authoritative queries.

Keep the evidence tied to specific records. A useful diagnosis names the parent DS record, the active DNSKEY, the affected hostname, and the resolver response. A general failure label gives your DNS operator much less to work with.

External checks also have a vantage point and may encounter cached data. If a result conflicts with your own queries, investigate the difference before making another change. You may be observing two stages of the same migration.

Recognize the Failure Before Choosing the Repair

Several problems can produce the same browser error. The record-level evidence helps distinguish them:

• Stale DS record: The parent still references the previous provider’s key, and the new authoritative service cannot provide a matching DNSKEY.
• Missing DNSKEY or signatures: The parent expects a signed child zone, but the active service returns unsigned data or incomplete signing records.
• Expired or premature signatures: RRSIG validity timestamps fall outside the current time, even though the records and keys appear present.
• Inconsistent authoritative servers: Delegated servers return different key sets or signing states, causing failures that vary between queries.

Matching a DS record to a DNSKEY is only part of validation. The DNSKEY record set must authenticate correctly, and signatures covering the requested data must verify. Signed denial-of-existence responses also need to work. That matters when a hostname has no AAAA record or when clients request a name that does not exist.

If both normal and Checking Disabled queries time out, widen the investigation. Unreachable nameservers, broken delegation, or blocked DNS traffic may explain the outage. Larger DNSSEC responses can also expose transport problems. A comparison with dig +tcp can help identify a failing TCP path.

Coordinate the Repair Across the Registrar and DNS Operator

Before changing anything, identify who controls the parent DS record and who controls signing at the authoritative service. These may be separate teams, separate providers, or separate dashboards under one account.

If the new provider supports DNSSEC, confirm that its zone is fully signed and consistent across all delegated servers. Obtain its intended DS values through the provider’s supported process. Check those values against what the authoritative servers actually publish before submitting them at the registrar.

Updating the parent DS record can restore trust in the new keys. It does not instantly replace an old DS record already cached by a recursive resolver. Some users may continue seeing failures until that cached information expires.

Restoring the old authoritative service can also be an option if it still serves the correct zone and matches the parent’s existing DS record. Treat that as a complete rollback. Returning only part of the previous delegation can leave mixed answers and mixed signing states.

If the destination cannot support DNSSEC, removing the parent DS record may be necessary. This intentionally removes authenticated delegation for the child zone once the change takes effect. For a planned migration to unsigned DNS, remove the DS record first and allow cached DS records to expire before switching away from the signed service.

During an active outage, that safe preparation window has already been missed. Removing a stale DS record may help future lookups, but resolvers with the old DS cached can still fail. Record the relevant TTLs and communicate the expected recovery window without promising a universal deadline.

Plan Future Moves Around Cache Lifetimes

A DNS migration has several clocks. Delegation records, DS records, DNSKEY records, and application records can each have different cache lifetimes. Reducing your A record’s TTL does not shorten a parent DS record’s TTL.

For a signed migration between DNS operators, agree on the transition procedure before changing nameservers. Providers may support coordinated key publication or another documented migration process. A workable sequence depends on their capabilities and on which records can remain available during the overlap.

Keep the previous service available long enough to cover the planned transition. Confirm that both services return the intended application records where overlap is required. Avoid adding an unrelated key rollover to the same maintenance window unless the migration procedure requires it.

Write down the old and new nameservers, DS values, key details, TTLs, and change times. Those notes let an engineer joining the incident distinguish a cached old state from a new configuration error.

Verify Recovery Along the Path Users Take

After the repair, return to ordinary validating queries. A successful Checking Disabled response is not a recovery test because it bypasses the failure you are trying to fix.

dig @1.1.1.1 www.example.com A +dnssec
dig @8.8.8.8 www.example.com A +dnssec
dig @1.1.1.1 www.example.com AAAA +dnssec

Check the actual production hostname and any alias targets involved in its resolution. Use multiple validating resolvers and, where possible, the resolver path affected users rely on.

• Confirm that ordinary queries return the expected answer or valid denial of existence without SERVFAIL.
• For signed answer chains, check for authenticated responses from resolvers you trust and investigate missing authentication where you expect it.
• Repeat direct queries against every delegated authoritative server to confirm consistent keys and signatures.
• Load the production site and verify TLS, asset requests, and edge routing after DNS resolution succeeds.

If you intentionally removed the DS record, the child zone is now insecure in DNSSEC terminology. Successful resolution is expected, but authenticated answers for that unsigned zone are not the recovery criterion. Document that state and schedule signing separately if it remains a requirement.

Give the Next Edge Launch a Verified Trust Chain

Your application build, edge deployment, and DNS trust chain each need their own checks. A green deployment proves that the platform accepted your frontend. It cannot prove that validating resolvers can reach its hostname.

Add parent DS inspection, authoritative DNSKEY checks, and validating resolver queries to your migration runbook. Capture the working state before the move and compare it afterward. That small habit turns a confusing frontend outage into a traceable infrastructure problem, with evidence that points directly to the record that needs repair.