this post was submitted on 30 Jan 2026
41 points (91.8% liked)

Technology

80479 readers
3507 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related news or articles.
  3. Be excellent to each other!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
  9. Check for duplicates before posting, duplicates may be removed
  10. Accounts 7 days and younger will have their posts automatically removed.

Approved Bots


founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] CarbonatedPastaSauce@lemmy.world 23 points 5 days ago (2 children)

There are lots of reasons to use really low TTLs, but most are a temporary need. Most of the times I had to set low TTLs for records were for hardware migration projects where services were getting new IP addresses. But in a well managed shop this should always be temporary. The TTL would be set low the day before the change, then set back to a normal value the day after the change. I feel the author is correct in that permanently setting low TTLs just covers up a lack of proper planning and change management.

The only thing off the top of my head that I can think absolutely requires a permanently low TTL is DNS based global load balancing for high uptime applications. But I'm sure there are other uses. I agree that the vast majority of things do not need a low TTL on their DNS record.

[–] SpaceNoodle@lemmy.world 5 points 5 days ago

So the options are to herd a million cats, or to set low TTLs? Hmmm ...

[–] CompactFlax@discuss.tchncs.de 2 points 5 days ago

I have a reasonably latent connection and using pihole and an anycast upstream resolver is noticeably slow. It falls out of pihole cache so freaking fast with these low TTL. I have set up unbound with aggressive caching prefetch and if I recall correctly pihole has a toggle to serve expired. Serving expired in unbound, before pihole, breaks stuff that rotates IP fast.