Diagnose DNS Propagation Before a Domain Cutover

DNS propagation is a bad name for what is happening. Nothing is slowly travelling across the internet. Recursive resolvers already have an old answer, and each one keeps it until that answer's TTL expires. That is why a new domain target can work on your laptop while a customer in another network still reaches the old server.

This pack turns a domain, its old and new answers, authoritative nameservers, TTL, and a set of resolver locations into a cutover report you can check before removing the old origin.

The three answers you need to separate

The authoritative answer. This is what the DNS provider says now. Query it directly first.
A recursive resolver's cached answer. Google, Cloudflare, an ISP, and an office network can each be holding a different answer with a different remaining TTL.
The browser's result. Browser, operating-system, proxy, and HTTP caches can make a correct DNS change look wrong. Do not start there.

Use dig to compare them:

dig NS example.com +short
dig @ns1.your-dns-host.example app.example.com A +noall +answer
dig @1.1.1.1 app.example.com A +noall +answer
dig @8.8.8.8 app.example.com A +noall +answer

The number beside the cached record is the remaining TTL. If the authoritative answer is new but a public resolver still returns the old target, the resolver is not broken. Its old answer has not expired yet.

A cutover that has a rollback

Lower the TTL at least one old-TTL window before the move. If the current TTL is 86,400 seconds, changing it five minutes before the cutover does not shorten copies already cached for a day.

Then:

Bring up the new origin and test it using the intended hostname and HTTPS.
Change one DNS variable at a time.
Record the authoritative answer and time of change.
Check more than one public resolver and network.
Keep the old origin serving valid traffic until the previous maximum TTL has passed.
Raise the TTL again only after the new path is stable.

Do not delete the old server because one laptop resolves correctly. That laptop may simply have had no cached answer.

What Claude can help with

Claude can compare command output, label authoritative versus cached answers, and draft a cutover checklist. It cannot observe resolvers you did not query. The runnable workflow keeps the raw answers, TTLs, and test locations in the evidence fields so a fluent summary cannot replace the measurements.

Tests worth running

authoritative record is new while one resolver remains old;
resolver returns the new IP but HTTPS has the wrong certificate;
www moved but the apex did not;
CNAME chain includes a stale intermediate answer;
old origin is removed before the last old TTL expires;
DNS is correct but an HTTP or service-worker cache still serves old content.

The final check is an actual request to the intended hostname. A new IP with a broken certificate or wrong virtual host is not a successful migration.

Run the starter locally

The starter uses Node 22 with no third-party npm packages. Dry-run is the default and performs no DNS changes.

npm test
npm run validate
npm run sample

Use Docker Compose to start the workflow service and n8n together. The n8n webhook passes the evidence into the tested service and returns a reviewable draft. It never edits DNS records.