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

61–70 of 163 posts

Re: Problems with low DNS TTLs

#61

Post by hiq »

yarcob wrote: post #34
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'…

> 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 the previous result (the "soft-invalidation" I mentioned, for lack of a better word), it shouldn't have any impact for the user.

Re: Problems with low DNS TTLs

#62

Post by numbsafari »

cortesoft wrote: post #45
JimWestergren wrote: post #2

What is the use cases for having the TTL shorter than 5 minutes?

DNS based network load balancing. If you have two data centers, and you want to be able to dynamically and deterministically shift load between them, you want a short TTL so you can control the percentage of traffic going to each data center.

If you want to deterministically shift load, you use routing, not DNS, to manage your load.

That’s what is missing from this discussion.

Re: Problems with low DNS TTLs

#63

Post by cstejerean »

askbill wrote: post #55

>The urban legend that DNS-based load balancing depends on TTLs (it doesn’t - since Netscape Navigator, clients pick a random IP from a RR set, and transparently try another one if they can’t connect) That's just not how this works at all. While you could use RR records for this purpose, I believe the author is suggesting that load balancing will happen automatically when the client simply can't connect to one of the…

I think load balancing in that argument happens via “clients picks a random IP” and failover happens via “transparently try another if they can’t connect”.

So that would be both load balancing and failover, why doesn’t the argument hold up?

Re: Problems with low DNS TTLs

#64

Post by smitop »

CloudFlare has a "Auto" TTL option, which is the default, and required to be used when reverse proxying through CloudFlare. There is nothing magical about "Auto" TTL, though: it appears to literally always be 299 seconds. A lot of low TTLs you see are probably caused by CloudFlare.

Re: Problems with low DNS TTLs

#65

Post by stevekemp »

yjftsjthsd-h wrote: post #28
smachiz wrote: post #26

Earlier quoted context omitted.

Yes, for 40 minutes to 1 hour. But I bet you still ran forwarders on the old hosts for at least an hour after you cut over DNS.

> But I bet you still ran forwarders on the old hosts for at least an hour after you cut over DNS. I promise you we did not.

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.

Re: Problems with low DNS TTLs

#66

Post by sparrish »

cookiengineer wrote: post #47
jabart wrote: post #37

Earlier quoted context omitted.

Same, saw a DNS entry for an internal DB endpoint get updated with an 8 hour TTL for a planned failover. DB Admins went to sleep as everything was fine, everyone woke up 8 hours later with everything failing to connect. Had to flush the DNS on each internal server to fix that issue.

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.

Migration accidents happen. If your TTLs are long, those accidents cause long disruptions and big downtimes. That's a poor customer experience.

I definitely think it's worth the millions or billions of DNS requests.

Use short TTLs, your customers will thank you.

Re: Problems with low DNS TTLs

#67

Post by gregsadetsky »

I was happy to have a low 10 minute TTL a few days ago when Netlify's apex domain IP address stopped working and I had to change it to the new IP that they announced on their status page...! :-) [0]

Netlify's "previous" IP was down for ~4 hours.

[0] https://news.ycombinator.com/item?id=26581027

Re: Problems with low DNS TTLs

#68

Post by cortesoft »

numbsafari wrote: post #62
cortesoft wrote: post #45

Earlier quoted context omitted.

DNS based network load balancing. If you have two data centers, and you want to be able to dynamically and deterministically shift load between them, you want a short TTL so you can control the percentage of traffic going to each data center.

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?

Re: Problems with low DNS TTLs

#69

Post by Androider »

smitop wrote: post #64

CloudFlare has a "Auto" TTL option, which is the default, and required to be used when reverse proxying through CloudFlare. There is nothing magical about "Auto" TTL, though: it appears to literally always be 299 seconds. A lot of low TTLs you see are probably caused by CloudFlare.

Similarly, AWS Route 53 alias records use a 60 second TTL and there's no way to change that, so that's probably about a quarter of the Internet right there. Also when creating a manual record in Route 53, the default is 300 seconds and you'd have to go out of your way to pick another value.

Re: Problems with low DNS TTLs

#70

Post by cmeacham98 »

Doubt long TTLs matter that much, given that plenty of software also has a max TTL value[1], including all popular browsers (Chrome(ium), WebKit aka Safari, Necko aka Firefox, Trident aka IE) and the most popular mobile OS (Android). You could maybe get lucky with some caching on your router, but in my experience cheap consumer routers just act as DNS forwarders and have little to no caching (I could not find any explicit data on this however).

1: https://www.ctrl.blog/entry/dns-client-ttl.html

Post reply on HN