Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Problems with low DNS TTLs

00f.net

Post reply on HN
Print view View original

91–100 of 163 posts

Re: Problems with low DNS TTLs

#91

Post by cogman10 »

rhacker wrote: post #53
cookiengineer wrote: post #47

Earlier 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…

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.

Re: Problems with low DNS TTLs

#92

Post by EricE »

aequitas wrote: post #11
codyb wrote: post #6

Earlier quoted context omitted.

I always was under the impression people lowered the TTL when updating records... which doesn't even really make sense since the change won't propagate until the previous TTL is overrun anyways. Then you were supposed to update it to a longer TTL when your change had propagated. So, I guess, after understanding things better... there is no use case really since if it's a new record your change will always propagate,…

It could help to lower your TTL way before you plan to update. If your current TTL was 24h, you just update it to 5m 24 hours before you plan the actual change of the record itself. The new record can them be set to 24h directly (unless you want a quick turnaround for rollback). It's still no guarantee all changes will propagate within 5 minutes. But it gives some ease of mind to know the bulk of change won't take a…

Yes - it’s called planning. Lowering TTL well in advanced is not a new concept and works very well if you have enough advanced notice from the application owners ahead of time :p

Re: Problems with low DNS TTLs

#93

Post by pas »

arp242 wrote: post #46
sparrish wrote: post #29

As 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 p…

Use a new (sub)domain. Your main domain can then simply redirect to whatever subdomain you wish.

Re: Problems with low DNS TTLs

#94

Post by Panino »

jeffbee wrote: post #18

It doesn’t sound like the author has ever operated a large scale service. There are reasons why every big operator has short TTLs and it isn’t because they are stupid.

Frank Denis worked for years for OpenDNS, one of the largest recursive DNS services on the Internet. While there he developed DNSCrypt, which has many users and was instrumental in pushing for encrypted DNS. And looking through his github, he has other DNS tools as well. DNS is a contentious issue and I don't agree with anyone on everything they say about the subject, but I agree with Frank here on the waste of absurdly low TTLs and in any case it's wrong to think he is inexperienced.

Re: Problems with low DNS TTLs

#95

Post by mlyle »

cogman10 wrote: post #91
rhacker wrote: post #53

Earlier quoted context omitted.

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…

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 potentia…

Surely we can live with 5-10 minutes for most things, though, right?

Re: Problems with low DNS TTLs

#97

Post by _wldu »

sparrish wrote: post #29

As a sysadmin with 20+ years experience, I've had long TTLs cause issues on several occasions. I've never regretted a short TTL.

15 mins is the shortest I would want to go. Otherwise, your app is going to be perceived as slow (by your users) because it has to do a bunch of needless DNS lookups a lot.

Re: Problems with low DNS TTLs

#98

Post by gnu8 »

elp wrote: post #30
ru552 wrote: post #15

Earlier quoted context omitted.

You got the use case right, but I think you're still thinking about it wrong. In-use public DNS changes aren't something that just crop up and need to be done immediately. Eg. Five days from now, I'm going to make an infrastructure change that will affect public DNS. Today, I lower my TTL on affected records. Five days later I make the public changes, still using the lower TTL. Once I am satisfied my change will stay…

In practice though other things come up and the admin doesn't get round to increasing the TTL back to sanity later because nothing is broken if they don't.

Sure but in a department where people are sysadminning reactively, they’re going to have that problem crop up everywhere. This type of thing wouldn’t be neglected in a well thought-out change process.

Re: Problems with low DNS TTLs

#99

Post by sparrish »

marcosdumay wrote: post #84
sparrish wrote: post #29

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. I've seen enough people complaining about overloaded DNS servers.

Yes, that happens.

I've seen way more people complain about outages that lasted hours because of long TTLs and a deployment mistake.

Re: Problems with low DNS TTLs

#100

Post by stevekemp »

yjftsjthsd-h wrote: post #80
stevekemp wrote: post #65

Earlier quoted context omitted.

That's a surprise - I've handled migrations like this in the past, and we always setup a simple proxy to forward traffic for a while. I've definitely lost count of the number of clients that would cache the old IPs, despite valid and low TTLs being in-place well in advance of a migration.

The impression I got from the senior sysadmins was that we considered clients caching records beyond TTL to be a bug on their side and not our problem, and (importantly) the nature of our business/clients allowed us to make that determination and not take corrective measures to compensate for client-side misconfigurations. As such, practicing traffic would have been considered at best unnecessary work (and at worst c…

I can appreciate that, I know that I would see traffic hit the old IP for >3 days. I suspect old Java clients, etc, that would resolve IPs once on startup and never again.

In our case it was worth keeping things working for a few days, but after a week at the outside we'd kill the proxying/forwarding.

Post reply on HN