There are lots of reasons to use really low TTLs, but most are a temporary need. Most of the times I had to set low TTLs for records were for hardware migration projects where services were getting new IP addresses. But in a well managed shop this should always be temporary. The TTL would be set low the day before the change, then set back to a normal value the day after the change. I feel the author is correct in that permanently setting low TTLs just covers up a lack of proper planning and change management.
The only thing off the top of my head that I can think absolutely requires a permanently low TTL is DNS based global load balancing for high uptime applications. But I’m sure there are other uses. I agree that the vast majority of things do not need a low TTL on their DNS record.
There are lots of reasons to use really low TTLs, but most are a temporary need. Most of the times I had to set low TTLs for records were for hardware migration projects where services were getting new IP addresses. But in a well managed shop this should always be temporary. The TTL would be set low the day before the change, then set back to a normal value the day after the change. I feel the author is correct in that permanently setting low TTLs just covers up a lack of proper planning and change management.
The only thing off the top of my head that I can think absolutely requires a permanently low TTL is DNS based global load balancing for high uptime applications. But I’m sure there are other uses. I agree that the vast majority of things do not need a low TTL on their DNS record.
So the options are to herd a million cats, or to set low TTLs? Hmmm …