DNS 查询与缓存
复习
- DNS 的名字空间：域名是一棵分层管理的树
- 套接字：应用通过套接字收发数据
- 端口：DNS 常用 53 号端口
TL;DR
- 解析器代表应用去查询域名对应的地址
- 查询会沿域名树逐级进行：根、顶级域、权威服务器
- 缓存让重复查询不必每次从头来
- TTL 决定一条解析结果能被缓存多久
正文
知道了域名是一棵树，那具体怎么“找到答案”？
一层层问过去
当你访问一个新域名时，背后大致会经历这样的过程：
- 先看看本地有没有缓存的答案，有就直接用
- 没有，就交给递归解析器（通常由网络服务商提供）
- 解析器从根开始问：“
.com该找谁？” - 根告诉它
.com的服务器地址，它再去问.com：“example.com该找谁？” .com再指向example.com的权威服务器- 权威服务器终于给出这个域名对应的 IP 地址
一路像问路一样，从一个知道一部分的节点，问到下一个更了解情况的节点，直到拿到最终答案。
缓存：别每次都从头问
如果每次都从根问起，网络负担会非常重。所以 DNS 大量使用缓存：
- 浏览器缓存
- 操作系统缓存
- 递归解析器的缓存
一旦某个域名被解析过，结果就会被存下来。下次再有人问，直接返回缓存，不必再跑一趟完整的查询。这正是“时间局部性”在 DNS 上的体现：刚问过的域名，很可能马上又被问。
TTL：缓存能留多久
缓存不能永远留着，否则服务器换了地址，用户还按旧地址访问就会失败。所以每条解析结果都带一个 TTL（生存时间），规定它能被缓存多久。
- TTL 太长：减少了查询、更快，但服务器变更后，旧结果可能长时间不更新
- TTL 太短：更新及时，但查询频繁、负载变大
又是一个熟悉的权衡：新鲜度与效率之间，总要取一个平衡。
有了地址，应用就可以真正去“取东西”了。网络世界里最常见的应用协议，就是 HTTP。
思考题 1
DNS 缓存为什么能显著加快后续访问？
思考题 2
TTL 设置得太长或太短，各有什么利弊？
小结
知识点
- 解析器代表应用逐级查询域名
- 查询沿域名树从根到权威服务器推进
- 多级缓存避免重复查询
- TTL 决定解析结果的缓存时长
参考资料
- Wikipedia(zh)：域名系统：解析过程与缓存机制
- Wikipedia(zh)：生存时间：DNS 记录的缓存有效期
思考题答案（仅供参考）
思考题 1
因为解析结果可以在浏览器、操作系统和递归解析器等多处缓存。同一个域名再次被访问时，往往直接命中缓存，省去了从根逐级查询的往返过程，延迟大幅降低，也减轻了 DNS 系统的负载。
思考题 2
TTL 太长，能减少查询、提升性能，但服务器地址变更后旧记录会长时间残留，可能导致访问失败；TTL 太短，更新及时，却会让查询更频繁、整体负载更大。需要根据记录的稳定程度来取舍。
协议
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
封面图
设计师 | 南国微雪