TTL: the number that decides how fast your changes happen

TTL (time to live) is how long, in seconds, resolvers may cache a DNS answer. It is the reason DNS scales — and the reason your "instant" record change takes hours to be seen: every resolver that cached the old value keeps serving it until its copy expires. There is no propagation push; there is only caches expiring.

The trade-off

• High TTL (hours/days): fewer queries, cheaper, more resilient to nameserver blips — but a wrong record or a migration takes that long to fix everywhere.
• Low TTL (30–300 s): changes land fast — failover depends on this — at the cost of more queries hitting your nameservers.

The practical migration recipe: lower the TTL to 300 s at least one FULL old-TTL before the change (if it was 86400, lower it a day early), make the change, then raise it back once verified.

Measuring it right

Ask a resolver and you see the REMAINING time of its cached copy, counting down. To read the configured value, ask your authoritative nameserver directly:

dig @ns1.example-dns.com example.com A +norecurse   # TTL configurado
dig @8.8.8.8 example.com A                          # TTL restante do cache