DNS TTL: how long an IP change really takes and how to prepare for it
Published on 2026-10-26 by frfrand
Change DNS records without breaking a website or losing traffic
You changed the A record to the new VPS IP, but some users are still reaching the previous one. It's not always that "the Internet takes time to find out": TTL defines how long resolvers can keep a response, and there are other caches along the way.
Let's turn it into a procedure you can use on a real VPS. The goal is to understand why it works, how to test it, and what problem appears if one part is misconfigured.
What DNS TTL means and when you need it
TTL is expressed in seconds and accompanies the DNS response. Resolvers can keep a value until it expires, but behavior varies with caches and policies. Reducing TTL right before changing the IP does not remove a previous TTL that was already cached.
Before changing anything in production, note the current state: IP, domain, port, affected service, and time of the last deploy. An isolated change is easy to verify; five simultaneous changes make it harder to reconstruct what happened.
Configuration or example commands
dig ejemplo.com A +noall +answer
dig @1.1.1.1 ejemplo.com A +noall +answer
dig @8.8.8.8 ejemplo.com A +noall +answer
# Ver los servidores autoritativos
dig ejemplo.com NS +shortDomains, IPs, paths, and names are illustrative. Do not copy an entire configuration over the current one without comparing first. In examples that include ports or firewall, make sure to keep administrative access.
How I would do it step by step
- Preparation. One day before a migration, lower the TTL of the relevant record and wait for the old TTL to expire.
- Step 2. Prepare the new VPS with HTTPS, API, and restored data before touching DNS.
- Step 3. Perform a final data sync or control writes during the cutover.
- Step 4. Change the A/AAAA record and verify authoritative servers and external resolvers.
- Verification. Keep the previous environment available for a reasonable window and then remove it carefully.
When finished, verify the actual operation from another connection. For example, for an API it is not enough to open the browser: run a read request, a write to a test database, and check the process logs.
Example of a real project
A store keeps orders in PostgreSQL. If both IPs temporarily point to different databases, some customers could place orders on the old server. The critical problem is not just DNS: it is avoiding data divergence.
The lesson is simple: an infrastructure configuration does not live isolated from the application. The frontend, the server, the database, and the workers connect, so measuring where the failure starts is more useful than restarting everything.
The mistake I would avoid
Do not promise a universal propagation of "five minutes". Low TTL helps, but behavior depends on resolvers and caches. Also, do not change only the A record if there is an old AAAA pointing to another server.
When working with client servers, keep a backup or rollback procedure before changes that affect data, network, or certificates. And if you don't know what permissions an operation needs, avoid running it as root just to stop errors from showing.
How does it relate to ArduMaker?
When migrating a website to ArduMaker, prepare VPS and services before DNS and test using a temporary domain or controlled resolution technique. Do not use production to discover missing variables.
In a typical case you can create a VPS for the application, deploy from Git, associate an HTTPS domain, and manage the backend and necessary databases. Tools help centralize operations, but you must understand which port and process fulfills each function.
Questions that arise when testing it
How do I know if the failure is DNS or the service? Check resolution first, then connection to the port, and finally the application response. That order avoids confusing different problems.
Can I expose a database to make it easier to maintain? Better to design private access or authenticated tunnels when possible. Exposing a port does not replace engine permissions or the firewall.
What should I document? The expected configuration, how to verify it, and how to return to the previous state. That document helps you more than a list of commands without context.
References
In summary: a good network or server configuration is one that you can explain, verify, and recover when something fails.