DNS缓存与TTL策略

可视化演示

通过DNS多级缓存层级查询（浏览器→OS→本地→根→TLD→权威）、TTL值权衡（命中率vs传播时间）与故障切换（主节点宕机→TTL过期→备用切换）三个模式，展示DNS缓存与TTL策略的核心机制。

缓存基本概念：手机里的通讯录

上回说到，你第二次去老王烧烤，靠手机通讯录里的地址就能到。但仔细想想，这个“地址”其实不止存在你手机里——你记性不好，先翻手机备忘录；没记，再查通讯录；还没有，才打电话问总台客服。DNS 也是层层设卡：浏览器缓存、操作系统缓存、递归解析器缓存，最后才轮到权威服务器。每一层都是一本“通讯录”，谁先查到谁答复。

这些层并不神秘。你在电脑上访问一个网站，浏览器先看自己记没记过这个域名；没记，问操作系统；还没记，转发给运营商或云厂商的递归解析器；递归解析器如果也没有，才向全球的权威服务器要“官方答案”。所谓“缓存命中”，就是某一层直接翻到了通讯录条目，省掉了后面的漫长问路。

每个解析器都维护一张表，记录域名与 IP 的对应关系。命中与否直接影响体验：命中的延迟通常在几毫秒，而完整递归解析可能需要几十甚至上百毫秒。衡量缓存价值的关键指标就是命中率，它决定你的“通讯录”到底好用不好用。

层数越多，可以命中的“通讯录”就越多，但每本通讯录都有存旧地址的风险——于是有了 TTL 这个有效期标签，控制每层能“信多久”。下一节我们就来看这张便签是怎么倒计时的。

TTL工作机制：地址便签上的有效期

老王烧烤每张发出去的地址便签右上角，都印着“此地址有效至 14:30”。在你手机里躺着这段时间，你都不用重新问路；一过 14:30 便签作废，你再去就得重新问一次。这张便签的“有效期”就是 TTL——每个 DNS 记录上都有这么个数字，单位是秒。

TTL 由权威服务器的管理员设定。当你拿到一条 A 记录，它自带“存活时间”。缓存在本地后，解析器开始倒计时，时间归零就删掉这条记录，下次有查询时重新去找权威服务器拿新地址。所以 TTL 本质上回答了三个问题：这条记录能信多久？什么时候必须重新验证？别人改地址后，最迟多久能被你知道？

技术细节上，缓存条目里通常保存“写入时刻”，每次查询时用当前时间减去写入时刻，与 TTL 比较。过期就删除，绝不续期——这也是为什么 TTL 被称为“缓存一致性”的守门员。它不关心内容本身，只关心“这条信息还能不能继续用”。

现在你明白了：TTL 是写死的一张期限，解析器只是机械地倒计时。但问题是，这张期限印多长才合适？这就引出了工程里最常见的权衡题。

TTL权衡取舍：保质期长与短的博弈

老王烧烤的地址便签，印得时间长短各有讲究。印 24 小时？客人今天不用再问路，但明天老王搬到街对面，便签还在指着老地址；印 10 分钟？再稳准也不怕，可每个人每 10 分钟都要给总台打一次电话，总台电话直接被轰炸。

工程里的权衡一模一样。记录 TTL 设得长，缓存命中率高、权威服务器负载低、用户平均延迟好看——代价是变更传播慢；设得短，故障切换和 IP 调整能被快速感知——代价是查询量上升、权威压力变大、抖动被放大。

怎么选？经验法则是“动态记录短一点，静态记录长一点”。例如 API 网关、调度域名用 30~300 秒；图片、静态资源这类很少变的域名用 3600~86400 秒。变更前还会先调低 TTL，“预热”整个缓存链，再实施切换，避免一刀切后在切换瞬间造成全网查询风暴。

所以别问“TTL 最佳值是多少”，要问“老王多久可能搬家、客人多久问一次路”——场景决定答案。可别忘了，还有一种缓存连“不存在”都要记，那就是负缓存。

负缓存机制：不存在也是一种情报

有天你路过老王烧烤原址，发现店没了，问总台，客服说“该店已关闭”。你会把“这家店不存在”也记在脑子里，至少这周不再特意跑一趟。DNS 也一样：查询一个不存在的域名，权威返回 NXDOMAIN，而这个“不存在”也可以被缓存——这就是负缓存。

没有负缓存时，攻击者或误配置的客户端反复查询不存在的域名，每次请求都会穿透各级缓存，直达权威服务器，造成资源消耗甚至 DDoS 放大。有了负缓存，递归解析器在一段时间内直接回答“没有”，上游压力骤减，恶意查询的放大效应被拦在门外。

负缓存能存多久由权威服务器的 SOA 记录决定。RFC 2308 给出了计算规则：取 SOA MINIMUM 字段与 SOA 记录自身 TTL 中较小的一个。设太短，防不住反复轰炸；设太长，域名恢复上线后，别人要等很久才能“发现它又活了”。

“不存在”也是宝贵的情报，记下来，既省力气又防轰炸。但真正考验 TTL 功力的时候，是老王真的搬家那一刻——故障切换。

故障切换策略：搬家前的告示

老王烧烤真的搬家了，搬到街对面。问题是，每位客人手机通讯录里都留着旧地址，纸条上还印着“24 小时有效”。整整一天，客人络绎不绝地扑空。老王吸取教训，每到要搬家，就提前在门口贴出“地址有效期仅 10 分钟”的告示。

