Worse case scenario when switching a DNS entry with a TTL of 1 day

Question

Say I have a DNS entry with a Time to Live set to 1 day or 86400 seconds, and I update it's destination IP, I wonder how long it would take in a worse case scenario for an end user until his he gets the new IP.

My assumption is that it could actually take 72 hours before the end user receives the new IP address. Is this right? Does the caching in multiple nodes allow this to happen?

---

This is based on the assumption:

• The nameserver updates the entry immediately.
• The ISP, user router and user computer are all caching the DNS entry.
• All the nodes are respecting the set TTL. They look at the TTL as a timeout, not an expiration date.

Time scenario:

• At t=0, the nameserver updates the entry.
• At t=23:59hours, the user router asks the ISP for the latest IP.
• At t=24, the ISP gets the new entry.
• At t=47:59hours, the user computer asks the user router for the latest IP.
• At t=48, the user router gets the new entry.
• At t=71:59, the user computer asks the user router again, which is finally up to date.

Answer 1

I don't think your scenario makes sense. At t=23h59m after the change in the authoritative server, the so-called ISP nameserver either already has the new entry, or else it has the old entry. But if it has the old entry it must have gotten it from the authoritative server at least 23h59m ago, so the remaining TTL has to me 60 seconds or less. Therefore when the user's computer asks for it at 47h59m, it won't be there anymore: it will have been expired since almost 24 hours, and possibly refreshed since then.

In general, if the TTL on a record is 86400 seconds at the moment it is changed then the maximum amount of time the old value of the record could remain in the DNS system is 86400 seconds. There are only two exceptions I can think of:

• Implementation bugs in DNS servers... hopefully there aren't any :-)
• Unbound's cache-min-ttl configuration, which can be used to force the nameserver to cache a record for longer than it's supposed to. But since Unbound's manpage actually says "higher values [...] can lead to trouble", I don't think that people should be using that without very good reason.

So what's left? Caching of the information outside of DNS.

After an application or some type of operating system cache gets ahold of the old record from the DNS, there's no telling how long it can cache it.