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

111–120 of 163 posts

Re: Problems with low DNS TTLs

#111

Post by squiggleblaz »

jamescun wrote: post #33
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.

This mirrors my experience. 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.

But that isn't the issue at question. If the TTL is 300 seconds or 3600 seconds and the JVM holds onto it for three weeks, you can't blame a TTL of 3600 seconds for that, and setting the TTL down to 0 seconds at all isn't going to fix it either (unless, bizarrely, the JVM developers decided to respect TTLs of 0-60 and treat all other values as infinite).

Re: Problems with low DNS TTLs

#112

Post by yarcob »

hiq wrote: post #61
yarcob wrote: post #34

Earlier quoted context omitted.

> aren't DNS queries a drop in the bucket compared to the size of most web pages anyway? The client needs to wait for the result of a DNS query before it can do anything else. The bandwidth is irrelevant, the problem is the delay. Usually DNS queries are cached by a server near the user, so they are very fast. But if the authoritative name server has a very short TTL, then those cached results will often be stale, an…

> The client needs to wait for the result of a DNS query before it can do anything else. The bandwidth is irrelevant, the problem is the delay. You're right. But the article seems to claim the number of queries can be reduced with a higher TTL, which is why these should be enforced. Fair enough, but so what? In any case, the TTL is irrelevant for the first query. For the next ones, if you allow yourself to rely on th…

> TTL is irrelevant for the first query

With a long TTL, the chances are higher that your router or your ISP has the name cached. Round trip to your ISP is very short.

If you have a short TTL, the ISPs name server may have to query the next server in the chain.

If the authoritative name server is 10000km away, that means at least 60ms extra round trip time (speed of light).

Re: Problems with low DNS TTLs

#113

Post by topranks »

avidiax wrote: post #78

The problem is that the DNS TTL is a feature designed for a static internet of the 70's or 80's. What this points to is a need for an authenticated DNS pushes for refresh/invalidation. All supporting resolvers could keep a list of supporting clients that were told that "foo is at address 42". If the record changes, the authoritative DNS server sends a DNSSEC signed unsolicited response to all previous requesters to u…

That is an insane amount of state for auth dns servers to maintain.

“Pushing” the message out that the record has changed would also prove tricky to implement I’d say.

Re: Problems with low DNS TTLs

#114

Post by numbsafari »

cortesoft wrote: post #68
numbsafari wrote: post #62

Earlier 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 than get into a lot of details, here's some excellent starting points:

[1] Google Cloud networking in depth: Cloud Load Balancing desconstructed - https://cloud.google.com/blog/products/networking/google-clo...

[2] What is AWS Global Accelerator: https://docs.aws.amazon.com/global-accelerator/latest/dg/wha...

[3] Tumblr: Hashing Your Way To Handling 23,000 Blog Requests Per Second: http://highscalability.com/blog/2014/8/4/tumblr-hashing-your...

[4] Load Balancing without Load Balancers: https://blog.cloudflare.com/cloudflares-architecture-elimina...

Re: Problems with low DNS TTLs

#115

Post by speleding »

I noticed Cloudfront sets a TTL of 60 seconds on its distributions and also on the elastic load balancers. You pay for every Route 53 lookup if you have an ALIAS record pointing there, as is typical. So AWS does not have an incentive to set it any higher.

But if I understand it correctly, you can point a CNAME with a long TTL to the appropriate cloudfront.net record, and then you only pay for the CNAME one. The cloudfront.net lookup will not cost you anything. But the latency for your users will be worse because it adds a lookup (because an ALIAS record gets resolved without a lookup).

Re: Problems with low DNS TTLs

#116

Post by cogman10 »

mlyle wrote: post #95
cogman10 wrote: post #91

Earlier quoted context omitted.

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?

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.

Re: Problems with low DNS TTLs

#117

Post by majewsky »

xg15 wrote: post #109

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.

It's the classic problem with externalities. Every individual person does the thing that's most convenient for them, society has to suffer the consequences, but since no person individually caused the problem, it doesn't get fixed.

Honestly, the only way I would see this resolved is if Google demoted sites with low TTLs in SERP ranking, but they're no saints either (I can see a 5 minute TTL for google.com over here).

Re: Problems with low DNS TTLs

#118

Post by majewsky »

prophesi wrote: post #10
JimWestergren wrote: post #7

Earlier quoted context omitted.

But those are no valid use cases which was my question. So there are no valid use cases at all?

A low DNS TTL for testing purposes is a valid use case.

This is about production systems of large enterprises.

...

Please tell me you're not testing in production.

Re: Problems with low DNS TTLs

#119

Post by majewsky »

abricot wrote: post #59
krzyk wrote: post #23

Earlier quoted context omitted.

Maybe for those cases where one can get random IP from their ISP and has a e.g. hopto.org configured? One would probably be OK if it was 5 or 10 mins, but it depends on what's behind that dns entry and how often ISP can change the IP.

Do any ISPs generally change dynamic IPs more often than modem/routers reboot?

Some ISPs do it on a daily schedule. I know that the German Telekom rotates customer IPs every night at 01:45 AM, because a friend of mine is with them and that's the time when he drops from the video conference for a minute (if we stick around that long).

Re: Problems with low DNS TTLs

#120

Post by majewsky »

EricE wrote: post #89
rebelde wrote: post #32

Earlier quoted context omitted.

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

They mean they're rebooting the server having the IP that's entered in DNS, not rebooting the client consuming that service.
Post reply on HN