After changing name servers, what is the max time a client can use old IP?

Question

I just migrated a domain to a new server. The original authoritative name-servers had a TTL of 14400 seconds (corresponding to NS records within the zone file). The A record (pointing the domain to the new machine IP) had a TTL of 14400 seconds. After changing the authoritative name-servers with the domain registrar, what could be the worst-case scenario (maximum) duration for a client to use the old IP instead of the new one?

Answer 1

TL;DR: Don't take DNS TTL numbers as sacred cows and binary switches: behaviors in practice is more nuanced than just "is the TTL expired or not?". And there are more than one TTL to take into account (you list two in your questions, but you miss the TTL in the parent zone, and other timers in the SOA can be relevant, depending on the nameservers setup).

In theory AND based on your numbers, if the registrar sends your change immediately (which is not a little "if", so you need to check for the parent nameservers to see when they publish the change in fact; also you are not even mentioning the TLD, not all registries are real-time ones, some forces a 5 days delay on any change for example, others do nameserver checks before allowing a neamserver change, etc.), 14400 seconds after your change (plus some delta because not all authoritative nameservers of the parent might be updated at the same time...) no one should still have the old NS records and hence the old A records (if you mean the A record is different on the new nameservers than on the old).

But a caveat: not only the TTL of the NS records of the zone counts here, also you have to take into account the TTL of those records in the parent zone, they are in fact even more important here. Some resolvers are "child-centric" others are "parent-centric" (and the debate is still ragging to determine which one is more right... some may say that the original DNS specifications are leaning towards a little more "child-centric" but it is certainly not 100% of observed behaviors on the field, hence you need to take into account what happens at parent).

However, the difference between theory and practice is not in theory there is none. Specially in the DNS world, there are so many misconfigurations and broken middleboxes that you can not count on anything like the above, specially since things are not time critical up to the second.

For changes like that, what is recommended instead:

• make sure the old nameservers continue to respond to queries (even if they start to give the new IP address for the A record); monitor their requests rate, so that you can be confident when they stop to receive queries for that record
• make sure the old IP address continue to work and deliver the service it has to deliver (even if it is with some trickery behind to "redirect" - at some level, not necessarily the TCP/IP layer - the traffic to the new IP address), and monitor access, you will then be confident to know when you can stop the service there.

Another VERY IMPORTANT point: it depends on the client. I hope you are speaking about a browser (otherwise your question is kind of off topic here), in which case things should be fine with the explanations above. But in some other cases, you can have for example (and I know of such cases) a long running process or even daemon that does a name resolution at start and then keeps the IP address until it stop running. Which means in this case, no matter what happens in the DNS records, that specific client will continue to hit the former IP address (which is why the above recommends you to monitor accesses on the old IP address anyway). So it is very important for cases like that to know how the records are used, by which applications.

At the end, it all depends on how critical the service is. If we imagine for example talking about a website being a blog with 2 visits/day, you may be able to cut corners and not caring about loosing a few accesses during the period when DNS changes are percolating everywhere. If instead it is a high traffic business website where each second equals potentially to hundreds or thousands of dollars being spent or lost, then of course some extra level of caution is needed.

PS: the perspective of the above comes from someone more close to 25 years in domain names and who have seen so many broken DNS changes because of lack of preparation, tests, monitoring, or too many false assumptions on how the DNS works (starting with the myth of "propagation" that everyone repeats and thankfully your question was void of that!)