Publishing and when a change is really live

Saving publishes

A change is written to your zone and pushed to all four nameservers in the background. It is normally complete in seconds.

The portal shows you which servers have it

You do not have to guess. The zone reports its sync state per nameserver, so a server that has not taken the change is visible rather than assumed. This is the point of showing it at all — "probably fine" is not a useful answer during an incident.

If a server was unreachable, the change is retried. You can also re-sync the zone by hand from the zone's tools if you want certainty rather than patience.

What you can verify yourself

Query a nameserver directly and you are asking the source, not a cache:

dig @ns01.kumodns.com example.com A
dig @ns04.kumodns.com example.com A

If all four agree, publishing worked. If a resolver you use still returns the old answer at that point, the record is live and you are looking at a cache.

What is not in our hands

Once the record is on our nameservers, how quickly the world sees it depends on the TTL that was in force before you made the change. A resolver holding a day-old answer with a day-long TTL will keep serving it until that expires, regardless of what we do.

Plan for it rather than fight it — see SOA and TTL, and why a change is not instant for the reason the honest answer is "up to 48 hours" rather than the TTL you set.

And what is not DNS at all

If the record is right on all four nameservers and the site is still wrong, the problem is downstream: the server the record points at, its certificate, its virtual host, or the registry status of the domain itself. DNS has done its job at that point, and the status page will say so if the problem is ours.

Last reviewed 2026-09-25.