Live data from Hacker News

Problems with low DNS TTLs

00f.net

31–40 of 163 posts

Re: Problems with low DNS TTLs

#31

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 would put a reasonable floor on short TTLs (5 minutes?), but yes, it's nice in an emergency to be able to send everyone someplace new. Sucks if you're down, hacked, etc, and can't do anything about an existing long TTL other than wait it out.

Edit: Worth noting there's lots of software that seems to only resolve hostnames at first connection, then hangs onto it forever. Lots of java internals for example, unless you poke in specific configuration.

Re: Problems with low DNS TTLs

#33

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.

Re: Problems with low DNS TTLs

#34
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, and the name server has to resolve the name recursively, which can be slow.

Re: Problems with low DNS TTLs

#36

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

We have a service that uses AWS Route53 health checks, and set the records to 60s TTL because if there is a problem at the primary service fails healthcheck, we want it to get the updated DNS records, which point to another data center, fairly quickly.

In our case, primary is AWS with a protection service in front of it, and secondary is our own servers at a data center. So something like VRRP wouldn't work.

Re: Problems with low DNS TTLs

#37

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

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.

Re: Problems with low DNS TTLs

#38

Earlier quoted context omitted.

The article posits why: Why are DNS records set with such low TTLs? - Legacy load balancers left with default settings - 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) - Administrators wanting their changes to be applied immediately, because it may require less plann…

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

The major cases revolve around failure recovery, and traffic distribution. A 5 minute outage is not acceptable in many industries or at scale.

If a load balancer or DC fails we need to ensure traffic moves away fast. Similarly if you want to take a system out for maintenance or perform migrations.

Re: Problems with low DNS TTLs

#40
post #32

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

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