[HN Gopher] Stop using low DNS TTLs
___________________________________________________________________
Stop using low DNS TTLs
Author : swills
Score : 21 points
Date : 2026-01-30 15:12 UTC (7 hours ago)
(HTM) web link (blog.apnic.net)
(TXT) w3m dump (blog.apnic.net)
| bjourne wrote:
| I don't understand why the author doesn't consider load balancing
| and failover legitimate use cases for low ttl. Cause it wrecks
| their argument?
| c45y wrote:
| Probably an expectation for floating IPs for load balancing
| instead of DNS.
|
| Relatively simple inside a network range you control but no
| idea how that works across different networks in geographical
| redundant setups
| preisschild wrote:
| Anycast pretty much
| deceptionatd wrote:
| Agreed; I have no idea how you'd implement that across
| multiple ASNs, which is definitely a requirement for multi-
| cloud or geo-redundant architectures.
|
| Seems like you'd be trying to work against the basic design
| principles of Internet routing at that point.
| BitPirate wrote:
| Why do you need a low ttl for those? You can add multiple IPs
| to your A/AAAA records for very basic load balancing. And DNS
| is a pretty bad idea for any kind of failover. You can set a
| very low ttl, but providers might simply enforce a larger one.
| Matheus28 wrote:
| If you add multiple IPs to a record, a lot of resolvers will
| simply use the first one. So even in that case you need a low
| TTL to shuffle them constantly
| toast0 wrote:
| You don't want to add too many A/AAAA records, or your
| response gets too big and you run into fun times. IIRC, you
| can do about 8 of each before you get to the magic 512 byte
| length (yeah, you're supposed to be able to do more, 1232
| bytes as of 2020-10-01, but if you can fit in 512 bytes, you
| might have better results on a few networks that never got
| the memo)
|
| And then if you're dealing with browsers, they're not the
| best at trying everything, or they may wait a long time
| before trying another host if the first is non-responsive.
| For browsers and rotations that really do change, I like a 60
| second TTL. If it's pretty stable most of the time, 15
| minutes most of the time, and crank it down before
| intentional changes.
|
| If you've got a smart client that will get all the answers,
| and reasonably try them, then 5-60 minutes seems reasonable,
| depending on how often you make big changes.
|
| All that said, some caches will keep your records basically
| forever, and there's not much you can do about that. Just
| gotta live with it.
| deceptionatd wrote:
| It's not good as a first line of defense for failover, but
| with some client software and/or failure mechanisms there
| aren't any better approachs I'm aware of. Some of the
| software I administer doesn't understand multiple A/AAAA
| records.
|
| And a BGP failure is a good example too. It doesn't matter
| how resilient the failover mechanisms for one IP are if the
| routing tables are wrong.
|
| Agreed about some providers enforcing a larger one, though.
| DNS propagation is wildly inconsistent.
| Bender wrote:
| Perhaps as most these days are using Anycast [1] to do
| failovers. It's faster and not subject to all the oddities that
| come with every application having its own interpretation of
| DNS RFC's _most notably java and all its work-arounds that
| people may or may not be using_ and all the assorted recursive
| cache servers that also have their own quirks thus making
| Anycast a more reliable and predictable choice.
|
| [1] - https://en.wikipedia.org/wiki/Anycast
| garciasn wrote:
| Could it be because folks set it low for initial propagation and
| then never change it back after they set it up.
| fukawi2 wrote:
| That's not how TTL works. Or do you mean propagation after
| changing an existing RR?
|
| It's "common" to lower a TTL in preparation for a change to an
| existing RR, but you need to make sure you lower it at least as
| long as the current TTL prior to the change. Keeping the TTL
| low after the change isn't beneficial unless you're planning
| for the possibility of reverting the change.
|
| A low TTL on a new record will not speed propagation. Resolvers
| either have the new record cached or they don't. If it's
| cached, the TTL doesn't matter because it already has the
| record (propogated). If it doesn't have it cached, then it
| doesn't know the TTL so doesn't matter if it's 1 second or 1
| month.
| garciasn wrote:
| I meant both. Initial (which you say doesn't matter; TIL) and
| edits after-the-fact. I learned something new today and I've
| been doing DNS crap for decades; I feel like a doofus.
| deceptionatd wrote:
| Maybe, but I don't think TTL matters for speed of initial
| propagation. I do set it low when I first configure a website
| so I don't have to wait hours to correct a mistake I might not
| have noticed.
| deceptionatd wrote:
| I have mine set low on some records because I want to be able to
| change the IP associated with specific RTMP endpoints if a
| provider goes down. The client software doesn't use multiple A
| records even if I provide them, so I can't use that approach; and
| I don't always have remote admin access to the systems in
| question so I can't just use straight IPs or a hostfile.
| Neywiny wrote:
| I guess I'm not sure I understand the solution. I use a low value
| (idk 15 minutes maybe?) because I don't have a static ip and I
| don't want that to cause issues. It's just me to my home server
| so I'm not adding noticable traffic like a real company or
| something, but what am I supposed to do? Is there a way for me to
| send an update such that all online caches get updated without
| needing to wait for them to time out?
| 1970-01-01 wrote:
| (2019)
___________________________________________________________________
(page generated 2026-01-30 23:01 UTC)