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.
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 what to do when ownership of the two layers got separated without you realizing it.
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
# 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 DNS
# 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.
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. The registry (Verisign for .com, etc.) takes 4–24 hours to push NS changes to the global DNS roots.
How to spot it:
whois yourdomain.com | grep -i "name server"
# Still shows old valuesFix: wait. NS changes are slow by design — the registry batches them. Most TLDs propagate within an hour; .com and .net typically 4–8 hours; some country-code TLDs up to 48.
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. They become live within minutes.
- 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 +short, (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.
Quick reference: NS hostname patterns
| Pattern | Provider |
|---|---|
*.ns.cloudflare.com | Cloudflare DNS |
ns-*.awsdns-*.{com,net,org,co.uk} | AWS Route 53 |
ns*.vercel-dns.com | Vercel DNS |
ns*.googledomains.com / ns-cloud-*.googledomains.com | Google Cloud DNS / Google Domains |
ns*.dns.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 it’s free, fast, and has the best API. Stick with it.
- 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: NS changes are slower than regular DNS changes because they involve the TLD registry. Most TLDs push within 1–4 hours; .com and .net usually within 8; some ccTLDs up to 48. Always plan NS changes with a 48-hour buffer.
Q: Can I have NS records at two providers for redundancy? A: Technically yes, and the DNS spec encourages it, but only if both providers serve identical records. Use a DNS provider’s built-in secondary feature (Cloudflare’s “secondary DNS”, Route 53’s “private secondary”) rather than running two independent zones.
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.