An old DS record, the hash of your signing key held in the parent zone, breaks a website after a nameserver change. DNSSEC, the DNS security extension that proves answers are authentic, then fails validation and security-aware resolvers reject the domain.
Your DNS editor cannot fix it alone. The fix lives at your registrar, where the DS is published. Remove that stale record before traffic shifts.
Table of Contents
- Why does a correct nameserver change still fail?
- Where is the old DS stored?
- What order prevents downtime?
- How do you confirm the stale DS is gone?
Why does a correct nameserver change still fail?
The Internet Society explains in its guide to securing and signing domains that a DS record links root to TLD to domain. It publishes a hash of the child-zone signing key in the parent zone.
Cloudflare states in its DNSSEC documentation that moving to new nameservers with different keys while the old DS remains leaves answers unauthenticated. Validators then treat the domain as bogus. The IETF rules in RFC 4035 require authentication and error signals, so affected visitors see server failure though the zone looks correct.
Where is the old DS stored?
Cloudflare notes in its troubleshooting guidance for full-setup zones that the DS must change through the registrar or registry. The authoritative DNS host alone cannot remove it.
Many owners update delegation but miss the registrar DNSSEC tab. Cloudflare instructs owners to disable DNSSEC and remove the old DS at the registrar before changing nameservers. Until that parent record is gone, the old trust signal stays live.
What order prevents downtime?
Cloudflare describes the safe order as removal first, patience second, and re-signing last. The pause lets the parent TTL and caches expire.
Do not publish the new DS early. Do not skip the wait when launches or ad campaigns depend on steady reach.
- Remove the old DS at the current registrar
- Wait for parent TTL and cached records to expire
- Change nameservers to the new provider
- Publish the new DS supplied by that provider
How do you confirm the stale DS is gone?
The APNIC Blog describes in its report on Bangladesh ccTLD deployment how DNSViz and the Verisign debugger exposed a parent DS pointing to a missing key. Run the same parent-side check after your move and compare the DS against the active keys.
Cloudflare notes a stale DS can hold a zone in Pending Nameserver Update though delegation points correctly. Check DS status separately before assuming delegation has finished.
