JSVarSenior frontend developer
Contact
Back to blog
October 27, 2026Sergei Solod10 min read

DNSSEC SERVFAIL After Changing Nameservers: Diagnosis and Safe Migration

A nameserver change can trigger DNSSEC SERVFAIL even with correct A records. Diagnose stale DS keys with dig and learn safer migration and recovery steps.

DNSSECDNSNameserver MigrationDNS TroubleshootingDomain Security

A nameserver migration can look successful in every control panel and still leave a website unreachable. The domain is active, its new authoritative nameservers return the expected address, and the web server has not changed. Yet validating DNS resolvers report SERVFAIL. The missing piece is often a DNSSEC delegation that still trusts the previous DNS operator's signing key.

In the incident behind this investigation, ordinary lookups failed while the same queries succeeded when DNSSEC validation was bypassed. The parent zone still advertised an old DS record, but the new authoritative zone was initially unsigned. Publishing a matching key and signing the new zone restored validated answers in the resolvers tested. The important lesson is not that DNSSEC should be turned off; it is that moving nameservers and moving the DNSSEC chain of trust are separate operations.

Why correct A records can still produce SERVFAIL

DNS answers two different questions. An A record tells a resolver which IPv4 address belongs to a name. DNSSEC tells a validating resolver whether the answer can be trusted. Correct address data does not automatically imply a valid DNSSEC chain.

For a signed domain, the chain runs from a trusted parent zone through a DS (Delegation Signer) record to a DNSKEY in the child zone. The child zone publishes signatures (RRSIG records) over its DNS data. The DS record contains a digest identifying an authorized DNSKEY; it is not an A record, a copy of the private key, or a setting inside a typical zone-file editor.

After a change of authoritative nameservers, the parent can still publish a DS record associated with the previous signer. If the new zone has no corresponding DNSKEY and signatures, a validating resolver cannot complete the chain of trust. It normally treats the response as bogus and returns SERVFAIL rather than an unverified address.

This is distinct from an HTTP outage. The request may never reach the web server. It is also distinct from an expired TLS certificate: DNSSEC validates DNS data, whereas HTTPS protects a later connection between the browser and server.

The diagnostic that separates DNSSEC from a missing record

The most revealing test uses the same resolver and the same name twice. First, make an ordinary query and inspect the status, not just the answer:

dig example.com A +noall +comments +answer

Then repeat with the DNSSEC Checking Disabled (CD) bit set:

dig example.com A +cdflag +noall +comments +answer

In the observed failure, the ordinary query returned SERVFAIL; the CD query returned the expected A record. That contrast strongly implicated DNSSEC validation rather than a missing DNS record or an unresponsive application. The +cdflag option asks a supporting recursive resolver not to perform its usual DNSSEC validation for that request. It is a diagnostic, not a browser-side repair or a way to disable DNSSEC for visitors.

Do not infer too much from an empty +short response. Both an absent answer and a SERVFAIL can appear blank with that presentation format. Keep +comments while diagnosing so that status: SERVFAIL and status: NOERROR remain visible.

The CD comparison alone does not identify which part of DNSSEC failed; it tells you where to investigate next. A resolver might also have a transient upstream error, so repeat the test where necessary and inspect the parent delegation.

Inspect the parent DS record, not just the DNS editor

Look for DS records for the domain:

dig example.com DS +noall +comments +answer

For a fuller view of the delegation path, query the DNS hierarchy directly:

dig +trace example.com DS

The exact authoritative parent nameserver depends on the top-level domain. What matters is the DS RRset published by the parent, not merely a summary shown by a DNS hosting dashboard. A registrar transfer can leave nameservers unchanged, and a nameserver change can occur without changing registrars; either way, the parent DS must remain consistent with the active authoritative zone.

A DS record has four meaningful fields: key tag, algorithm, digest type, and digest. The key tag is a convenient label for troubleshooting, but it is not by itself proof that a DNSKEY matches. The digest and algorithm information must also correspond to a key actually served by the authoritative zone.

The case's decisive state was simple: the parent continued advertising the previous DNSSEC trust information, while the replacement authoritative zone reported that signing was inactive. The A records were present and could be retrieved when validation was bypassed. Changing application configuration or repeatedly editing the same A record would not repair that mismatch.

Two ways to restore a broken DNSSEC delegation

There are two legitimate recovery strategies. They solve the same trust-chain mismatch but have different operational consequences. Choose one deliberately; avoid randomly alternating between them.

Option 1: Remove the outdated DS and run temporarily unsigned

Ask the current registrar or its supported DNSSEC management interface to remove the stale DS record from the parent zone. Once the parent no longer asserts a secure delegation, validating resolvers can treat an unsigned child zone as insecure rather than bogus. DNS continues to work, but DNSSEC authentication for that domain is temporarily absent.

