Changing nameservers should be straightforward: update the NS records at your domain registrar, wait for propagation, and you're done. In practice, you'll run into cryptic errors, silent failures, and changes that seem to vanish into the void. This guide walks through the most common nameserver change errors, shows you how to recognize each one, explains what went wrong, and provides the exact steps to fix it.
Error 1: Nameserver Change Rejected by Registrar
Symptoms
You submit the nameserver update through your registrar's control panel, but the form returns an error like "Invalid nameserver" or "Nameserver does not exist." The old nameservers remain in place.
Root Cause
Most registries require nameservers to be registered in DNS with at least one A or AAAA record (glue records for in-bailiwick nameservers, or resolvable hostnames for out-of-bailiwick). If the nameserver hostname doesn't resolve, the registry rejects the change to prevent breaking your domain entirely.
The Fix
Step 1: Verify the nameserver hostnames resolve before submitting the change.
dig ns1.newhost.com +short
dig ns2.newhost.com +short
If these return no results, the nameservers aren't publicly resolvable yet.
Step 2: If you're using private nameservers under your own domain (e.g., ns1.yourdomain.com), you must register them with glue records at your registrar first. Look for a section called "Register Nameserver," "Host Records," or "Glue Records" in your registrar panel and add both the hostname and its IP address.
Step 3: For third-party nameservers that should already be public, contact the new hosting provider to confirm the correct nameserver hostnames and verify they're live in DNS.
Step 4: Once resolution works, retry the nameserver change at the registrar.
Error 2: Domain Locked or Transfer-Locked
Symptoms
The registrar control panel shows an error like "Domain is locked" or "Cannot modify nameservers while domain is locked." Some registrars silently ignore the update.
Root Cause
Domains have a registrar-lock (also called domain lock or transfer lock) that prevents unauthorized changes including nameserver updates, transfers, and contact modifications. This lock is enabled by default as a security measure.
The Fix
Step 1: Log into your domain registrar control panel.
Step 2: Locate the domain lock setting. Common labels include "Registrar Lock," "Domain Lock," "Transfer Lock," or "Lock Status."
Step 3: Disable the lock. Some registrars require email confirmation or two-factor authentication for this action.
Step 4: Immediately attempt the nameserver change.
Step 5: After the change is confirmed, re-enable the domain lock. Leaving it disabled exposes your domain to unauthorized transfers.
If you cannot find the lock toggle, check your registrar's documentation or contact support. A few budget registrars hide this setting or require a support ticket to unlock.
Error 3: Nameservers Updated But Not Propagating
Symptoms
The registrar confirms the nameserver change, and WHOIS shows the new nameservers, but your site still resolves to the old hosting. DNS lookups from some locations return old nameservers, while others return new ones. This state persists for hours or days.
Root Cause
DNS propagation is not instantaneous. The parent zone (TLD servers) must refresh its NS record cache, and every recursive resolver that cached the old nameservers must wait for the TTL to expire. If the old nameservers had a long TTL, this delay can stretch beyond the typical propagation window.
The Fix
Step 1: Confirm the registry has the update by querying the TLD authoritative servers directly.
dig @a.gtld-servers.net yourdomain.com NS +short
Replace a.gtld-servers.net with the appropriate TLD server for your extension. For .org, use a.gtld-servers.net; for country codes like .uk, check the ccTLD operator's nameservers.
If this returns the new nameservers, the registry update succeeded and you're waiting on cache expiration.
Step 2: Check how long ago the change was made. Most nameserver changes propagate within 24-48 hours under normal conditions.
Step 3: If the TLD servers still show old nameservers after 24 hours, log back into your registrar and verify the nameserver fields. Some registrars have a separate "Save" or "Apply" button that's easy to miss.
Step 4: Flush your local DNS cache to see the current state without waiting:
# Linux
sudo systemd-resolve --flush-caches
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
ipconfig /flushdns
Step 5: Use a multi-location DNS checker to confirm propagation progress. If most regions show new nameservers but one or two lag, that's normal caching behavior.
Step 6: If propagation stalls beyond 72 hours and the TLD servers show the correct nameservers, the issue is likely with a specific ISP or resolver. End users can flush their own DNS cache or switch to a public resolver like 8.8.8.8 or 1.1.1.1 temporarily.
Error 4: DNSSEC Validation Failure After Nameserver Change
Symptoms
After changing nameservers, the domain stops resolving entirely for users on validating resolvers. Browsers show "DNS_PROBE_FINISHED_NXDOMAIN" or "Server not found." Non-validating resolvers and direct queries to the new nameservers work fine.
Root Cause
If DNSSEC is enabled on your domain, the DS records at the registry must match the DNSKEY records published by your authoritative nameservers. When you change nameservers to a provider that doesn't host the correct DNSSEC keys, validation breaks and resolvers refuse to return answers.
The Fix
Step 1: Verify DNSSEC is the issue by testing with a validating resolver:
dig yourdomain.com @8.8.8.8 +dnssec
If you see SERVFAIL or no answer section, DNSSEC validation failed.
Step 2: Check if your domain has DNSSEC enabled:
dig yourdomain.com DS +short
If this returns DS records, DNSSEC is active at the registry.
Step 3: Decide whether your new hosting provider supports DNSSEC:
- If yes, obtain the new DS records from your hosting provider (often available in their DNS control panel) and update them at your registrar in the DNSSEC or DS record section.
- If no, you must disable DNSSEC at the registrar before the nameserver change will resolve correctly.
Step 4: To disable DNSSEC, log into your registrar, locate the DNSSEC settings, and remove all DS records. This change can take several hours to propagate.
Step 5: After removing DS records or adding correct new ones, flush caches and retest:
dig yourdomain.com @8.8.8.8
Best practice: Always handle DNSSEC updates before or immediately after a nameserver change. Coordinate with both the old and new hosting providers to minimize downtime.
Error 5: Mixed or Inconsistent Nameserver Configuration
Symptoms
Some DNS queries return correct records, others return stale or missing records. Users report intermittent site outages. The domain sometimes resolves, sometimes doesn't, and behavior varies by user location or time of day.
Root Cause
You've configured nameservers from two different providers (old and new), or left one old nameserver mixed with new ones. When recursive resolvers round-robin between nameservers that serve different zone files, they return inconsistent answers. This breaks DNS and is never a valid migration strategy.
The Fix
Step 1: Check your current nameserver list at the registrar and via WHOIS. Look for nameservers from multiple providers.
whois yourdomain.com | grep 'Name Server'
Step 2: Identify which set of nameservers should be authoritative. If you're mid-migration, complete the migration properly:
- Copy all DNS records from the old nameservers to the new ones before changing nameservers.
- Update the registrar to use ONLY the new nameservers, removing all old ones.
Step 3: Never mix nameservers from different providers. All nameservers for a domain must serve identical zone data. If you need to use multiple providers for redundancy, configure proper secondary DNS with zone transfers between them.
Step 4: After correcting the nameserver list, allow 24-48 hours for full propagation and cache expiration.
Error 6: Nameserver Change Reverted or Not Saved
Symptoms
You submit the nameserver change, see a success message, but when you check again hours or days later, the old nameservers are back.
Root Cause
Some registrar control panels require a two-step process: edit the fields, then click a separate "Save," "Update," or "Apply" button. If you only edited the fields, the change never committed. Alternatively, browser autofill or a session timeout caused the form to revert.
The Fix
Step 1: Log back into the registrar and navigate to the nameserver management section.
Step 2: Re-enter the new nameservers. Look carefully for a "Save," "Update," "Apply," or "Submit" button distinct from any "Edit" or field-level buttons.
Step 3: Wait for the confirmation screen or email. Do not navigate away until the registrar confirms the update.
Step 4: Immediately verify via WHOIS:
whois yourdomain.com | grep 'Name Server'
Step 5: If the registrar panel is buggy or unreliable, try a different browser without autofill enabled, or contact registrar support to make the change manually.
Error 7: Child Nameserver Hostname Not Registered
Symptoms
You're setting up private nameservers (e.g., ns1.yourdomain.com) and the registrar accepts them, but DNS lookups fail and the domain becomes unreachable.
Root Cause
Private nameservers under your own domain create a circular dependency: to resolve yourdomain.com, DNS must query ns1.yourdomain.com, but to resolve ns1.yourdomain.com, it must first know yourdomain.com's nameservers. Glue records at the registry break this loop by providing the IP address of the nameserver directly in the parent zone.
The Fix
Step 1: Before setting your domain to use ns1.yourdomain.com and ns2.yourdomain.com, register those hostnames as child nameservers at your registrar. This section may be labeled "Register Nameserver," "Host Records," "Glue Records," or "Child Nameservers."
Step 2: For each nameserver, provide:
- Hostname (e.g.,
ns1.yourdomain.com) - IPv4 address (required)
- IPv6 address (optional but recommended)
Step 3: Save the glue records and wait a few minutes for registry propagation.
Step 4: Verify glue records are live:
dig @a.gtld-servers.net yourdomain.com NS +additional
The additional section should show A records for ns1.yourdomain.com and ns2.yourdomain.com.
Step 5: Only after glue records are confirmed, update your domain to use the new private nameservers.
Error 8: Old Hosting Provider Blocks Zone Transfer
Symptoms
This isn't a nameserver change error per se, but a common migration pitfall. After changing nameservers, you discover critical DNS records missing from the new nameservers because you couldn't export the zone file from the old provider.
Root Cause
Not all hosting providers allow zone exports or AXFR zone transfers. Some lock you into their platform by making it difficult to retrieve a complete record list.
The Fix
Step 1: Before changing nameservers, manually document every DNS record at the old provider. Export if available, otherwise take screenshots or copy records into a spreadsheet.
Step 2: Recreate all records at the new nameservers before making the registrar change. Common records to check:
- A and AAAA records for the root domain and
www - MX records for email
- TXT records for SPF, DKIM, DMARC, and domain verification
- CNAME records for subdomains
- SRV records if used
Step 3: Use a DNS comparison tool or run queries against both old and new nameservers to confirm parity:
dig @oldns1.example.com yourdomain.com ANY
dig @newns1.example.com yourdomain.com ANY
Step 4: Only after confirming all records are replicated, change nameservers at the registrar.
Step 5: Monitor for missing records after the switch. Common casualties are SPF/DKIM records (breaks email), autodiscover records (breaks mail client configuration), and verification TXTs (may deactivate third-party integrations).
Checklist: Nameserver Change Pre-Flight
Before submitting any nameserver change, work through this checklist to avoid the errors above:
- [ ] Unlock the domain at the registrar if locked
- [ ] Export or document all existing DNS records from current nameservers
- [ ] Recreate all DNS records at the new nameservers
- [ ] Verify new nameservers resolve publicly (
dig ns1.newhost.com) - [ ] Register glue records if using private nameservers under your domain
- [ ] If DNSSEC is enabled, obtain new DS records or plan to disable DNSSEC
- [ ] Lower the TTL on critical DNS records at the old nameservers 24-48 hours before the change
- [ ] Submit the nameserver change at the registrar and confirm the update saved
- [ ] Verify via WHOIS and TLD authoritative servers that the change propagated
- [ ] Update or remove DNSSEC DS records as needed
- [ ] Re-enable domain lock after confirming the change succeeded
- [ ] Monitor propagation across multiple regions for 24-48 hours
How to Test Nameserver Changes Correctly
After making a nameserver change, proper testing helps you distinguish between propagation delays and actual errors.
Query the TLD authoritative servers directly to confirm the registry received the update:
dig @a.gtld-servers.net yourdomain.com NS
Query the new nameservers directly to verify they're serving the correct records:
dig @ns1.newhost.com yourdomain.com A
If this works, the new nameservers are correctly configured and the issue is propagation.
Use a propagation checker to test from multiple global locations, but understand that these tools query different resolvers, not authoritative servers. They show cache state, not the source of truth.
Flush your local cache before testing to avoid seeing stale answers from your machine or local network.
Wait the full TTL period from the time the registry updated. If the old NS records had a 24-hour TTL, assume 24-48 hours for worldwide propagation.
Conclusion
Nameserver changes fail for predictable reasons: domain locks, unregistered glue records, DNSSEC mismatches, and incomplete record migration. Each error has clear symptoms and a straightforward fix once you know what to look for. Always verify both the registry-level change and the DNS records served by the new nameservers, and give propagation the full TTL window before concluding something is broken. When in doubt, query authoritative sources directly rather than relying on cached results. By following the checklist and fixes in this guide, you'll handle nameserver changes with confidence and minimal downtime.