As 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 never regretted a short TTL.
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.
For a lot of things changing domain is quite a hassle, and the old domain will still be around, cached, and considered valid (because its ttl hasn't expired yet).
I agree with GP in saying that a short TTL never created too much issue.
Now, to come to the original issue: short ttl.
What do you expect, in this day and age?
With all this cloud stuff going up and down, being created and destroyed again and again, ephemeral stuff that doesn't even last a whole single day...
Of course you need a short ttl.
Edit: Worth noting there's lots of software that seems to only resolve hostnames at first connection, then hangs onto it forever. Lots of java internals for example, unless you poke in specific configuration.
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.
K8s Ingress and Cloudfront alone will probably make the customer visible IP addresses nearly static forever. We don't live in the old world where we had to take a server down any more. It's all managed.
If it's going to take more than 3 hours to setup the new traffic target anyway, sure. You have time to fiddle with TTLs. If you have servers ready to go elsewhere, 1-5 minute TTLs are nice so you can quickly move things when you notice a problem.
1 minute is a long time, you can do a ton of requests in 60,000 milliseconds.
On the flip side, setting the TTL long can be a disaster. You can't fix it after the fact. If you have a 1 hour TTL then that's potentially 1 hour before the changes needed to fix a service fully take effect. That's 1 hour of helplessness.
I definitely think it's worth the millions or billions of DNS requests.
Use short TTLs, your customers will thank you.
Default TTL: 12 hours;
[<startdate> to <enddate>] TTL: 10 minutes;
Default TTL: 12 hours;
[Thu 0000-1200, repeating]: 5 minutes;
[<startdate> to <enddate>] TTL: 10 minutes;
I dunno, I'm sure there's other downsides I haven't thought of, and proper implementation would require thinking through side effects. But after a long time dealing with it feels like there's some room for something beyond one single TTL ever which must be specifically changed (with a wait for propagation) well ahead of time whenever anything planned with a risk of issues needs to be done. Maybe?
eg.
- Check if there's a maintenance window in the next [max TTL]
- If not, set TTL = [max TTL]
- Otherwise, set TTL = [time until maintenance window]
- Repeat
Very much this sentiment.
When migrating a website many years ago, I forgot to lower the TTL of companyname.co.uk. I had lowered the TTL of www. but not the root.
So when the big switchover came, half the traffic stayed where it was. Not only that the new backend fell over.
having that option to roll out/in would have been really useful.
Now with the cloud stuff goes away with, so having a TTL of 3600 means long outages.
I've seen more problems caused by the JVM, by default on some configurations, caching DNS indefinitely, regardless of TTL, than caused by a short TTL.
I remember having to bounce Java apps every time DNS changed, which never made sense to me. It's literally the point of DNS to not have to do that.
No one ever said this.
Less than a minute is excessively short. Most long-lived applications will internally cache your IP address for longer than a minute no matter what you do.
As a user with 20+ years of experience, I have never regretted using authoritative DNS as the source for DNS data instead of DNS caches. Instead of using a shared cache, I bind local authoritative servers loaded with zone files containing the DNS data that applications need to the loopback. IME, lookups are faster than with a cache.
IMO as a user, recursive queries to shared caches are overrated. I want to know what lookups the applications I use are making and I want control over what DNS data is available to them. IME, giving applications license to lookup any resource at any time means this permission will be abused to further the interests of the online ad industry and all those who service it instead of 100% serving the interests of the user.
For example, a commercial router's management console does not need to be able to look up the addresses of ad servers. Letting it have access to a remote shared cache, or even a local one, that does recursive queries is unnecessary. The user has already paid for the router.
I've seen enough people complaining about overloaded DNS servers.
I've seen way more people complain about outages that lasted hours because of long TTLs and a deployment mistake.
1. DNS lookups add on the order of 100ms to load time.
2. In both cases (5 min and 15 min) the user is going to do a DNS lookup on the first page, then have cached DNS while they browse for a bit, then have a DNS lookup at some point in the future.
Most web sessions are relatively short, so I doubt most users would even notice the difference where they see an extra 100ms load time at, say, 2 points in their session instead of 1.
In my experience the appropriate use of the preconnect and dns-prefetch hints has a much bigger impact on perceived performance than worrying about DNS TTLs beyond 5 min.