DNS Check — "It Works on My Machine" for Domains

You updated the A record. ping on your laptop shows the new IP. Half the company still lands on the old box. DNS is eventually consistent with opinions — and Cloudflare’s orange cloud adds another layer of “which address am I really seeing?”

Start at the source of truth

Step	Question
1	Who are the authoritative nameservers?
2	What do those servers answer for A / AAAA / CNAME?
3	What do 1.1.1.1 and 8.8.8.8 answer?
4	What does the user’s ISP resolver answer?

If authoritative is correct and public DNS is stale, wait TTL. If authoritative is wrong, stop blaming “propagation” — fix the zone. Compare record types quickly with a DNS check tool while you change panels.

Propagation is not magic

“DNS propagation” usually means cache expiry. There is no global push. Lower TTL to 300 (or 60) a day before cutover; change; raise TTL after things stabilize. Changing with TTL still at 86400 schedules a day of split-brain.

Cloudflare / proxy gotchas

Mode	Public DNS shows	Traffic path
Grey (DNS only)	Origin IP	Straight to origin
Orange (proxied)	Cloudflare anycast	CF → origin

You can “update A to new origin” while orange cloud still fronts CF — fine unless the origin setting in the dashboard is wrong. SSL mode errors often look like DNS but are proxy config. Local /etc/hosts fixes only you.

CNAME vs A at apex

www.example.com  CNAME  pages.example.net   ✅
example.com      CNAME  pages.example.net   ❌ classic conflict
example.com      A / ALIAS                  ✅

Apex CNAME conflicts with NS/SOA. Use your host’s flattening feature when pointing apex at SaaS.

IPv6, corp caches, commands

You updated A but forgot AAAA — some networks prefer v6 and keep hitting the old address while your v4 tests look fine. Always verify both. Office resolvers with aggressive or split-horizon DNS can lag phone LTE by hours — ask IT which resolver they run before rewriting the zone again.

dig example.com NS +short
dig @ns1.example-dns.net example.com A +short
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com AAAA +short

Comparing @authoritative vs @1.1.1.1 ends most arguments.

Checklist

• Registrar NS points to the host you are editing
• A/AAAA/CNAME values intentional
• CDN/proxy origin updated
• TTL strategy planned before the change
• Verified from ≥2 public resolvers

Authoritative truth first, caches second, CDN config third. Then “works on my machine” becomes a TTL calendar, not a mystery.

CAA, MX, and “why did email break?”

Changing A/AAAA for a web app is only half the zone. After migrations, confirm MX and CAA still point where you intend — especially if you flipped nameservers at the registrar. A web cutover that silently dropped MX becomes an “DNS is hard” thread that is actually an incomplete checklist. Print a before/after of critical record types (A, AAAA, CNAME, MX, TXT, CAA) and tick them in the change ticket.

TTL psychology for stakeholders

Product managers hear “DNS propagation” and imagine a weather system. Show them the dig outputs: authoritative already correct, public resolver still old, ETA ≈ remaining TTL. That screenshot ends panic faster than explaining RFCs. Schedule cutovers when someone can watch resolvers for an hour — not Friday 5pm with TTL 86400.