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 always go for 5 minutes. The workaround would be to lower the TTL we you know you are gonna make changes soon.
Problems with low DNS TTLs
81–90 of 163 posts
Re: Problems with low DNS TTLs
#82I've seen issues with some DNS caches not honouring the TTLs if they're too short (less than 1 hour iirc, although memory is a bit hazy, it was some years ago) - in particular academic institutions tended to be the biggest culprits for this.
Re: Problems with low DNS TTLs
#83Earlier quoted context omitted.
But those are no valid use cases which was my question. So there are no valid use cases at all?
The major cases revolve around failure recovery, and traffic distribution. A 5 minute outage is not acceptable in many industries or at scale. If a load balancer or DC fails we need to ensure traffic moves away fast. Similarly if you want to take a system out for maintenance or perform migrations.
> A 5 minute outage is not acceptable in many industries or at scale.
Well, if that's the case, you better have your redundant systems on your normal DNS entries, because there is no chance you will distribute new entries over the internet in 5 minutes, whatever value you specify at the TTL.
Re: Problems with low DNS TTLs
#84As 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.
I've seen enough people complaining about overloaded DNS servers.
Re: Problems with low DNS TTLs
#85Earlier quoted context omitted.
Sorry - why would a 5m TTL take an hour to stop using? Shouldn't it be 5 minutes?
If things behaved nicely, yes. There's all sorts of weird DNS caching behaviour out there. It's not unusual to find folks with DNS servers / clients that are caching records for 1 hour+, and then of course there's people running super old versions of Java that used to cache DNS forever by default (before JDK 6). There's a very clear set of user that seem to cache for 10-15 minutes, regardless of any DNS TTL.
You can't fix systems that ignore your TTL by specifying lower TTL values.
Re: Problems with low DNS TTLs
#86Earlier quoted context omitted.
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.
I'd kind of like if there was some ability to have more complex multi-part TTLs as an option along with a default TTL (the current one). So I could specify Default TTL: 12 hours; [ to ] TTL: 10 minutes; or even Default TTL: 12 hours; [Thu 0000-1200, repeating]: 5 minutes; [ to ] TTL: 10 minutes; So with no further effort all downstream caches/clients can basically have advanced notice of regular maintenance windows a…
[deleted]
Re: Problems with low DNS TTLs
#87Earlier quoted context omitted.
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.
I generally agree with this. I think most of us that have set a DNS entry use a low TTL because of experiences we had 5, 10, 15 years ago. Really really bad experiences. I'm not necessarily arguing to increase the TTL, but maybe we should beg the question: with all the new routing tech out there, is low TTL still necessary? K8s Ingress and Cloudfront alone will probably make the customer visible IP addresses nearly s…
During the Centurylink outage, like last year?, I had to switch IPs to a different network since those were exposed over BGP and you couldn't update BGP anymore. All one offs sure, the point of low TTLs is to be prepared. I pay for Route53 by the query so I'm aware of the cost and it's still nothing compared to the cost of an outage waiting for a TTL to expire.
Re: Problems with low DNS TTLs
#88Earlier quoted context omitted.
If you want to deterministically shift load, you use routing, not DNS, to manage your load. That’s what is missing from this discussion.
How would you use routing to balance load at that granularity?
Rather easily. There are routing protocols designed for such things. Far more reliable than trying to hijack DNS for load balancing.
Indeed the root DNS servers are not a single server but pools of geographically distributed servers via anycast.
Re: Problems with low DNS TTLs
#89What is the use cases for having the TTL shorter than 5 minutes?
Windows Update. To reboot a server, you need to take it out of production. With a TTL of 5 minutes, it can take an hour for (nearly) all users to stop using that server.
Good grief- you do not need to reboot the server; just flush the cache https://www.dnsstuff.com/clear-flush-dns-server-cache-window...
Re: Problems with low DNS TTLs
#90Earlier quoted context omitted.
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.
I generally agree with this. I think most of us that have set a DNS entry use a low TTL because of experiences we had 5, 10, 15 years ago. Really really bad experiences. I'm not necessarily arguing to increase the TTL, but maybe we should beg the question: with all the new routing tech out there, is low TTL still necessary? K8s Ingress and Cloudfront alone will probably make the customer visible IP addresses nearly s…
What about 2 minutes during the first hour after a change, 30 minutes during 2 days, 3 hrs after that?