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

101–110 of 163 posts

Re: Problems with low DNS TTLs

#101

Post by cortesoft »

EricE wrote: post #88
cortesoft wrote: post #68

Earlier quoted context omitted.

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.

Anycast doesn't support percentage based load balancing unless you control all the hops between client and server, which is almost never the case if you are serving the public.

Every request that comes from the same network is going to be routed the same way. Anycast works great for regional load balancing in general, but it doesn't work for subdividing individual networks.

Re: Problems with low DNS TTLs

#102

Post by Twirrim »

marcosdumay wrote: post #85
Twirrim wrote: post #51

Earlier quoted context omitted.

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.

Sure. My general approach is to use lower TTL values (~ 5 minutes) and just accept that if people do dumb things, they just have to put up with things randomly breaking unexpected.

Re: Problems with low DNS TTLs

#103

Post by don-code »

gertrunde wrote: post #82

I'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.

I've seen this happen with mobile providers and ISPs in APAC, especially Australia and New Zealand. In the worst case, a migration we expected to take place within an hour actually long-tailed to a full 24 hours - where within an hour, practically all of the US and Europe had migrated, and practically none of ANZ had.

Re: Problems with low DNS TTLs

#104

Post by karmakaze »

Had to get to the very end to see that 'ridiculously low' was anything shorter than "between 40 minutes (2400 seconds) and 1 hour."

No thank you, if there's an outage that needs a DNS update to resolve it, 5 to 15 minutes is much more reasonable.

Re: Problems with low DNS TTLs

#105

Post by cactus2093 »

hiq wrote: post #22

I think it'd be more interesting to measure the impact on the end user. The article mentions a drop in queries, but aren't DNS queries a drop in the bucket compared to the size of most web pages anyway? Is the difference really noticeable? Do you get faster web pages if you cache for a longer time? If you do, shouldn't web browsers "soft-invalidate" (use the entry, but update it right after) the cache entry when you'…

I thought the same thing. This post included lots of data about the system-wide behavior of the DNS system, but no data about the end user experience. It's obvious there will be some reduced latency for users, but what is the distribution there in the real world? If the mean is like 10ms extra or something, it's not really worth optimizing for anybody except maybe the very biggest players on the web (and even they might decide the trade-offs are not worth it).

It's just very easy to shoot yourself in the foot with a long DNS TTL, in the worst case taking down your entire site until the TTL expires if you ever misconfigure it. Why risk it for a small gain?

Also, even theoretically it's not clear to me that it would help end user experience. Someone correct me if I'm wrong, but I believe if there's already an open connection from the browser to the server based on the TCP keep-alive settings, the browser will continue to use it rather than kill it and open a new connection starting with a DNS lookup even if the DNS TTL expires. So for an otherwise well-tuned site, each user session should expect to do a DNS lookup at the start of the session but then the rest of the requests in that session won't need to.

If that's true, then the only way DNS TTL will affect the end user experience is if the TTL is long enough such that there are a significant number of instances where the time between sessions for one user on the same device is longer than the DNS TTL. Most sites don't have their users returning every 30 minutes, they're lucky to get someone as a daily active or even weekly active user. So the TTL might have to be ~ a few days long to impact a significant number of users (and even then, probably only by a few tens of milliseconds at the beginning of the session).

Re: Problems with low DNS TTLs

#106

Post by KaiserPro »

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.

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.

Re: Problems with low DNS TTLs

#107

Post by squiggleblaz »

laurent92 wrote: post #90
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…

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

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.

Re: Problems with low DNS TTLs

#108

Post by xg15 »

hiq wrote: post #22

I think it'd be more interesting to measure the impact on the end user. The article mentions a drop in queries, but aren't DNS queries a drop in the bucket compared to the size of most web pages anyway? Is the difference really noticeable? Do you get faster web pages if you cache for a longer time? If you do, shouldn't web browsers "soft-invalidate" (use the entry, but update it right after) the cache entry when you'…

I have no data, but I think it should make a difference. The impact is not about bandwidth but about latency, so the size of a query plays no role - what does play a role is how many network roundtrips the browser has to do before the page becomes usable.

Seems to me that short TTLs in connection with the current trend to include scripts from dozens of different domains could easily double the number of average roundtrips per page load here.

Re: Problems with low DNS TTLs

#109

Post by xg15 »

Reading the article and then reading the comments is interesting. I guess this is a good example of a feature which in theory would benefit both, users and sites - but which falls flat because it's infeasible for ops.
Post reply on HN