You bought yourdomain.com at Namecheap. You log in, find the DNS panel, change the A record, save. Five hours later, nothing. You query dig yourdomain.com and it returns a completely different IP than what you set. You’re not crazy: you edited the right field in the wrong building. Your A record at Namecheap is being ignored by the rest of the internet because Namecheap is not the authoritative DNS for your domain. Cloudflare (or Route 53, or Vercel DNS) is. Welcome to the most common conceptual trap in domain management.
Fastest fix: run dig NS yourdomain.com +short, read the hostname it returns, and edit your A/CNAME/MX records in that provider’s dashboard, not your registrar’s. The rest of this article tells you how to match the hostname to a provider, and what to do when the two layers got separated without you realizing it.
This article explains the difference between name servers (NS) and DNS records (A, CNAME, MX, TXT), how to find out where you should actually be editing, and how to fix each way the two layers come apart.
The two-layer model (5 second version)
Registrar (where you bought the domain)
↓ stores: which NS servers are authoritative
NS servers (the authoritative DNS provider)
↓ stores: A, CNAME, MX, TXT records
The actual records the world queries- NS records live at the registry (controlled via your registrar) and answer the question: who is authoritative for this domain?
- A / CNAME / MX / TXT records live at the authoritative DNS provider (whoever NS points to) and answer the question: what is the IP / target for this hostname?
If you change an A record at your registrar’s DNS panel but NS points to a different provider, the change goes into a database nobody queries. The change is invisible.
How to identify which case you’re in
Step 1: find out who is authoritative
dig NS yourdomain.com +short
# Examples of output:
# stan.ns.cloudflare.com. ← Cloudflare DNS is authoritative
# amy.ns.cloudflare.com.
# OR (Cloudflare Enterprise "Foundation DNS"):
# aragorn.foundationdns.com. ← still Cloudflare, edit in Cloudflare
# aragorn.foundationdns.net.
# OR
# ns-1234.awsdns-12.org. ← Route 53
# ns-567.awsdns-34.com.
# OR
# ns1.vercel-dns.com. ← Vercel DNS
# ns2.vercel-dns.com.
# OR
# dns1.registrar-servers.com. ← Namecheap's default BasicDNS
# dns2.registrar-servers.com.
# OR
# ns1.bluehost.com. ← hosting provider doubling as DNSThe hostname pattern tells you the provider. Edit DNS records there, not anywhere else. If dig isn’t installed, the same answer comes from nslookup -type=ns yourdomain.com, or paste your domain into any public “NS lookup” tool (whatsmydns.net, dnschecker.org). No installs needed: web tools query the same authoritative chain.
Case 1: NS points to a provider you forgot about
You bought at Namecheap, then a year ago you (or a teammate) onboarded the domain to Cloudflare for the proxy / WAF features. Cloudflare’s onboarding flow asked you to change NS at Namecheap to Cloudflare’s NS. You forgot. Now you log into Namecheap, see a familiar DNS panel, and edit records that nobody queries.
How to spot it: NS in dig output doesn’t match the brand of your registrar.
Fix: log into the provider that owns NS, edit records there. If you want to consolidate back to the registrar, change NS at the registrar to the registrar’s defaults — but then re-create all your records there too, or you’ll have downtime.
Case 2: NS points to a hosting provider (Bluehost, GoDaddy, SiteGround)
When you signed up for hosting, the wizard offered to “manage DNS for you” and you said yes. Now dig NS shows the hosting provider, not your registrar. Their DNS panel is the truth.
How to spot it: NS matches your hosting brand. Registrar DNS panel says “your nameservers point to a third party” or “DNS is managed elsewhere.”
Fix: edit records inside the hosting provider’s control panel. The registrar’s DNS section is read-only / decorative until you change NS back.
Case 3: NS is split across providers
You see four NS records and two are at Cloudflare, two at Route 53. This is technically valid but operationally a nightmare — public resolvers will randomly pick one and that provider’s records win. If only one provider has your latest A record, half your users get old answers.
How to spot it:
dig NS yourdomain.com +short
# Returns mixed providersFix: pick one. Migrate all records to the chosen provider. Update NS at the registrar to list only that provider’s NS hostnames. Wait for previous NS TTL to expire (often 24–48 hours).
Case 4: NS changes you made aren’t propagating
You changed NS at the registrar. whois yourdomain.com still shows the old NS, or dig still hands out old records. This is rarely the registry being slow. As of June 2026 Verisign regenerates the .com and .net zones roughly every couple of minutes, so the new delegation appears at the TLD almost immediately. The real delay is caching: every resolver on the planet may have cached the old NS delegation, and the TLD’s NS records carry a TTL of up to 48 hours that you cannot lower (the registry owns it).
How to spot it:
# What the .com TLD servers hand out (the source of truth, ignores resolver cache):
dig NS yourdomain.com @a.gtld-servers.net +short
# If this already shows the NEW nameservers, the registry is done; you're just waiting on cache.
whois yourdomain.com | grep -i "name server"
# whois can lag the actual zone by hours; trust the dig-against-TLD answer over whois.Fix: wait, and verify against the TLD servers (above) rather than your local resolver. Most resolvers see the new delegation within 2–6 hours; full global propagation can take up to 24–48 hours in the worst case because of cached NS records. Plan every NS change with a 48-hour buffer.
Case 5: Records exist at both NS providers, conflicting
You changed NS from Namecheap to Cloudflare months ago. You still occasionally edit at Namecheap out of habit. Then one day NS gets reverted (by a teammate, or a registrar “Reset to defaults” button), and suddenly Namecheap’s stale records become authoritative again.
How to spot it:
dig yourdomain.com +short
# Returns an IP you don't recognize — it's the old Namecheap A recordFix: decide which provider is authoritative, sync records, set NS correctly, and turn off “auto-restore” at the registrar if it has one.
Shortest fix path
dig NS yourdomain.com +short: match the hostname pattern to a provider.- Log into that provider’s dashboard: not your registrar (unless they’re the same).
- Edit the A / CNAME / MX / TXT records there. Save. With a normal record TTL they become live within minutes, not hours (a record’s TTL, often 300 seconds, is unrelated to the multi-hour NS delegation TTL).
- If you want to switch authoritative DNS providers: (a) add all your records at the new provider first, (b) verify with
dig @<new-ns-hostname> yourdomain.com +shortthat the new provider already answers correctly, (c) only then change NS at the registrar. - Document where NS lives for every domain your team owns. Store this in an ops doc, not in someone’s head.
How to confirm it’s fixed
# Ask the authoritative provider directly (bypasses every cache):
dig @stan.ns.cloudflare.com yourdomain.com +short # swap in your real NS hostname
# Then ask a public resolver and confirm it now matches:
dig @1.1.1.1 yourdomain.com +shortWhen both return the IP you just set, the fix has propagated. If the authoritative-NS query is right but 1.1.1.1 is still wrong, you’re only waiting on the record’s TTL to expire.
Quick reference: NS hostname patterns
| Pattern | Provider |
|---|---|
*.ns.cloudflare.com | Cloudflare DNS (standard) |
*.foundationdns.{com,net,org} | Cloudflare Enterprise “Foundation DNS” — still edited in Cloudflare |
ns-*.awsdns-*.{com,net,org,co.uk} | AWS Route 53 |
ns*.vercel-dns.com | Vercel DNS |
ns-cloud-*.googledomains.com | Google Cloud DNS (the Google Domains registrar shut down in 2024 and moved to Squarespace; this hostname now means Cloud DNS) |
dns*.p*.dynect.net | Oracle Dyn |
dns*.registrar-servers.com | Namecheap BasicDNS |
ns*.domaincontrol.com | GoDaddy |
ns*.bluehost.com / ns*.hostgator.com | hosting bundle DNS |
ns*.digitalocean.com | DigitalOcean DNS |
ns*.dnsimple.com | DNSimple |
If you don’t recognize the pattern, run whois <ns-hostname> to find out who operates it.
Prevention
- Pick one authoritative DNS provider for your whole team: Cloudflare is the popular default because the DNS tier is free, fast, and has a clean API. Stick with it. (Cloudflare assigns your two NS hostnames automatically and they can’t be renamed; see Cloudflare’s nameserver docs.)
- Document NS in a team doc alongside the registrar and the renewal date. New engineers should never have to guess.
- Disable “reset to defaults” / “auto-DNS” features at the registrar if they offer them — they can silently revert NS during account maintenance.
- When migrating DNS providers, do it in this order: add all records at the new provider → verify with explicit-NS dig → change NS at registrar → wait 48 hours → only then remove records at the old provider.
- Lock NS at the registrar by enabling “domain lock” or “transfer lock” — most registrars have this and it prevents accidental NS edits.
FAQ
Q: My registrar shows DNS records. Why aren’t they live?
A: Because NS for your domain points elsewhere. The registrar’s DNS panel is only authoritative when NS points to the registrar’s own DNS servers. Run dig NS yourdomain.com +short to see who actually owns DNS.
Q: Will changing NS cause downtime?
A: It can. If you change NS to a new provider that doesn’t have all your records yet, queries flip to the new provider mid-propagation and start returning NXDOMAIN. Pre-stage all records at the new provider, verify with dig @<new-ns> yourdomain.com +short, then flip NS.
Q: How long does an NS change take to propagate globally?
A: The registry itself is fast (as of June 2026 Verisign rebuilds the .com/.net zone every few minutes), so the new delegation shows up at the TLD almost immediately. The wait you feel is cache: resolvers worldwide may hold the old NS delegation, and the TLD’s NS TTL can be up to 48 hours and isn’t yours to lower. Most resolvers update within 2–6 hours; budget 48 hours for the long tail. Check the TLD’s own answer with dig NS yourdomain.com @a.gtld-servers.net +short to separate “registry done” from “cache not expired yet.”
Q: Can I have NS records at two providers for redundancy? A: Yes, and RFC 2182 recommends running secondaries on diverse infrastructure, but only if both providers serve identical zones. Don’t maintain two zones by hand. Use a provider’s secondary-DNS feature so one zone is the primary and the other pulls it via zone transfer (AXFR/IXFR): Cloudflare’s “Secondary DNS” and Route 53’s secondary/zone-transfer support both do this. Two hand-edited independent zones drift and is exactly the conflict in Case 3.
Q: I changed NS and now my email is broken too. A: Yes — NS owns all records, not just A / CNAME. When you flipped NS, you also flipped MX, SPF, DKIM, DMARC. You need to recreate all of those at the new provider. See MX records got overwritten.