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

51–60 of 163 posts

Re: Problems with low DNS TTLs

#51

Post by Twirrim »

yjftsjthsd-h wrote: post #40
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.

Sorry - why would a 5m TTL take an hour to stop using? Shouldn't it be 5 minutes?

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.

Re: Problems with low DNS TTLs

#52

Post by icedchai »

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.

Definitely. About 12+ years ago, I had to prove to a vendor, with tcpdumps, etc., that they were connecting to the wrong server after we changed a DNS entry. 3 of their systems were working, the 4th hadn't been restarted and was connecting to the old address. Very frustrating.

Re: Problems with low DNS TTLs

#53

Post by rhacker »

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.

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.

Re: Problems with low DNS TTLs

#54

Post by eximius »

Okay, I thought this would be little more hyperbolic than it is. TTLs under a minute is a little ridiculous. 5m is plenty long for sessions and plenty short for migrations/recovery/what have you.

Re: Problems with low DNS TTLs

#55

Post by askbill »

>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 addresses. That's not load balancing. That's failover.

Additionally, most of the use cases for this that I'm aware of are Cname -> A record. This is to say, this method is being used with precision rather than RR.

I agree that running 60 second TTL's regardless of need is inefficient, but at a fast glance, the full argument doesn't hold up for me.

Re: Problems with low DNS TTLs

#56

Post by rntksi »

Unrelated to the author's post, but for LetsEncrypt TXT records (to have wildcard SSLs), I've always set the TTL very low (in the 1-2 minutes or so range). This is because when I renew SSLs, I don't want to wait for DNS caching of those TXT records to resolve all over the Internet.

I think that doesn't really affect anything traffic-wise. Just a thought I had in mind reading the article.

Re: Problems with low DNS TTLs

#57

Post by hkt »

DNS issues could be operated better by many of those running resolvers, for instance, by keeping caches primed for sites to reduce latency to end users - as opposed to extending TTLs.

This is probably the cheapest and best solution available for improving DNS related UX issues, and is likely to be something where a commercial DNS provider might do well.

Re: Problems with low DNS TTLs

#58

Post by ShakataGaNai »

Part of the problem is that so many devices are poorly behaved when it comes to DNS. At one point I worked for a company that had a large mobile app presence. We setup new authoritative name servers to conduct a test for a week or so. After the test was completed we removed the name servers records. A lot of clients went away very quickly... but way more stuck around way longer than they should have.

At two months post test, those test servers were still getting some traffic.

Re: Problems with low DNS TTLs

#59

Post by abricot »

krzyk wrote: post #23
JimWestergren wrote: post #2

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

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?
Post reply on HN