Live data from Hacker News

Problems with low DNS TTLs

00f.net

161–163 of 163 posts

Re: Problems with low DNS TTLs

#161
post #144

LOL lot of arguments for a feature that makes sysadmin/dev life easy once a year at the expense of degraded user experience every day (lot of sporadically broken ISP etc DNS servers civilians can't be expected to bypass). Digital littering.

quite the opposite, actually. more dns queries with a lower-ttl (say 10 minutes) means one additional round-trip every 10 minutes. how long can a round-trip be, 200msec worst case scenario? that looks good. now on the other hand, assume a 48h ttl and something breaks. now you've got all your users unable to reach your services for up to 48h. or worse, some of your users will go to the old ip, some to the new. what's…

I wish 10 minutes was the minimum acceptable TTL, that'd be tremendous progress already.

It's typically much more than 1 round trip, given typical amount of crap frameworks and gadgets that each load themselves and dependencies from around the world on a typical webpage. On a page that takes 50 seconds to load all the crap from 50 servers each with a 5 second TTL through a flaky ISP DNS server, you get hit all the time basically.

200ms is not worst case, that's more like median, worst case is DNS being stuck for minutes with responses lost or very slow (say 20 seconds). Often DNS is the only thing that's broken, and if you're in one session (with no new DNS request required beyond refreshes from expired TTL) it makes the difference between the user being stuck or being able to proceed unhindered, until they go to a new site requiring a new request.

Re: Problems with low DNS TTLs

#162
post #46

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

The part that's missing in DNS is the ability to tell people that the cache expired. You can't really do this in DNS itself since a cached response will never hit the network. You could add a signal in the application protocol for example: . You'd also have to do that for SMTP, IMAP, etc. Probably not worth the complexity as low TTLs seem to work well enough with few enough downsides. DNS is already a tricky enough p…

The event horizon of the stupidity singularity just became a little better defined.

Re: Problems with low DNS TTLs

#163
post #144

Earlier quoted context omitted.

quite the opposite, actually. more dns queries with a lower-ttl (say 10 minutes) means one additional round-trip every 10 minutes. how long can a round-trip be, 200msec worst case scenario? that looks good. now on the other hand, assume a 48h ttl and something breaks. now you've got all your users unable to reach your services for up to 48h. or worse, some of your users will go to the old ip, some to the new. what's…

I wish 10 minutes was the minimum acceptable TTL, that'd be tremendous progress already. It's typically much more than 1 round trip, given typical amount of crap frameworks and gadgets that each load themselves and dependencies from around the world on a typical webpage. On a page that takes 50 seconds to load all the crap from 50 servers each with a 5 second TTL through a flaky ISP DNS server, you get hit all the ti…

The only time I've seen DNS failing after seconds, about six seconds iirc, was when an host had three DNS server configured, all of which were wrong (public DNS servers, used to query an internal zone).

It took seconds for the request to time out because the host tried all three records one after another, and gave up only when all three had failed.

But, uh, that's an uncommon situation.

Post reply on HN