5 ms·
Stop using low DNS TTLs
- csense 8mo agoDNS is something you rarely change that has costly consequences if you mess it up: It can bring down an entire domain and keep it down until TTL passes. If you set your TTL to an hour, it raises the costs of DNS issues a lot: A problem that you fix immediately turns into an hour-long downtime. A problem that you don't fix on the first attempt and have to iteratively try multiple fixes turns into an hour-per-iteration downtime. Setting a low TTL is an extra packet and round-trip per connection; that's too cheap to meter [1]. When I first started administering servers I set TTL high to try to be a good netizen. Then after several instances of having to wait a long time for DNS to update, I started setting TTL low. Theoretically it causes more friction and resource usage but in practice it really hasn't been noticeable to me. [1] For the vast majority of companies / applications. I wouldn't be surprised to learn someone somewhere has some "weird" application where high TTL is critical to their functionality or unit economics but I would be very surprised if such applications were relevant to more than 5% of websites.
- UltraSane 8mo agoDNS TTLs are a terrible method of directing traffic because you can't rely on clients to honor it.
- nubinetwork 8mo ago> However, no one moving to a new infrastructure is going to expect clients to use the new DNS records within 1 minute, 5 minutes or 15 minutes When you run a website that receives new POSTed information every 60 seconds, you sure do. ;)
- arter45 8mo agoMeaning some kind of API that is periodically polled?
- bjourne 8mo agoI 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 8mo agoProbably 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 8mo agoAnycast pretty much
- deceptionatd 8mo agoAgreed; 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.
- _bernd 8mo agoYou can configure your assigned network numbers that other AS are allowed to announce certain networks of your own. Not uncommon for in examples authoritative name server addresses.
- deceptionatd 8mo agoTIL, I always thought IP:ASN mappings were 1:1.
- _bernd 8mo agoWith cloud providers and such the wording could also be "bring your own address".
- garciasn 8mo agoCould it be because folks set it low for initial propagation and then never change it back after they set it up.
- fukawi2 8mo agoThat'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 8mo agoI 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.
- bigstrat2003 8mo agoTechnically the initial propagation does depend somewhat on TTL. If you query the server and get the response that the record doesn't exist, that negative response gets cached too (based on the TTL of the SOA record). But it's pretty unusual for that to matter if you're standing up a new server.
- deceptionatd 8mo agoMaybe, 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.
- 8mo ago
- deceptionatd 8mo agoI 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 8mo agoI 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?
- viraptor 8mo agoFor a private server with not many users this is mostly irrelevant. Use low ttl if you want to, since you're putting basically 0 load on the DNS system. > such that all online caches get updated There's no such thing. Apart from millions of dedicated caching servers, each end device will have it's own cache. You can't invalidate DNS entries at that scope.
- 1970-01-01 8mo ago(2019)
- zamadatix 8mo agoDiscussed in 2022 (106 comments) https://news.ycombinator.com/item?id=33527642 https://news.ycombinator.com/item?id=33527642 And a similar version of the same blog post on a personal blog in 2019 https://news.ycombinator.com/item?id=21436448 https://news.ycombinator.com/item?id=21436448 (thanks to ChrisArchitect for noting this in the only comment on a copy from 2024).
- tracker1 8mo agoI usually set mine to between an hour and a day, unless I'm planning to update/change them "soon" ... though I've been meaning to go from a /29 to /28 on my main server for a while, just been putting off switching all the domains/addresses over. Maybe this weekend I'll finally get the energy up to just do it.
- GuinansEyebrows 8mo agoi was taught this as a matter of professional courtesy in my first job working for an ISP that did DNS hosting and ran its own DNS servers (15+ years ago). if you have a cutover scheduled, lower the TTL at $cutover_time - $current_ttl. then bring the TTL back up within a day or two in order to minimize DNS chatter. simple! of course, as internet speeds increase and resources are cheaper to abuse, people lose sight of the downstream impacts of impatience and poor planning.
- effnorwood 8mo agoSometimes they need to be low if you use the values to send messages to people.
- zamadatix 8mo agoI used to get more excited about this but even when browsers don't do a DNS prefetch (or even a complete preload) the latency for lookups is usually still so low on the list of performance impacting design decisions that it is unlikely to ever outweigh even the slightest advantages (or be worth correcting misperceived advantages) until we all switch to writing really really REALLY optimized web solutions.
- gertop 8mo agoThe irony here is that news.ycombinator.com has a 1 second TTL. One DNS query per page load and they don't care, yay!
- a012 8mo agoJoke on them because I use NextDNS with caching so all TTL is 3600s
- jurschreuder 8mo agoIt's because updating dns does not work reliably so it's always a lot if trail and error which you can only see after the cache updates
- joelthelion 8mo agoCould you make your changes with a low TTL and switch to a longer one once you are satisfied with the results?
- throw20251220 8mo agoHow does that help you if you have to wait for long ttl to expire before the short one takes over?
- nubinetwork 8mo agoYou don't if you flush your cache... on linux, that usually means a reboot unless you run bind or dnsmasq and can just restart them.
- ece 8mo agoI've never changed the default, Squarespace, Godaddy, Cloudflare, Porkbun, all have been an hour or so.
- compumike 8mo agoThe big thing that articles like this miss completely is that we are no longer in the brief HTTP/1.0 era (1996) where every request is a new TCP connection (and therefore possibly a new DNS query). In the HTTP/1.1 (1997) or HTTP/2 era, the TCP connection is made once and then stays open (Connection: Keep-Alive) for multiple requests. This greatly reduces the number of DNS lookups per HTTP request. If the web server is configured for a sufficiently long Keep-Alive idle period, then this period is far more relevant than a short DNS TTL. If the server dies or disconnects in the middle of a Keep-Alive, the client/browser will open a new connection, and at this point, a short DNS TTL can make sense. (I have not investigated how this works with QUIC HTTP/3 over UDP: how often does the client/browser do a DNS lookup? But my suspicion is that it also does a DNS query only on the initial connection and then sends UDP packets to the same resolved IP address for the life of that connection, and so it behaves exactly like the TCP Keep-Alive case.)
- hannasm 8mo ago> patched an Encrypted DNS Server to store the original TTL of a response, defined as the minimum TTL of its records, for each incoming query The article seems to be based on capturing live dns data from some real network. While it may be true that persistent connections help reduce ttl it certainly seems like the article is accounting for that unless their network is only using http1.0 for some reason. I agree that low TTL could help during an outage if you actually wanted to move your workload somewhere else, and I didn't see it mentioned in the article, but I've never actually seen this done in my experience, setting TTL extremely low for some sort of extreme DR scenario smells like an anti pattern to me. Consider the counterpoint, having high TTL can prevent your service going down if the dns server crashes or loses connectivity.