Stop using low DNS TTLs (2019)

I interpret their data differently: only 47% of DNS lookups were for expired entries due to TTL. If some of those were for longish TTLs, some for actually changed records, then an even bigger majority of requests would be needed anyway, and longer TTLs would not have stopped them.

I use low TTLs because I don’t like waiting too long when I broke something or did a DNS configuration mistake.

One reason to use low TTL’s is for a DNS-based load balancer that is typically used for DR such as Azure Traffic Manager. That and paranoia about incorrectly updating a record causing your service to break for a period of time with nothing you can do about it.

The scenario I think about is, what happens if the DNS entry I just pushed had a typo in it? If my TTL is 60s, then I push a fixed entry and my site is back up quickly. If the TTL was 1hr, then anyone who cached that bad entry can't connect for about that long. 60s is better for disaster recovery, 1hr is better for performance.

I've seen this happen on internal networks where IT support tries to guide end users through flushing their local DNS cache so the users can get back to work before TTL expires on a broken entry.

The model I've been trying recently is to make DNS changes in three parts. First: change existing DNS entry TTL from 1hr to 1s. Wait 1hr as the caches clear. Update entry to the new address, keeping 1s TTL. Wait, test, and monitor for a while. Finally, increase the TTL back to 1hr. It takes more planning, but I avoid a 1hr partial outage if I mess up the address.

Most sites I've worked with change DNS <1 time per year, so outside infrequent, planned maintenance a long cache time is best for performance.

The way of measuring this affects (and skews) the outcome. DNS queries with low TTLs are requested more frequently and because of that, the author seeing more of them pass through his patched DNS relay, which was only left running for a few hours instead of for at least the max TTL they wanted to measure.