Why ipconfig /flushdns didn't fix it: stale DNS after moving a domain

I moved the apex of a domain from a hosting platform to my own VPS by changing one A record. The new server was ready, the certificate was issued, and the site still loaded from the old host on my machine. ipconfig /flushdns changed nothing.

The cause was a stale record in my ISP’s DNS resolver. Flushing the Windows cache cannot clear that, because the stale copy is not on your machine. This post shows how to tell the two cases apart.

The symptom

A request to the domain was answered by the old host:

$ curl -sS -I https://example.com
HTTP/1.1 200 OK
Server: Vercel
X-Vercel-Cache: HIT

and curl confirmed which address it had connected to:

$ curl -sS -o /dev/null -w "remote_ip=%{remote_ip}  http=%{http_code}\n" https://example.com
remote_ip=76.76.21.21  http=200

76.76.21.21 was the old A record. The new one should have been 203.0.113.10.

The mistake I made first

My first check passed, and it was the wrong check:

curl -sS -I --resolve example.com:443:203.0.113.10 https://example.com

--resolve tells curl to skip DNS and connect to the address you give it. That proves the new server answers correctly for that hostname. It says nothing about what DNS returns. I declared the move finished on the strength of this command, and it was not.

If you are verifying a DNS change, at least one check has to go through real DNS.

Three queries that locate the stale record

Ask three different places for the same record and compare.

1. The authoritative nameservers. This is the zone itself, with no caching in between.

Resolve-DnsName example.com -Type A -Server ns1.dns-parking.com

IPAddress       TTL
---------       ---
203.0.113.10 14400

2. A public resolver.

Resolve-DnsName example.com -Type A -Server 1.1.1.1

IPAddress       TTL
---------       ---
203.0.113.10 14400

3. Whatever resolver the machine uses by default (no -Server).

Resolve-DnsName example.com -Type A

IPAddress     TTL
---------     ---
76.76.21.21 11015

The zone was correct and a public resolver agreed. Only the default resolver still returned the old address.

Why flushing did nothing

ipconfig /flushdns empties the cache held by the Windows DNS client. After flushing, Windows asks its configured DNS server again. If that server still has the old record cached, you get the old answer straight back.

I ran the flush and repeated the default query:

local default resolver (pre-flush):  76.76.21.21
flushed
local default resolver (post-flush): 76.76.21.21

To see which server that is:

Get-DnsClientServerAddress -AddressFamily IPv4

On my machine the Wi-Fi adapter was using two addresses handed out by the ISP. Those resolvers had cached the old record before the change.

Check the hosts file as well, since a forgotten entry there produces the same symptom:

C:\Windows\System32\drivers\etc\hosts

Mine had no entry for the domain.

How long it lasts

The TTL column answers this. The record’s TTL in the zone was 14400 seconds, which is four hours. The stale answer showed 11015 seconds remaining, so the ISP resolver would keep serving the old address for about three more hours and then fetch the new one.

Nothing was broken. For most of the internet the move had already taken effect.

Ways to get the right answer sooner

• Wait. The cache expires on its own within one TTL.

• Change the machine’s DNS server to a public resolver that already has the new record:

  Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses 1.1.1.1,8.8.8.8
  ipconfig /flushdns

  This needs an elevated shell.

• For browser tests only, start Chromium with a resolver override and leave the system alone:

  --host-resolver-rules="MAP example.com 203.0.113.10, MAP www.example.com 203.0.113.10"

Before the next move

Lower the record’s TTL a day ahead of the change, for example to 300 seconds. Caches then expire in five minutes instead of four hours. Raise it again once the move is confirmed.

Summary

If the first two are right and the third is wrong after a flush, the problem is upstream of your machine and time will fix it.