Why Your DNS Change Isn’t Showing Yet

Record types themselves are How DNS records work. Here the job is a cutover that looks stuck.

What actually has to change

Authoritative servers (your DNS host: Cloudflare, Route 53, registrar DNS) store the new record. That write is usually fast.

Recursive resolvers (ISP, Google, Cloudflare DNS, the resolver in the coffee shop) remember the previous answer until TTL. They do not poll you every second.

Your OS and browser remember too. flushdns, new private window, and another network are local, not “propagation.”

CDN and hosting dashboards add a fourth layer: the DNS is right but the CDN still maps the hostname to an old origin until you purge or the SSL hostname is wrong. Check certificates separately with SSL Certificate Checker - that tool sends the hostname on purpose.

TTL is a promise you already made

If the old A record had TTL 86400, a resolver that cached it this morning can serve it until that day is up. Changing TTL to 60 now does not shrink the cache that already exists. Lower TTL before the migration window.

Apex vs www is the classic miss. You updated www and people type the apex, or the opposite. CNAMEs cannot sit on some apex setups the way you hoped. Lookup both names with DNS Record Lookup.

Old nameservers: you changed records at the registrar but the domain’s NS still point at the previous DNS host. The host you edited is not authoritative. Check NS records first, then A/AAAA/CNAME.

How to see the public answer

1. Note the IP you expect (new load balancer or Pages project).
2. Domain to IP and DNS Record Lookup for example.com and www.example.com. These send the name to look it up. Only domains you operate or have permission to test.
3. Compare to what HTTP Header Viewer returns if the site loads - you may be hitting a different vhost on the same IP.
4. If public DNS is new and the browser is old, flush local cache, try a phone off Wi-Fi.

Do not use these tools as a port scanner or against hosts you do not own.

Local caches that fake “not propagated”

Windows: ipconfig /flushdns. macOS: dscacheutil / killall -HUP mDNSResponder depending on version. Browsers also cache. VPNs pin resolvers. Docker and corporate split-horizon DNS will show an internal view your lookup tool (public) will never see. If you have split DNS, “Google DNS shows X, my laptop shows Y” is expected, not a bug in DevOkk.

SSL and “the site is the new one but the padlock screams”

You pointed the name at a new host whose certificate does not include that name yet. DNS worked. TLS did not. How SSL certificates work and how to check expiry. Issue the cert on the new host or complete HTTP-01 with the new A record visible to the CA - which also depends on public DNS.

Email cutovers (MX) are slower to notice

Mail caches and provider retries. Updating A for the website does not move mail until MX and the mail host are right. Lookup MX separately. Do not test MX by sending a customer invoice during the first five minutes.

A worked example: Friday deploy

Old TTL 3600. You forgot to drop it Thursday. Friday 18:00 you switch A to the new VPS. Half the office sees the new site (resolvers that missed the old cache). Half see the old (ISP still has 40 minutes left). Public lookup from DevOkk shows a mix depending on which resolver the tool uses - treat a new public answer as “authoritative is updated” and wait out TTL for the rest. Do not keep editing records every two minutes; you add more cache versions.

Saturday, flush the one laptop that still fails. If public A is new and local flush fails, look at hosts file (127.0.0.1 example.com leftovers) and IPv6 AAAA you forgot to update. DNS Record Lookup for AAAA too.

Thirty-minute checklist

1. NS at the registrar match the host you edited
2. Apex and www both correct
3. A and AAAA
4. Public lookup vs local
5. Cert names
6. Stop toggling TTL during the incident

The networking roundup is Best free networking diagnostic tools. IP-only view: How to find a website’s IP address.

DNS “propagation” is caches expiring, not a weather system. Look up the public record, fix the name you actually use, and wait the TTL you already advertised. DNS Record Lookup is the public half. Your flushdns is the laptop half.

Anycast, CDNs, and “lookup shows two IPs”

A record can return different IPs in different regions on purpose. That is not failed propagation. If you compare a lookup from your laptop to a lookup tool and they differ by design (GeoDNS), you are debugging the wrong problem. Check whether both IPs serve the new app.

CDN hostnames (cname to something.cdn.cloudflare.net) mean the A you care about might be the CDN’s, not your origin. Origin IP changes do nothing until you change the origin in the CDN. People “update DNS” on the registrar and wonder why Cloudflare still points at Heroku.

IPv6 leftovers

You updated A. You forgot AAAA. Dual-stack clients prefer v6 and hit a dead or old host. Lookup AAAA. If you do not serve v6, remove stale AAAA. This looks exactly like “half the company sees the new site” (the half on v4-only).

Registrar vs DNS host vs website builder

Squarespace/Wix/Webflow want you to point NS or A at them. You edited A at GoDaddy but NS still point at Cloudflare with old records. Three panels, one truth: who is in the NS set. DNS Record Lookup for NS, then edit that host.

Negative caching

NXDOMAIN can be cached too. You created app.example.com after a lookup failed. Some resolvers remember the failure. Wait that TTL. Do not typo the name ten times before the record exists.

Split-horizon at work

Office DNS returns an internal IP. Home DNS returns the public one. The lookup tool on DevOkk returns public. All three can be “correct.” Say which view you are debugging.

Your flushdns is the laptop half. The public half is DNS Record Lookup. Together they beat refreshing the registrar panel until it blurs.

CAA, TXT, and “I only changed A”

You added a load balancer. You did not touch TXT for SPF. Mail is unrelated to the website cutover except you will get blamed. Lookup TXT/MX when the complaint is mail. Lookup A when the complaint is the website. DNS Record Lookup has to be aimed at the right type.

DS records and DNSSEC

If DNSSEC is on and you change DNS hosts without DS at the registrar, some resolvers SERVFAIL. That looks like “the site is down everywhere” while a phone on a resolver that ignores DNSSEC works. It is not TTL. Fix DS or disable DNSSEC until the new host is ready.

Wildcard leftovers

*.example.com still points at Heroku while www is new. app.example.com hits Heroku. Not propagation. Look up the exact hostname in the error.

Glue records and “NS changed but nothing moved”

When you change nameservers, the registrar must also publish glue if the NS hostnames live under the same domain. Missing glue looks like a random mix of old and new depending on resolver luck. It is not TTL on the A record. Fix glue at the registrar, then look up NS again with DNS Record Lookup.

The 48-hour myth

Support macros still say “wait 48 hours.” That number is a hangover from old TTLs and from people who changed records twice an hour. The honest wait is the TTL you already advertised on the record you are replacing, plus local cache. If that TTL was 300, you should not be quoting two days. If it was 86400, you should have lowered it yesterday.

Do not lower TTL during the incident as a ritual. Resolvers that already cached the old answer will not re-read your new 60-second TTL until the old cache dies.

ALIAS/ANAME vs CNAME at the apex

Some DNS hosts offer ALIAS/ANAME so the apex can follow a hostname. That is not a CNAME in the RFC sense. Lookup A/AAAA at the apex and CNAME on www. If you “copied the Cloudflare instructions into GoDaddy A records” you may have pasted a CNAME target into an A field. Public lookup will show a surprising IP or NXDOMAIN. DNS Record Lookup on both names.

Together they beat refreshing the registrar panel until it blurs. Domain to IP is the A/AAAA shortcut. DNS Record Lookup is the rest of the types.