线上服务故障切换完全同理。当你把流量从故障的 IP-A 切到 IP-B，凡是缓存了“域名→IP-A”的解析器，都要等 TTL 倒计时结束才会重新查询。TTL 越大，“扑空”的时间越久。所以在计划变更前，工程团队会先调低 TTL，等整个缓存链“冷却”，再执行切换。

成熟的切换流程是：提前数小时把 TTL 从 3600 调到 60；等待至少一个原 TTL 周期让旧缓存自然过期；执行 IP 切换；监控观察稳定；再把 TTL 调回正常值。多 IP 场景下，健康检查会自动把故障 IP 从 A 记录里摘除，但摘除的“见效速度”同样由 TTL 决定。

把 TTL 当成运维的“刹车灯”——变更前一脚点刹，切换后才能稳稳停下，而不是让全员追尾。老王的故事还没完，他后来开了全国分店，这时候调度又成了新难题。

全球加速配置：就近吃烧烤

老王烧烤做大了，全国开了分店。顾客打电话问总台“老王烧烤在哪”，总台不会只报总店地址，而是看你在北京就报北京分店，在杭州就报杭州分店。这就是全局负载均衡，而 DNS 的响应就是那台“总台电话”。

CDN 和 GSLB 依赖 DNS 做就近调度：权威服务器根据解析器查询的地理位置或网络位置，返回离用户最近的节点 IP。可是如果这条记录 TTL 太长，用户长时间“钉”在旧节点上，新增节点、节点故障都难以及时反映，就像你明明搬到杭州，通讯录还记着北京分店。

因此 CDN 场景的 TTL 通常是分钟级（60~600 秒），在“少问路”和“调度及时”之间取折中。有些 CDN 甚至用很短的 TTL 配合 ECS 高频精确调度。工程上还会结合 TTL 与监控缓存命中率动态调整，让“就近”真正意义上贴着网络拓扑走。

想清楚“分店在哪、客人多远”，你才能定下让大家都少跑路的有效期。但总台还有个尴尬：它只知道你的电话号码归属地，不知道你此刻人在哪——ECS 就是来解决这个的。

ECS精准调度：告诉总台你在哪

总台电话还有个难题：你的手机号归属地是北京，但你现在人在上海出差，总台按号码归属地推了北京分店——跑错地方了。于是你得多说一句“我人在上海”，总台才报上海分店。DNS 里的这句话就是 ECS（EDNS Client Subnet）。

传统 DNS 查询到达权威服务器时，权威只能看到递归解析器的 IP，无法精确到每个用户。ECS 在请求里额外携带客户端 IP 前缀，让权威/CDN 能做更精细的地域调度。代价是：缓存键从“域名”变成“域名+子网”，缓存被拆分，命中率下降；同时客户端 IP 前缀的暴露带来隐私考量。

工程实践中，ECS 一般按 /24 前缀携带，只对需要地域精细调度的域名启用，并在权威侧控制缓存分组大小。打开 ECS 后要重点监控权威服务器的缓存条目数和解析成功率，防止缓存碎片化拖垮性能。安全团队还要评估 IP 前缀暴露面，必要时做匿名截断。

告诉总台“你在哪”能吃到最近的分店，但也因此让总台要记更多小纸条——精准和成本永远是配对的。从缓存到 TTL，从负缓存到 ECS，老王烧烤的故事其实就是整个 DNS 工程哲学：一切都在为“让用户少跑路”和“让信息不落伍”之间找到那个刚刚好的平衡点。

AI 应用场景

Python 演示

import time class TTLDNSCache:    def __init__(self):        self.records = {}        self.negative = {}        self.hits = 0        self.queries = 0     def lookup(self, domain, authoritative, ttl, neg_ttl):        now = time.time()        self.queries += 1         if domain in self.records:            ip, expire = self.records[domain]            if now < expire:                self.hits += 1                return ip            del self.records[domain]         if domain in self.negative:            expire = self.negative[domain]            if now < expire:                self.hits += 1                return None            del self.negative[domain]         if domain in authoritative:            ip = authoritative[domain]            self.records[domain] = (ip, now + ttl)            return ip         self.negative[domain] = now + neg_ttl        return None  def simulate(authoritative, ttl, seconds=600, step=3):    cache = TTLDNSCache()    t = 0.0    domains = list(authoritative.keys()) + ["ghost.shop.com"]    while t < seconds:        for d in domains:            cache.lookup(d, authoritative, ttl, neg_ttl=30)        t += step    return cache  def main():    records = {        "www.shop.com": "10.0.0.1",        "api.shop.com": "10.0.1.1"    }    for ttl in [60, 300, 3600]:        c = simulate(records, ttl)        print("TTL=%5ds 命中率=%5.1f%% 总查询=%d" % (            ttl, 100.0 * c.hits / c.queries, c.queries))  if __name__ == "__main__":    main()

1. class TTLDNSCache:定义一个迷你 DNS 缓存，内部维护正缓存 records 和负缓存 negative，就像手机里存地址便签和“这家店不存在”的备忘录。
2. if now < expire:检查记录是否仍在 TTL 有效期内，没过期就直接命中，省掉一次“问路”。
3. del self.records[domain]记录过期就删掉，下次查询会重新向权威请求，这是 TTL 倒计时的核心动作。
4. self.negative[domain] = now + neg_ttl查询不存在的域名时，把“不存在”也缓存一段时间，对应负缓存机制。
5. for ttl in [60, 300, 3600]:分别用短、中、长三种 TTL 跑同一段流量，对比输出结果。
6. 100.0 * c.hits / c.queries计算缓存命中率，能看到 TTL 越长、命中率越高的趋势。

常见误区

面试题