A DNS change updates an authoritative record; it does not push a new answer to every browser. Recursive resolvers and devices can continue using cached answers until their caching rules allow a refresh. A working site on your laptop therefore does not prove the cutover is complete for other visitors.

1. Separate the three changes people call propagation

  • A/AAAA record change: the destination address changes at the existing DNS provider.
  • Nameserver change: the parent zone delegates the domain to a different set of authoritative servers. Parent delegation caches and the new provider’s zone content both matter.
  • DNSSEC change: parent DS records and the new zone’s keys must agree. A mismatch can cause validation failures even when an address record looks correct.

There is no universal 15-minute or 48-hour completion promise. TTLs, negative caching, delegation, DNSSEC and provider publishing behavior can all affect what a client sees.

2. Build a cutover record before changing anything

Record the current authoritative provider, A and AAAA values, MX records, TXT records used for SPF and verification, and any CNAMEs. Keep both old and new website environments available during the transition. Moving website DNS must not accidentally remove email records.

If your current A record has a TTL of 86400 seconds, lowering it to 300 immediately before the move does not shorten copies already cached for 86400. Lower it at least one full old TTL ahead, allowing additional operational margin. A TTL is not a global completion stopwatch.

3. Compare authoritative and recursive answers

The commands below use dig, available through DNS utilities on many Linux and macOS systems. They are illustrative commands, not measurements of BahadurHosting infrastructure. Replace example.com with your domain. On Windows, use an installed DNS tool or an appropriate WSL environment.

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

Replace the example nameserver with an actual authoritative server from the NS lookup. The answer columns include the name, remaining TTL, class, type and value. A recursive answer with the old address and a decreasing TTL often indicates a cached record. If all authoritative servers still return the old address, fix the zone or provider publishing issue rather than clearing your browser repeatedly.

4. Interpret the symptom

  • A is new but some visitors reach the old site: check AAAA as well. IPv6-capable clients may take a different path.
  • NXDOMAIN: check the spelling and zone content. A previous nonexistent answer can be negatively cached even after a record is created.
  • SERVFAIL: investigate delegation, server availability and DNSSEC. Do not disable security blindly to hide the error.
  • Different authoritative servers disagree: check zone publication and the provider’s synchronization before announcing completion.
  • DNS is correct but HTTPS fails: check certificate names, virtual-host configuration, redirects and application settings.

5. Test the new web origin without moving DNS

For a server you control, curl --resolve sends the proper hostname and TLS server name while connecting to a selected address:

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

203.0.113.10 is a documentation-only address, not a server to use. Substitute your real assigned address. Do not add -k to conceal certificate errors. A successful HTTP response tests that route at that time; it does not verify mail delivery, every application page, or worldwide DNS consistency.

6. Decide whether to proceed or roll back

Check the homepage, sign-in, forms and a representative application transaction from more than one network. Keep a note of the timestamp, resolver, answer and error for each failed check. Roll back only with an understanding that the previous and new answers may coexist in caches. Once stable, restore an operationally suitable TTL and retire the old environment after your transition window.

When requesting help, send the domain, changed record type, old and new values, change time, and sanitized command output. Never send DNS-provider passwords. See pointing your domain for the account-level setup workflow.