Introduction

Disabling DNSSEC at the DNS provider does not always finish the job. If the parent zone still publishes an old DS record, validating resolvers can continue treating the domain as signed even though the corresponding chain of trust is gone. That leads to confusing resolution failures that look random if you only test from non-validating paths. The fix is to align the DNS provider state with the registrar and parent zone so no stale DS record remains behind.

Symptoms

  • Some resolvers fail to resolve the domain while others still work
  • DNS looks correct at the zone provider, but validating clients return errors
  • The issue started after turning off DNSSEC or moving DNS providers
  • Public DNS checkers show stale DS records at the parent zone
  • Users report intermittent failures depending on which recursive resolver they use

Common Causes

  • DNSSEC was disabled at the zone provider, but the registrar still publishes the DS record
  • A DNS provider migration changed signing state without coordinating parent zone updates
  • Teams removed DNSKEY records first and assumed the parent DS record would disappear automatically
  • Registrar dashboards show DNSSEC as off while the parent zone still serves stale data temporarily
  • Troubleshooting focused on A, AAAA, or NS records and missed the broken trust chain above them

Step-by-Step Fix

  1. Confirm the domain is failing only on validating resolvers, which points toward a DNSSEC chain-of-trust issue instead of a basic record problem.
  2. Check whether the current authoritative zone still publishes DNSKEY records or whether signing has already been disabled there.
  3. Query the parent zone or registrar view to see whether a DS record is still published for the domain.
  4. If DNSSEC is meant to be off, remove the DS record at the registrar so the parent zone no longer advertises a broken trust chain.
  5. If DNSSEC is meant to stay on, make sure the DS record matches the active keys at the current DNS provider instead of removing security by mistake.
  6. Wait for parent-zone propagation and re-test with validating public resolvers after the stale DS record has aged out.
  7. Compare results from several recursive resolvers so you can distinguish propagation delay from an unresolved signing mismatch.
  8. Review any recent provider migration, nameserver change, or registrar update that may have split responsibility for DNSSEC.
  9. Keep future DNSSEC changes in a single runbook that covers both the zone provider and the parent DS record to avoid repeating the outage.