A record propagation
Changing a domain's IP, when migrating hosting or swapping servers, is the most common A record change, and also the most visible one when it goes wrong: some visitors land on the new server while others still hit the old one until the TTL expires.
All three agreeing confirms the migration has propagated to those providers; while at least one disagrees, part of the real traffic still reaches the old IP.
A TTL of 86400 seconds equals up to 24 hours of cache at any resolver that already queried the record; lower the TTL before migrating to speed up the next swap.
Even after the A record is created, a resolver that already cached NXDOMAIN only queries again once that time (set in the zone's SOA, RFC 2308) expires.
It's the time a DNS record change takes to be reflected across every recursive resolver in the world. There is no mechanism to "push" the change, each resolver only fetches the new value after the old cached value's TTL expires.
Wait at least the old TTL value (visible in the query) before considering the migration complete. A TTL of 3600 (1h) means up to an hour of possible inconsistency.
No, it is expected behavior right after a change. Each resolver has its own cache and fetches the new value at a different time.
Not directly, third-party resolvers do not take a command from you. The only control you have is the TTL configured before the change.
The check queries 3 public resolvers (Cloudflare, Google Public DNS and DNS.SB) in parallel, straight from your browser, without touching our server. If all of them agree, propagation is complete.
For safety, the browser talks directly to fixed public resolvers, passing only the queried name, the J-Kit server is never used as an intermediary, avoiding IP exposure and SSRF. A DNS query is public by nature, like any name resolution.