了解 DNS 缓存

学渣出品，技术 / 英文学习记录，难免会有了解 / 翻译瑕疵甚至谬误，欢送斧正。
倡议浏览原文: Understanding DNS cache

当我第一次学习 DNS 解析 时，我被这个漫长和简单的过程惊到了。设想一下你每天要拜访多少网站，再想一下你每天要拜访多少次。当初设想一下你每次拜访时，在另一端的 ISP DNS 服务器必须反复整个递归过程，并查问递归链中的所有域名服务器。

以此为背景，设想一下你的手机。当你想跟你一个定期分割的敌人通个电话时，你很容易在最近通话中找到他们的名字并拨打。然而，如果这些信息并没有筹备好，你就得打 114 来去获取他们的号码，而后手动拨出。看起来是不是很繁琐？

实际上将域名转化为 IP 地址 须要大量步骤，并且要耗费大量工夫。侥幸的是，DNS 的设计者思考到了如何减速 DNS，并实现了缓存。DNS 缓存使得 DNS Server 或者 客户端本地存储 DNS 记录并在当前复用，缩小了对新 DNS 申请的查问需要。

域名零碎为每一条 DNS 记录实现了存活工夫（TTL）。TTL 指定了一条 DNS 记录在 DNS 服务器和客户端能够被缓存的秒数。当缓存中存在该 DNS 记录时，也会保留其存活时长。服务器会继续更新缓存中的 TTL，以秒为单位倒计时。当它变为 0 时，该记录会从缓存中被删除或者革除。此时，如果缓存过期当前再次收到该记录的申请，DNS 服务器就必须启动解析流程。

要了解缓存，让咱们来看下上一篇文章中的例子，解析 www.google.com。当你在浏览器里输出 www.google.com 时，浏览器向操作系统询问 IP 地址。操作系统有 stub resolver 或者 DNS client (参考：什么是 DNS Server, resolver 以及 stub resolver)，一个操作系统响应所有 DNS 查问的解析器。DNS 解析器会发送 DNS 申请（并开启递归查问标记）给特定的递归解析器（域名服务器）并依据其 TTL 值存储其 DNS 记录到缓存。

当 Stub Resolver 收到一个应用程序的申请，它会先查看本人的缓存，如果缓存中有该记录，它会将缓存中的信息间接返回给应用程序。如果缓存中没有，则发送 DNS 申请（并开启递归标记）递归解析器（ISP 的 DNS 服务器）。

当 Recursive Resolver 收到申请，它会先查看缓存中有 www.google.com 的哪些信息。如果缓存中有 A 记录，则把记录发送给 Stub Server。如果没有 A 记录，然而有权威域名服务器的 NS 记录，它将会申请这些权威域名服务器（绕过根服务器和 com gTLD 服务器）。

如果没有权威域名服务器，它会申请 com gTLD 服务器。

graph TD;
google.com-->Browser;
Browser-->OS;
OS-->Stub-Resolver;
Stub-Resolver-->Cached;
Cached-->Browser;
Stub-Resolver-->Not-Cached;
Not-Cached-->ISP-DNS;
ISP-DNS-->Cached-A-Record;
Cached-A-Record-->Stub-Resolver;
ISP-DNS-->Not-Cached-A-Record;
Not-Cached-A-Record-->Cached-Auth-NS-Server;
Cached-Auth-NS-Server-->Query-Auth-NS-Server;
Query-Auth-NS-Server-->ISP-DNS;
Not-Cached-A-Record-->Not-Cached-Auth-NS-Server;
Not-Cached-Auth-NS-Server-->COM-GTLD-Server;
COM-GTLD-Server-->ISP-DNS;

注：图表为译者依据本人了解增加（欢送斧正）

如果没有权威名称服务器，就会申请 .com gTLD 服务器（因为他们 TTL 十分高，他们个别是存在于缓存中，并且他们实用于任意 .com 域名）。只有当他们不存在于缓存时，Recursive Resolver 才会向根服务器申请 gTLDs，这种状况十分少见（通常是指行了 purge 操作）。

为了防止流传过期 DNS 记录，DNS 服务器将会通过改正一个申请的 TTL，而不是这条记录原始 TTL 值。例如，假如 一条 www.google.com 记录的 TTL 是 4 个小时，并且它在上午 8 点被 Recursive Resolver 保留于缓存中。如果有一个新用户，在这个解析器，在上午 9 点申请雷同的域名，resolver 将会发送一个 3 个小时的 TTL 记录。

当初咱们曾经笼罩了 DNS 在 OS 和 DNS 服务器的缓存，而后就剩下最初一层缓存：应用程序。所有利用都能够抉择缓存 DNS 数据，即便他们不能遵循 DNS 规范。利用依赖操作系统函数 getaddrinfo() 来解析域名（所有操作系统都是用雷同的函数名）。该函数返回域名的 IP 地址列表 – 然而他不返回 DNS 记录，所以应用程序没有 TTL 可用。

所以，不同的应用程序缓存数据工夫不同。IE10+ 将在其缓存中存储最多 256 个域名，固定工夫为 30 分钟。256 个域名看起来如同很多，实际上不是的 – 网络上大量网页都会饮用 50 个域名以上，多亏第三方标记和重定向。另一方面，Chrome 将缓存 DNS 信息一分钟，并且存储 1000 条记录。你能够通过拜访 chrome://net-internals#dns 查看和清理 Chrome 的 DNS 缓存。

NS 缓存陷阱

人们会常常掉入一个的 DNS 缓存陷阱是权威名称服务器记录。就像咱们之前提到的，权威名称服务器在申请响应中作为 NS 记录被指定。NS 记录有 TTL。但并不提供名称服务器的 IP 地址。IP 信息在额定的 A 或者 AAAA 记录响应里。

因而，一个 Recursive Resolver 同时依赖于 NS 和 A 记录来到达名称服务器。现实状况下，两种记录类型的 TTL 应该雷同，然而偶然有人谬误配置 DNS zones，他们会在 DNS 申请传入新的 A 或者 AAAA 记录。新记录笼罩老记录，导致产生差别。

当所有的记录都在缓存里，Recursive Resolver 将会申请其中一台域名服务器的 IP 地址。如果 Recursive Resolver 缓存中只有 NS 记录，没有 A 或者 AAAA 记录，它就必须解析 名称服务器域名，比方 ns1.google.com，获取其 IP 地址。这样并不好，因为它减少了解析域的工夫。并且，如果它有域名服务器的 A 或者 AAAA 记录然而没有 NS 记录，它会强制发动一个 域名 www.google.com 的 DNS 查问。

设置 TTL: 均衡行为

那么，TTL 工夫长一些还是短一些会更好的呢？适合的的状况下，应用一个更长的 TTL，因为它会使 resolvers 缓存更久并且 OSS — 意味着对终端用户而言意味着更好的性能，以及它会缩小到你名称服务器的流量，因为申请会更少。无论如何，它也会缩小你的变更 DNS，使你更容易因为蒙受 DNS 劫持攻打，并在你的数据中心不可拜访时无奈设置离线谬误页面。

换句话说，TTL 越短人们就越会花工夫在下载页面或资源，并减少你名称服务器的压力。并且使你更快的变更 DNS 配置。

DNS 解析是一个多阶段的由互联网大量服务器参加的过程。协定内建的缓存机制通过缓存并复用信息减速了将来 DNS 申请的过程。DNS 服务器 和 / 或 客户端在 TTL 上遵循该 DNS 标准，然而像浏览器这样的应用程序不遵循该标准 – 因而他们的缓存能够保留任意工夫。