As a sysadmin with 20+ years experience, I've had long TTLs cause issues on several occasions. I've never regretted a short TTL.
Yep, that matches perfectly my (shorter) experience
Problems with low DNS TTLs
41–50 of 163 posts
Re: Problems with low DNS TTLs
#42This only applies to the first request until the cache expires.
If a client makes 50 requests before the cache expires, then those will all be based on the cached result.
This is still efficient enough that there's probably no more than a single DNS hit for every web page load, even with a short (say, 5 second) TTL, because most web assets will be loaded within that five second window. (If your web page takes longer than 5 seconds to load, you have far more significant issues than a few UDP DNS requests.)
Whether the list of invalid use cases are straw man arguments are left as an exercise to the reader, but this article seems to be arguing only one side of the perfectly valid trade-off between flexibility (low TTL's) versus latency (high TTL's).
In other words, if high TTL's are so great and there's no compelling reasons to not use them, why not make them one year? Ten years?
On the other hand, many (probably most) applications can probably absorb a five-minute outage without anyone screaming too loudly.
Clearly there is a balance between "long" and "short" (probably somewhere between one second and infinity). It's good to think about these things and optimize for lower latency, but if five-minute or longer TTL's simply don't fit your use case, then don't feel bad about it.
Re: Problems with low DNS TTLs
#43As a sysadmin with 20+ years experience, I've had long TTLs cause issues on several occasions. I've never regretted a short TTL.
I've been using 5 minute TTL in production for years, never noticed any problems with it. It has the advantage that it makes it super simple to deploy to production at a moment's notice, in case something unexpected occurs.
Re: Problems with low DNS TTLs
#44As a sysadmin with 20+ years experience, I've had long TTLs cause issues on several occasions. I've never regretted a short TTL.
[deleted]
Re: Problems with low DNS TTLs
#45What is the use cases for having the TTL shorter than 5 minutes?
DNS based network load balancing. If you have two data centers, and you want to be able to dynamically and deterministically shift load between them, you want a short TTL so you can control the percentage of traffic going to each data center.
Re: Problems with low DNS TTLs
#46As a sysadmin with 20+ years experience, I've had long TTLs cause issues on several occasions. I've never regretted a short TTL.
The part that's missing in DNS is the ability to tell people that the cache expired. You can't really do this in DNS itself since a cached response will never hit the network. You could add a signal in the application protocol for example: .
You'd also have to do that for SMTP, IMAP, etc. Probably not worth the complexity as low TTLs seem to work well enough with few enough downsides. DNS is already a tricky enough protocol.
Re: Problems with low DNS TTLs
#47As a sysadmin with 20+ years experience, I've had long TTLs cause issues on several occasions. I've never regretted a short TTL.
Same, saw a DNS entry for an internal DB endpoint get updated with an 8 hour TTL for a planned failover. DB Admins went to sleep as everything was fine, everyone woke up 8 hours later with everything failing to connect. Had to flush the DNS on each internal server to fix that issue.
The issue here is whether a one-time migration lazyness justifies millions or billions of DNS requests to a web service that could've been saved for customers.
And I do not think it does. DNS without caching is useless traffic overhead. Just like HTTP responses without gzip compression. DNS entries almost never change, therefore it should be cached accordingly.
Re: Problems with low DNS TTLs
#48What is the use cases for having the TTL shorter than 5 minutes?
The article posits why: Why are DNS records set with such low TTLs? - Legacy load balancers left with default settings - The urban legend that DNS-based load balancing depends on TTLs (it doesn’t - since Netscape Navigator, clients pick a random IP from a RR set, and transparently try another one if they can’t connect) - Administrators wanting their changes to be applied immediately, because it may require less plann…
The DNS based load balancing isn’t a myth if you want to do any kind of load balancing that isn’t round robin. If you want to, say, send 10% of traffic to data center A and 90% to data center B, and you don’t want to use up 10 IPs to do that.
Re: Problems with low DNS TTLs
#49Earlier quoted context omitted.
> Administrators wanting their changes to be applied immediately, because it may require less planning work. Why is this not valid?
But 5 minutes should be fine? It surprised me that so many has 1 second or 20 second TTL.
If I need to get a web service up and I can save 4 minutes by setting a low TTL when I configure my DNS record why wouldn't I?
Re: Problems with low DNS TTLs
#50Maybe for losely coupled systems. Unavoidable in tightly coupled systems because it's a convenient way to do things unless you already have elaborate HA infra and protocols in place.
For example, if you offer an "entrypoint" that you can guarantee and technically make to be stable, then use longish TTLs. Anycast IPs are an extreme, but inbetween there are many useful modes of exploiting longish but not too long TTLs.
On the other hand, if you implement system failover in a locally redundant system and want to exploit DNS so you don't have to manage additional technology to make an "entrypoint" HA (VRRP, other IP movements, ...), low TTLs are nice. AWS is I think using 5s TTLs on the ElastiCache node's primary DNS names.
Finally, 15m max is what I'm comfortable with. Any longer or much longer, and ANY MISTAKE, and you can easily be in a world of hurt. It's no fun sitting out a DNS mistake propagating around the world and the fix lagging behind.
And this is only a view on "respectable TTL" values. DNS services like Google's public dns probably ignore any or all TTLs for records they pull, and refresh them as fast as possible anyway, at least according to my observation. In that sense, I doubt that most of the internet is still using "respectable" TTLs --- I suspect most systems will RACE to get new data ASAP.