You migrated from one host to another. You updated the A record at your registrar. The browser still loads the old host, and dig +short yourdomain.com returns the old IP. You are certain you edited DNS, but the edit has no effect.
Fastest fix: run dig NS yourdomain.com. Whatever nameservers come back are the authoritative ones the world actually queries. If they are not your registrar’s nameservers (for example they say cloudflare.com, vercel-dns.com, or awsdns), then your registrar’s DNS panel is a dead end. Log in to that authoritative provider, delete the old A/CNAME record, add the new one, and your change takes effect within the record’s TTL.
The whole problem is almost always this one mismatch: you are editing DNS in one place while a different provider is answering queries.
The 60-second diagnosis
Run these three commands in order. They tell you which bucket you are in.
# 1. Who actually answers for this domain?
dig NS yourdomain.com +short
# 2. What IP does the world see right now?
dig A yourdomain.com @1.1.1.1 +short
# 3. Full delegation chain, root -> TLD -> authoritative
dig yourdomain.com +trace| What you see | Likely cause | Fix |
|---|---|---|
dig NS shows a provider you did not edit | Authoritative nameservers are elsewhere | Edit DNS at that provider (cause 1) |
dig A @1.1.1.1 returns 2+ different IPs | Old record left alongside new | Delete the stale record (cause 2) |
dig A @1.1.1.1 is new, your local dig A is old | Stale local cache | Flush local DNS (cause 5) |
dig A @1.1.1.1 is still old, NS is correct | High TTL / propagation | Check TTL, then wait (cause 3) |
| IP belongs to a CDN, not your origin | Proxy in front pointing at old origin | Fix the proxy origin (cause 6) |
A note on dig +trace: it queries from the root down using the same path a real resolver would, so it bypasses any cached answer your local resolver is holding. If +trace ends at a different nameserver than your registrar’s WHOIS shows, you are mid-delegation or the delegation never finished. Compare against the registrar’s nameserver field: WHOIS shows what the registrar delegated; dig NS shows what is answering today.
Common causes
Ordered by hit rate, highest first.
1. Authoritative nameservers are elsewhere
Your registrar’s nameservers (ns1.yourregistrar.com) are not the ones the world queries. The world queries Cloudflare, Vercel DNS, Route 53, or whatever you delegated to months ago. Registrar-panel edits do nothing because that panel is no longer authoritative.
How to spot it:
dig NS yourdomain.com +shortIf this returns Cloudflare nameservers (leah.ns.cloudflare.com, walt.ns.cloudflare.com, etc.), Cloudflare is authoritative and your registrar’s DNS panel is irrelevant. This is the single most common cause of “I edited DNS and nothing changed.”
2. Old A / CNAME records still present alongside the new one
You added the new A record but did not delete the old one. The zone now has two A records for the same name, and resolvers return them round-robin, so roughly half of all requests still land on the old host.
How to spot it:
dig A yourdomain.com @1.1.1.1If the ;; ANSWER SECTION: lists two or more A records pointing to different IPs, you have a stale record to delete.
3. TTL on the old record was high
You changed the record, but its TTL was 86400 (24 hours). Resolvers that cached the old value before your change keep serving it until the TTL expires. As of June 2026 most resolvers honor TTL within a few hours, but a 24-hour TTL can legitimately mean a 24-hour wait.
How to spot it: look at the TTL column in dig A yourdomain.com output. If it is large and the change was recent, the fix is to wait. Lower the TTL to 300 before your next change.
4. Multiple A records (legitimate multi-host, or accidental)
A-record fan-out is fine when intentional (round-robin load balancing across one host’s IPs). It breaks when the IPs belong to two unrelated hosts, because half your traffic goes to the old one.
How to spot it: dig A yourdomain.com +short shows multiple IPs. Confirm every IP belongs to the same host. Mixed origins are the accidental case from cause 2.
5. Local DNS cache is stale
Global DNS already serves the new IP, but your laptop’s OS resolver or your browser is still holding the old answer.
How to spot it:
dig A yourdomain.com @8.8.8.8 +short # public resolver: shows new IP
dig A yourdomain.com +short # your system resolver: shows old IPIf the public resolver is correct and your local one is not, flush your local cache (see Step 6 below).
6. A CDN proxy is in front, pointing at the old origin
Cloudflare’s orange-cloud proxy is on. The public IP is Cloudflare’s edge, not your host, and the edge is configured to talk to the old origin. Editing the proxied DNS record does not change where the edge sends traffic.
How to spot it: the IP from dig A belongs to Cloudflare (or another CDN), not your host. In the Cloudflare dashboard go to your domain, then DNS then Records, and check the origin the proxied record points at. Also check Rules then Origin Rules (or any old Page Rule) for a pinned origin.
Shortest path to fix
Step 1: Find the authoritative DNS provider
dig NS yourdomain.com +shortThis is the truth. Whatever returns here is who serves your DNS. Examples:
ns1.dreamhost.com-> DreamHost is authoritativeleah.ns.cloudflare.com-> Cloudflare is authoritativens-376.awsdns-47.com-> Route 53 is authoritative
Step 2: Log in to that authoritative provider
Edit DNS records there, not at the registrar. The registrar’s panel may still show a DNS section, but if the registrar’s nameservers are not the authoritative ones, that section is dead code and saving in it changes nothing.
Step 3: Delete the old A / CNAME record
Before adding the new record, delete the old one for the same name. Do not leave both, or you re-create cause 2.
Step 4: Add the new record per your host’s requirements
Follow your host’s docs exactly. For Vercel apex domains, the general-purpose value is A 76.76.21.21; as of June 2026 Vercel also recommends running vercel domains inspect yourdomain.com to get a per-project dynamic value such as xyz.vercel-dns-016.com, which it prefers over the legacy 76.76.21.21 and cname.vercel-dns.com (both still work). For subdomains, use the CNAME the host gives you. See A vs CNAME confusion.
Step 5: Verify globally
dig +short yourdomain.com @8.8.8.8
dig +short yourdomain.com @1.1.1.1Both should return the new IP. If either is still old, the change was not saved, was made at the wrong provider, or has not propagated yet. Cross-check from many locations at dnschecker.org.
Step 6: Flush local DNS
# macOS (Sonoma and later)
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# Linux (systemd-resolved: Ubuntu 18.04+, recent Debian/Fedora/Arch)
sudo resolvectl flush-caches
# Windows 10/11
ipconfig /flushdnsFlush the browser too: open chrome://net-internals/#dns (Edge: edge://net-internals/#dns) and click Clear host cache.
Step 7: How to confirm it’s fixed
You are done when all three are true:
dig +short yourdomain.com @1.1.1.1returns only the new IP, no old IP.curl -sI https://yourdomain.comreturns headers from the new host (checkserver:or a host-specific header likex-vercel-id).- dnschecker.org shows the new IP green across most regions.
If dig is correct but the browser still loads the old site, it is local cache only (cause 5), not a DNS problem.
Step 8: Document the authoritative provider
In a DNS.md (or your runbook) record, for example: Authoritative DNS for yourdomain.com: Cloudflare (leah/walt.ns.cloudflare.com). This is the note that prevents you from editing the wrong panel next time.
When this is not on you
Some resolvers and ISPs over-cache regardless of TTL, and nameserver (NS) changes specifically can take 24-48 hours to settle because they propagate through the TLD’s parent zone, slower than a plain A-record edit. As of June 2026 a single A-record change is usually visible within a few hours, but a full nameserver delegation can legitimately run to two days. Verify from multiple geographic locations via dnschecker.org before assuming something is broken.
Easy to misdiagnose as
People edit registrar DNS settings when the nameservers point elsewhere. The change saves successfully in the registrar UI and shows no error, yet has zero effect on what the world resolves. Always run dig NS first, before touching any record.
Prevention
- Document which DNS provider is authoritative for each domain (in
DNS.md). - Lower the TTL to 300 seconds at least 24 hours before any host change, so cached old values expire fast.
- After a host change, delete the old A/CNAME records. Do not leave them.
- For shared or team domains, restrict DNS edit access to one person so two people do not fight over records.
- Verify with
digagainst multiple public resolvers (@8.8.8.8,@1.1.1.1), not just your local machine.
FAQ
- How do I find the authoritative DNS provider? Run
dig NS yourdomain.com +short. The nameservers it returns are authoritative. For the full delegation chain from the root down, usedig yourdomain.com +trace. - My registrar shows different nameservers than
dig NS. Which is right? WHOIS / the registrar field shows what was delegated;dig NSshows what is answering right now. During a nameserver change they differ for up to 24-48 hours. Trustdig NSfor “where do I edit today.” - Can I use both registrar DNS and Cloudflare at the same time? No. Only one set of nameservers is authoritative. Set the registrar to delegate to Cloudflare’s nameservers, then manage every record at Cloudflare.
- I edited the right place and
dig @1.1.1.1is correct, but my browser still loads the old site. Why? That is a stale local cache, not DNS. Flush your OS resolver and clear the browser host cache (Step 6). It is not a global problem. - How long until the change is live everywhere? A single A/CNAME edit is usually visible within a few hours as of June 2026; a nameserver (NS) delegation change can take 24-48 hours because it propagates through the TLD parent zone.
- The IP
digreturns is not my host’s IP. It is probably a CDN edge (Cloudflare, Fastly). The proxy is pointing at your old origin. Fix the origin inside the CDN dashboard, not the public DNS record (cause 6).