DNS and TTL planning when you move a short domain

The number that decides how long the move takes

Every DNS record carries a time to live, expressed in seconds, that tells resolvers how long they may cache the answer before asking again. If your short domain has a TTL of 86400, a resolver that looked up the record a minute before you changed it will keep serving the old answer for almost a full day, and there is nothing you can do from your side to make it stop.

This is the single fact that determines the shape of a short domain migration. The change itself is instant. The propagation is not, and the word propagation is misleading: nothing is being pushed anywhere. Resolvers around the world are simply holding old answers until their individual timers expire.

Lower the TTL before the change, not during it

Reducing the TTL to 300 seconds at the moment you change the record does not help, because resolvers that already cached the old record also cached the old TTL. They will hold it for the original duration regardless of what you do now. The reduction has to happen far enough in advance that every cached copy of the old record has expired and been replaced by a copy carrying the new, shorter TTL.

The safe rule is to lower the TTL at least one full old-TTL period before the migration, and preferably two. If the current value is one day, lower it two days before you plan to move. Then the worst case at cutover is five minutes rather than twenty-four hours, and you can raise it again a day or two after the move is confirmed stable.

Keep the old target serving during the overlap

Because you cannot control when each resolver switches, both the old and the new endpoint must serve correct redirects simultaneously for the whole overlap window. Turning off the old host at the moment you change the record guarantees broken links for every resolver still holding the old answer, and those are exactly the users on networks with aggressive caching.

Plan for the old endpoint to stay live for at least a day after cutover even with a short TTL. Some corporate resolvers and some consumer devices ignore TTLs entirely and cache on their own schedule. The cost of leaving a redirect service running for another day is nothing. The cost of a printed code that fails for a subset of scanners is considerable.

CNAME versus A record, and why it matters here

If your short domain points at a provider using a CNAME, you are delegating the TTL decision partly to them: your CNAME has a TTL, and so does the record it points to. Both caches apply. If it points at an A record with a fixed address, you control the whole chain but you also inherit responsibility for the address changing.

Check both TTLs before planning. Query the record and read the value returned rather than trusting the number shown in your registrar interface, which sometimes displays an intended value rather than what is actually being served. If the provider's downstream record has a long TTL you cannot change, factor that into your overlap window.

Certificates are the other clock

A short domain serving HTTPS needs a valid certificate at the new endpoint before traffic arrives, not after. Automatic certificate issuance usually depends on the domain already resolving to the issuing host, which creates an ordering problem: the certificate cannot be issued until DNS points at the new place, but pointing DNS at a place without a certificate produces a browser warning.

Most platforms resolve this by allowing you to add the domain and complete a validation step in advance, using a separate verification record. Do that first, confirm the certificate is issued and installed, and only then change the record that carries live traffic. If the platform cannot pre-issue, schedule the change for a low-traffic hour and watch the certificate status directly rather than assuming it completed.

Verify from more than your own machine

Your laptop is the least representative resolver available, and your browser may be using a resolver you did not configure. Check the record from several public resolvers and from a mobile network. A propagation checking service that queries many resolvers at once is useful here, not because it tells you when the change is finished, but because it shows you the spread of answers still in circulation.

Also check the redirect itself, not just the DNS answer. Resolving correctly and redirecting correctly are different failures. Fetch a known short link end to end from each vantage point and confirm both the status code and the destination.

Write the rollback down before you start

The rollback for a DNS change is trivially to put the old value back, and it is subject to exactly the same caching delay in reverse. That is why the overlap matters: if both endpoints work, a rollback is uneventful, and if only one works, a rollback is another wait of the same length.

Record the exact previous value, its TTL, and the time you changed it, somewhere that is not the DNS console. During an incident, the console shows you the current state and not the state you are trying to restore, and reconstructing an old record from memory at an awkward hour is how short outages become long ones.