Introduction

A nameserver change can look complete while the domain still fails because the parent zone keeps publishing a DS record from the old DNS provider. The new authoritative nameservers may answer correctly, but resolvers that validate DNSSEC will still reject the zone if the trust chain points to keys that no longer match.

Treat this as a DNSSEC delegation problem instead of a normal propagation delay. Start by checking whether the current DS record at the registrar still belongs to the old provider, because changing nameservers alone does not update the parent-side DNSSEC record.

Symptoms

  • The domain breaks only for DNSSEC-validating resolvers after nameserver change
  • DNS looks correct on the new provider, but users still see intermittent resolution failures
  • The domain works for some networks and fails for others with validation-related errors
  • The issue starts right after moving DNS hosting to a new provider
  • The parent zone still shows a DS record even though DNSSEC was reconfigured or disabled during migration
  • Resolution behaves as if the old DNS provider still controls trust for the zone

Common Causes

  • The registrar still publishes a DS record from the old DNS provider
  • DNSSEC was enabled on the old provider but not recreated correctly on the new one
  • The new provider signs the zone with different keys while the parent DS still references the old key set
  • Nameservers were changed before the registrar-side DNSSEC settings were updated
  • DNSSEC was disabled on the destination provider but the stale DS record was never removed
  • Mixed migration steps left the zone with broken chain-of-trust data during cutover

Step-by-Step Fix

  1. Confirm whether the domain currently uses DNSSEC and which provider is expected to sign the zone now, because you need the intended trust model before correcting the parent-side DS record.
  2. Check the DS record published at the registrar or parent zone for the domain, because that record determines which DNSKEY validators expect from the child zone.
  3. Compare the published DS details with the DNSKEYs or DNSSEC state on the new provider, because a mismatch there confirms the trust chain still points to the old environment.
  4. Verify whether DNSSEC should remain enabled on the destination provider or be removed temporarily, because the correct fix depends on whether the new zone is already signed and ready.
  5. Update or remove the stale DS record at the registrar based on the destination signing plan, because changing nameservers without correcting the parent trust record leaves validating resolvers broken.
  6. Retest using DNSSEC-aware lookups after the registrar change instead of relying only on basic resolution checks, because ordinary DNS queries can appear healthy while validation is still failing.
  7. Confirm that the old DNS provider is no longer signing or serving the zone in a way that confuses cutover validation, because mixed old and new trust data can prolong the failure.
  8. Check multiple external validating resolvers after the fix is published, because some networks may hold stale parent-side DNSSEC information longer than others.
  9. Document the exact order for future DNS provider moves including nameservers, signing state, and DS updates, because DNSSEC migrations often fail when those steps happen out of sequence.