This is often the simpler emergency option, provided there is a reliable way to change the parent DS RRset. Keep the existing signing configuration stable until the old DS has expired from recursive caches. Removing DS from a control panel is not enough evidence on its own: verify the parent record externally and allow for its TTL. HTTPS remains independent of the DNSSEC setting. The temporary unsigned transition is also described in RFC 8078.

Option 2: Sign the new zone and publish a matching DS

The alternative is to enable DNSSEC at the new authoritative DNS operator, generate its DNSKEY material, sign the zone, and publish the corresponding DS record at the parent. A validating resolver can then build a trusted path to the new DNSKEY and validate the A record.

This was the recovery path actually observed. The DNS management interface reported that it had generated keys, signed the zone, and published a new DS. A parent-zone query subsequently showed the new DS alongside the previous one. Validating recursive lookups began returning the expected A record; a later test also returned NOERROR with the ad flag set, indicating authenticated data from that resolver.

The order matters: a published DS is only useful if the corresponding DNSKEY and valid signatures are already available from the authoritative DNS service. A control panel saying “published” is not a substitute for external verification. Cached DS, DNSKEY, RRSIG, and NS records can make different resolvers recover at different times.

Why two DS records did not necessarily keep the site broken

One surprising result was that the parent temporarily contained both an obsolete DS and a new, valid DS, yet DNSSEC validation succeeded. That is not contradictory. A DS RRset can contain multiple records, as it often does during key transitions. A validator does not require every DS record to identify a currently usable key; it needs a valid authentication path through an applicable DS to a DNSKEY and valid signatures. RFC 6840 clarifies that validators should accept a single valid path.

That does not make stale keys desirable forever. An obsolete DS increases operational ambiguity and should eventually be cleaned up once the new chain is verified. But removing it is maintenance, not an excuse to perform another risky DNSSEC reset while validated lookups are already succeeding.

There is a particularly dangerous control-panel trap here: an action named “emergency unpublish DS” may mean remove all DS records, including the new working one. Similarly, disabling zone signing while a DS remains published can immediately recreate the outage. Neither action is equivalent to deleting one specific obsolete DS record. If the interface cannot target an individual record, use a registrar-supported selective change rather than a blanket reset.

How to change authoritative nameservers safely

The safest sequence depends on whether the old and new DNS operators can coordinate keys. For a conventional migration using a temporary unsigned interval, the following order avoids the mismatch seen in this incident:

  1. Prepare the destination zone first. Copy the required A, AAAA, CNAME, MX, TXT, and other relevant records. Test the new authoritative nameservers directly before changing delegation.
  2. Inspect DNSSEC at the parent. Check whether DS records exist and identify who can update them. Do this even if you have never manually enabled DNSSEC; some DNS services automate signing.
  3. Remove the old DS while the old signed zone is still operating. Confirm the change at the authoritative parent, then wait long enough for previously cached DS data to expire. The wait is governed by observed TTLs, not a universal fixed number of minutes.
  4. Change the nameserver delegation. Keep the former authoritative service available while cached NS delegations may still point to it. Account for parent NS TTLs and verify which servers different resolvers are actually using.
  5. Decide whether to re-enable DNSSEC. If the new service should remain unsigned, do not publish a DS. If it should be signed, verify that the new DNSKEY and signatures are serving correctly before publishing the matching DS. Coordinate this with remaining old-NS caches to avoid a new validation mismatch.
  6. Validate independently. Check the parent DS, authoritative DNSKEY, ordinary recursive resolution, and the authenticated-data result from validating resolvers.

If continuous DNSSEC protection is required, an explicitly coordinated key rollover or multi-signer transition is preferable to the unsigned interval. That needs both DNS operators to support the necessary key and signing arrangement; simply copying the old DS digest to a new provider is not a rollover.

A short post-migration verification checklist

After any DNSSEC-related change, check both the DNS records and the proof that resolvers accept them:

dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answer

Use a validating recursive resolver for the authenticated-answer check. In its response, NOERROR plus an expected A record means resolution succeeded; an ad flag additionally reports that the resolver authenticated the answer according to its DNSSEC policy. A missing ad flag is not, by itself, proof of failure, because resolver capabilities, policies, and query flags differ. If DNSKEY queries fail through a validating resolver during an outage, query the active authoritative DNS service directly as part of the investigation.

Do not stop after one successful resolver response. Different caches may temporarily hold different delegations and keys. Also update any open operational support request: an earlier instruction to remove all DS records becomes hazardous once a new working DS has been published. A follow-up should explicitly preserve the active key and, if needed, request removal of only the obsolete record.

The failure was not caused by a wrong web-server address. It came from changing where DNS answers were served without first aligning the trust information that told resolvers which answers to believe. The practical preflight question before every nameserver cutover is therefore: What DS records does the parent publish, and will the destination's DNSKEY and signatures satisfy them?