系统与基础设施00f.net
别再使用过低的 DNS TTL
Stop using low DNS TTLs
2019 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者主张不要使用过低的 DNS TTL（如 60 秒以下），指出低 TTL 会显著增加 DNS 查询量、拖慢解析，而现代浏览器和负载均衡技术已经能应对后端故障，无需依赖极短 TTL 来快速切换流量。文章引发了关于 TTL 实际遵守情况、隐私影响和运维实践的广泛讨论。
为什么经久不衰：DNS TTL 的取舍涉及性能、可靠性和隐私，而大量真实运维经验表明许多解析器根本不遵守 TTL，这些来自一线的洞见至今仍有参考价值。
HN 评论精选
现实中大量解析器和客户端无视 TTL，低 TTL 并不能保证快速切换流量
讽刺的是，对服务器运营者来说这些 TTL 几乎没有意义。即使你把 TTL 设为 5 分钟，也有大量客户端会无视它。我在 reddit 做 DNS 切换时，即便 TTL 是 5 分钟，80% 的流量花了一小时才迁移，一周后只迁移了 95%，两周后仍有 1% 流量指向旧 IP，一个月后旧端点还有流量（多半是硬编码 IP 的爬虫），最后我直接把它关了。我一位在阿拉斯加运营 ISP 的朋友说，他们干脆无视所有 TTL、统一缓存 7 天，因为带宽不够支撑对外的 DNS 查询。所以把 TTL 设成 40 小时吧，反正也没用。紧急情况下你需要 DNS 之外的手段来快速切换流量，比如可改路由配置的 IP。
jedberg查看英文原文
The irony of all of this is that those TTLs are almost meaningless as a server operator anyway. Even if you set your TTL to 5 minutes, there are a whole lot of clients that will ignore it. When I made a DNS switch at reddit, even with a 5 minute TTL, it still took an hour for 80% of the traffic to shift. After a week, only 95% had shifted. After two weeks we still had 1% of traffic going to the old IP. And after a month there was still some traffic at the old endpoint. At some point I just shut off the old endpoint with active traffic (mostly scrapers with hard coded IPs at that point as far as I could tell). One of my friends who ran an ISP in Alaska told me that they would ignore all TTLs and set them all to 7 days because they didn't have enough bandwidth to make all the DNS queries to the lower 48. So yeah, set your TTL to 40 hours. It won't matter anyway. In an emergency, you'll need something other than DNS to rapidly shift your traffic (like a routed IP where you can change the router configs).
一线域名服务商的实践：默认 1 小时，变更前临时降低，但担心过低 TTL 触发解析器异常行为
我为近一万个域名运营权威域名服务器。最初按 RIPE-203 建议使用 2 天的默认 TTL，但用户不接受要等两天，于是除 SOA 和 NS 记录外我把默认 TTL 改为 1 小时；如有计划的变更则临时降到 5 分钟。我不想再低了，因为听说有故障的解析器会把“过低”的 TTL 视为异常而回退到某个很高的默认 TTL，从而毁掉精心规划的 DNS 切换。但我没见过关于“多低算过低”的真实数据或可靠参考，希望有人能提供信息。
teddyh查看英文原文
I operate authoritative name servers for almost 10.000 domains. Originally, I used a default TTL of 2 days, as recommended by RIPE-203¹ (which is also compatible with the recommendations of RFC 1912²), but this was not accepted by users, who didn’t want to wait two days. Therefore, for all records except SOA and NS records, I changed the default TTL to one hour, which I still use as the default value unless a change is scheduled and/or planned, in which case I lower it to 5 minutes. I do not want to lower it any more, as I’ve heard rumors of buggy resolvers interpreting “too low” TTLs as bad, and reverting to some very-high default TTL, and thereby wrecking my carefully planned DNS changeover. I have, however, not seen any real numbers or good references on what numbers are “too low”, and would like to hear from anyone who might have some information on this. 1. https://www.ripe.net/publications/docs/ripe-203 2. https://tools.ietf.org/html/rfc1912#page-4
低 TTL 的一个隐秘动因是隐私代价：明文 DNS 的高频查询可被用来刻画用户行为
作者似乎漏掉了人们使用极低 TTL 的一大原因：这让被动窃听者能大致还原你的浏览历史。HTTP 流量大多已转向 HTTPS，但 DNS 仍是明文。低 TTL 意味着每次点击链接几乎都会触发新的 DNS 请求，观察某人每 60 秒（甚至更短）在查询哪些域名，足以刻画出非常详细的生活模式。而且每次点击往往不止一个域名，加载 js/css/images 等的一组域名足以指纹化特定活动。TTL 需要更合理的下限，更重要的是转向加密协议。可惜 DoH 解决不了这个问题，只是把被动窃听问题转移给了上游（如 Cloudflare）；真正的方案是允许所有人本地做递归解析的加密协议。
pdkl95查看英文原文
> Why are DNS records set with such low TTLs? The author seem to be missing one of the big reasons ridiculously low TTLs are used: it lets passive eavesdroppers discover a good approximation of your browsing history. Passive logging of HTTP has (fortunately) been hindered as most traffic moved to HTTPS, but DNS is still plaintext. Low TTLs mean a new DNS request happens (apx) every time someone clicks a link. Seeing which domain names someone is interacting with every 60s (or less!) is enough to build a very detailed pattern-of-life[1]. Remember, it's probably not just one domain name per click; the set of domain names that are requested to fetch the js/css/images/etc for each page can easily fingerprint specific activities within a domain. Yes, TTLs need to have some kind of saner minimum. Even more important is moving to an encrypted protocol. Unfortunately DOH doesn't solve this problem[2]; it just moves the passive eavesdropping problem to a different upstream server (e.g. Cloudflare). The real solution is an encrypted protocol that allows everyone to do the recursive resolution locally[3]. [1] https://en.wikipedia.org/wiki/Pattern-of-life_analysis [2] https://news.ycombinator.com/item?id=21110296 [3] https://news.ycombinator.com/item?id=21348328
15–30 分钟是兼顾变更灵活性与稳定性的合理 TTL 区间
面向客户的 DNS 的 TTL 应在 15 到 30 分钟量级。折半估算用户侧实际缓存时间，即 7 到 15 分钟，这对大多数网页交互来说差不多正合适。再长就会遇到运营者难以保持 DNS 准确的各种麻烦——DNS 很难搞，很容易弄坏——而 15 到 30 分钟大致是“好了，我们改完了，DNS 生效了吗”这种问题所能维持的正常注意力时长。5 到 10 分钟的 TTL 只对运营者有利；任何低于 5 分钟的 TTL 都表明运营者对自己管理 DNS 的能力毫无信心。
xbar查看英文原文
Customer-facing DNS should have TTLs on the order of 15 to 30 minutes. Halving those values to estimate TTL value to the end user, you get 7 to 15 minutes of cached DNS. That's about right for most user interactions on the web. Much longer and you run into all the trouble that operators have with keeping DNS accurate. DNS is hard. It is easy to break. And 15 to 30 minutes of waiting is about as much normal human attention span you can apply to a problem that sounds like, "Ok, we're all done, is DNS ok?" 5 to 10 minute TTLs only benefit operators. Certainly, any TTL less than 5 minutes is an indicator that your operators have no faith whatsoever in their ability to manage DNS.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选