Enter the record's current TTL and when you want to switch. Get a dated schedule: when to lower the TTL, when to change the record, how long old answers linger and when the old server can go.
Runs entirely in your browser — nothing you enter here is sent to a server.
Every DNS record carries a time to live: the number of seconds a resolver may keep the answer before asking again. When you change a record, nothing is pushed to anyone. The resolvers that already have the old answer go on handing it out until their copy expires, and only then fetch the new one. "DNS propagation" is nothing more than those caches running out, each on its own clock.
That gives a hard rule for any planned change: for up to one TTL after you switch, some users reach the old address and some the new. With a TTL of a day, that is a day during which you cannot be sure where traffic is going — and a day before a rollback takes full effect.
Reduce it to a few minutes ahead of the change. The new short TTL itself takes one old TTL to reach every cache, so do it well in advance.
After the change, old answers last only minutes. Both servers must still work during that window.
A long TTL means fewer lookups, faster page loads and resilience if your DNS provider has trouble. Restore it once the change is settled.
A few ISP resolvers enforce minimum TTLs, and browsers, operating systems and long-running applications keep their own caches. Expect a thin tail of late arrivals.
For records that rarely change — the apex and www of a stable site, MX records — an hour to a day is reasonable. For records you may need to move in a hurry, such as a failover target, 60 to 300 seconds keeps the switch quick at the cost of more queries. Very low values (under 30 seconds) are often ignored by resolvers and bring little benefit. And remember negative caching: a name that did not exist when someone asked is remembered as missing for the SOA minimum TTL, so create new records before you announce them.
As long as the record's TTL, at most, for well-behaved resolvers. A record with a 1-hour TTL is updated everywhere within about an hour. The "24 to 48 hours" people quote applies to nameserver changes at the registry.
300 seconds is the usual choice; 60 seconds if you want the fastest rollback. Set it at least one full old-TTL period before the cutover so that every cache has picked up the short value.
Your resolver, operating system or browser still has the old answer cached. Check the authoritative server directly with dig @ns1.yourprovider.com name — if that is correct, it is only a matter of waiting out the TTL.
Slightly. Visitors' resolvers have to look the name up more often, which adds a few tens of milliseconds to the first request. That is why you raise the TTL again after the change.
Upzilla's DNS monitor watches your records from several locations and alerts you when an answer is wrong or missing. 10 monitors free.