5 ms·

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 exp

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 static forever. We don't live in the old world where we had to take a server down any more. It's all managed.

laurent92 6y ago
What about 2 minutes during the first hour after a change, 30 minutes during 2 days, 3 hrs after that?
- squiggleblaz 6y ago
  I think the point is that I don't want to change my TTLs. If I had my druthers, yeah, they'd go up periodically, and then if tech support receives an issue that sounds like it might require DNS changes, they press a button and the TTL drops. Once that issue is closed, it goes back to gradually increasing.
- toast0 6y ago
  This would be fine for some uses. It's not great for client facing names where you want to be able to react to an incident and have traffic move over quickly. 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.
jabart 6y ago
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.
cogman10 6y ago
I just don't see the harm in a short TTL. Most apps are "bursty" so a 1 minute TTL is more than ample, basically giving them a 1 time penalty on the first request then nothing for the rest of the requests. 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.
- mlyle 6y ago
  Surely we can live with 5-10 minutes for most things, though, right?
  - cogman10 6y ago
    I don't see why not. I just don't see there being a huge difference between 1 and 10 minutes in the grand scheme of tech.
    - pixl97 6y ago
      That's an order of magnitude which can make a pretty big difference when demand spikes.
- mjevans 6y ago
  It would be nice if failure to connect / TLS handshake failure invalidated the entire related network stack cache for that link. If that were the case I wouldn't mind higher TTLs.

laurent92 6y ago

What about 2 minutes during the first hour after a change, 30 minutes during 2 days, 3 hrs after that?

squiggleblaz 6y ago
I think the point is that I don't want to change my TTLs. If I had my druthers, yeah, they'd go up periodically, and then if tech support receives an issue that sounds like it might require DNS changes, they press a button and the TTL drops. Once that issue is closed, it goes back to gradually increasing.
toast0 6y ago
This would be fine for some uses. It's not great for client facing names where you want to be able to react to an incident and have traffic move over quickly. 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.

jabart 6y ago

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.

cogman10 6y ago

I just don't see the harm in a short TTL. Most apps are "bursty" so a 1 minute TTL is more than ample, basically giving them a 1 time penalty on the first request then nothing for the rest of the requests. 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.

mlyle 6y ago
Surely we can live with 5-10 minutes for most things, though, right?
- cogman10 6y ago
  I don't see why not. I just don't see there being a huge difference between 1 and 10 minutes in the grand scheme of tech.
  - pixl97 6y ago
    That's an order of magnitude which can make a pretty big difference when demand spikes.
mjevans 6y ago
It would be nice if failure to connect / TLS handshake failure invalidated the entire related network stack cache for that link. If that were the case I wouldn't mind higher TTLs.