AI AI Tools Guidebook
Troubleshooting

Domain Points to the Wrong Hosting Provider

You changed hosts but DNS still resolves to the old provider. Where to look in the DNS chain to find where the wrong record lives.

Published: Author: AI Productivity Guide Team 🌐 查看中文版本

You migrated from one host to another. Updated A records at your registrar. Browser still loads the old host. dig +short yourdomain.com shows the old IP. You’re sure you edited DNS — but it has no effect. The most likely cause: your authoritative nameservers (the ones the world actually queries) aren’t your registrar’s default nameservers. They’re at Cloudflare, Vercel DNS, Route 53, or somewhere you set up months ago and forgot. Edits at the registrar don’t reach the authoritative provider.

The diagnostic is one command: dig NS yourdomain.com.

Common causes

Ordered by hit rate, highest first.

1. Authoritative nameservers are elsewhere

Your registrar’s nameservers (ns1.yourregistrar.com) aren’t the ones queried by the world. The world queries Cloudflare’s or whoever you set up months ago. Registrar panel edits do nothing.

How to spot it:

dig NS yourdomain.com

If returns cloudflare.com nameservers (leah.ns.cloudflare.com, etc.), that’s the authoritative provider. Your registrar’s DNS panel is irrelevant.

2. Old A / CNAME records still present alongside new

You added the new A record but forgot to delete the old one. DNS now has two A records; resolvers round-robin or pick one inconsistently.

How to spot it:

dig yourdomain.com

If ;; ANSWER SECTION: has 2+ A records pointing to different IPs, you have stale records.

3. TTL on old record was high

You changed the record but TTL was set to 86400 (24 hours). Resolvers may keep serving the old IP for up to 24 hours.

How to spot it: Check the TTL on the old record. If high and the change was recent, just wait.

4. Multiple A records (legitimate multi-host or accidental)

A record fan-out is fine if intentional (load balancing). But if you have IPs from two unrelated hosts, that’s accidental and breaks routing.

How to spot it: dig yourdomain.com shows multiple A records. Verify each IP — they should all be from the same host.

5. Local DNS cache stale

After global propagation, your laptop’s OS or browser cache still has the old IP.

How to spot it: dig yourdomain.com @8.8.8.8 shows new IP, but dig yourdomain.com (your system resolver) shows old. Flush local DNS.

6. CDN proxy in front, pointing to old origin

Cloudflare proxy is on. You updated origin DNS but Cloudflare’s edge is configured to talk to the old origin.

How to spot it: Cloudflare → DNS → check what the proxied record actually resolves to behind the proxy. May still be old.

Shortest path to fix

Step 1: Find the authoritative DNS provider

dig NS yourdomain.com

This is the truth. Whatever returns here is who serves your DNS. Examples:

  • ns1.dreamhost.com → DreamHost is authoritative
  • leah.ns.cloudflare.com → Cloudflare is authoritative
  • ns-376.awsdns-47.com → Route 53 is authoritative

Step 2: Log in to the authoritative provider

Edit DNS records there. The registrar panel may or may not have a DNS section — if the registrar’s nameservers aren’t the authoritative ones, that section is dead code.

Step 3: Delete old A / CNAME

Before adding the new record, delete the old one for the same name. Don’t leave both.

Step 4: Add the new record per host requirements

Follow host docs exactly (Vercel: A 76.76.21.21, etc.). See A vs CNAME confusion.

Step 5: Verify globally

dig +short yourdomain.com @8.8.8.8
dig +short yourdomain.com @1.1.1.1

Both should return the new IP. If still old, change wasn’t saved or hasn’t propagated.

Step 6: Flush local DNS

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# Linux
sudo resolvectl flush-caches
# Windows
ipconfig /flushdns

Browser too: chrome://net-internals/#dns → Clear host cache.

Step 7: Document authoritative DNS

In DNS.md or similar, note: “Authoritative DNS for yourdomain.com: Cloudflare (ns-XXX.cloudflare.com).” Future-you will thank you.

When this is not on you

Some registrars/DNS providers cache for hours regardless of TTL. Verify from multiple geographic locations via dnschecker.org.

Easy to misdiagnose as

People edit registrar DNS settings when the nameservers point elsewhere. The changes save successfully in the registrar UI but have no effect. Always check dig NS first.

Prevention

  • Document which DNS provider is authoritative for each domain (in DNS.md).
  • Lower TTL to 300 seconds at least 24 hours before any host change.
  • After a host change, delete the old A/CNAME records — don’t leave them.
  • For shared / team domains, ensure only one person can make DNS changes to avoid conflicts.
  • Verify with dig from multiple resolvers, not just your local machine.

FAQ

  • How do I find authoritative DNS? dig NS yourdomain.com returns the NS records.
  • Can I use both registrar DNS and Cloudflare? No — only one set of nameservers is authoritative. Set the registrar to delegate to Cloudflare, then manage records at Cloudflare.

Tags: #Domain #DNS #SSL #Troubleshooting #Name server

Related Articles