发布于

乐观 DNS 缓存那些事

本文主要内容包括乐观 DNS 缓存的介绍，现网使用中的优缺点，国内部分递归 DNS（不包含境外 DNS） 的使用情况数据，及如何规避乐观 DNS 等内容。

  • 约60%的运营商递归 DNS 开启了乐观 DNS

乐观 DNS 缓存介绍

乐观 DNS 缓存（Optimistic DNS、RFC8767:Serving Stale Data to Improve DNS Resiliency等，本文后续以乐观 DNS 代替），简单的说就是在客户端向递归 DNS 发起一个域名的 DNS 查询请求时，如果递归 DNS 缓存中的记录已经过期（缓存时间超过了 TTL 时间）时，还是会应答该过期记录的行为。

【注意:】准确的说目前运营商的递归 DNS、南京信风公共 DNS（114.114.114.114）和阿里云公共 DNS（223.5.5.5）等使用过期缓存应答行为与 RFC8764 中乐观 DNS 的行为是冲突的，并不是真正的乐观 DNS 缓存，但此处也先以乐观 DNS 称呼。

  • RFC8767 中的对乐观 DNS 行为的是只有权威 DNS 解析失败时， 比如DDoS 攻击、网络等其他原因导致的超时、REFUSE等错误时才向客户端应答过期的缓存记录数据，而目前部分国内支持乐观 DNS 行为的递归 DNS 则不关注权威应答成功或失败，直接给客户端应答缓存中的过期记录，再去异步向权威查询。
    • 使用过期缓存应答的客户端查询超时时间在标准 RFC 中建议为 1.8 秒，但从个人的经验看，这个值在现网环境中明显有点高了，可以考虑酌情降低，个人建议低于 400 ms
  • 最大过期时间（A maximum stale timer）即 TTL 过期多长时间内可以继续应答过期的记录，RFC 的建议是 1 – 3 天，而目前部分国内递归 DNS 在实践中该时间是无限的。

乐观 DNS 的优点

乐观 DNS 对终端用户的使用体验以及递归 DNS 服务提供商有一些好处，主要包括以下方面：

  • 在缓存的记录 TTL 过期后降低客户端的 DNS 解析时延，尤其是请求量不是很大的冷域名没有了冷启动过程，因为省却了同步的向各级权威 DNS (包括根 DNS, TLD DNS, zone 域名 DNS等 ) 递归（迭代） DNS 查询的过程。
    • 此处主要是部分国内非标准实现的乐观 DNS 的优点。
    • 运营商递归 DNS 或云厂商等公共 DNS 中普遍使用缓存和递归分离的多级架构中，此方式工程实现上更为简单，缓存层可以无需保存递归过程中的客户端连接状态信息。
  • 当权威 DNS (包括根 DNS, TLD DNS, zone 域名 DNS等 ) 遭受 DDoS 攻击或其他故障无法响应递归 DNS 的查询时，不影响客户端获取请求域名的记录，虽然 TTL 已经过期，但是比解析失败更好一些（”stale bread is better than no bread.”）。
    • 此处可以减少递归 DNS 提供商的收到的无法解析等情况问题反馈、咨询工单等。
    • 降低递归 DNS 的成本，包括网络带宽和计算资源成本等，权威失败时仅间隔性的重试到权威的请求。

乐观 DNS 的缺点

如果按照标准的 RFC8767 去实现乐观 DNS，这里其实并没有什么显著的缺点，因为只有在权威 DNS 不可用或不稳定时才会触发该功能，虽然可能会有一些解析错误的情况出现，但至少不会使情况变得更糟。

乐观 DNS 更多的缺点来自目前部分递归 DNS 的非标实现，主要包括以下方面：

  • 过期的解析记录在递归 DNS 缓存中可能长期（数小时、数天、甚至数月）无法刷新，还可能解析到旧的记录，尤其是对平时解析量不大的冷域名，此时过期的记录很可能早已无法访问。
    • 尤其是最大过期时间（A maximum stale timer）设置为无限时，而不是标准建议的 1-3 天或自行稍微斟酌修改的时间。
    • 此处会增加递归 DNS 提供商的收到的解析错误等情况问题反馈、咨询工单等，具体最终工单量增加还是减少需视客户业务和网络等情况单独去看。
  • 对需要频繁切换记录的域名不友好，如全局负载均衡或 CDN 调度等。
    • 如果域名的 DNS 查询请求量足够大，则可以减轻该影响。

个人观点

  • 基本支持标准 RFC 的乐观 DNS 行为。
  • 强烈反对部分递归 DNS 的乐观 DNS 的非标实现，见之前乐观 DNS 介绍中的注意事项，降低解析时延不能以解析到错误甚至不可用的 IP 为代价。
  • 使用开源软件等自建自用递归 DNS 的场景，根据个人需求自行设置缓存规则即可。

国内乐观 DNS 测试

测试范围及方法

  • 测试范围：境内 31 个省份三大运营商（电信、联通、移动）共 93 个测试目标，及部分公共 DNS （119.29.29.29,114.114.114.114,223.5.5.5）共 3 个测试目标。
  • 测试的大体步骤如下所示，该测试过程会重复测试多次：
    • 步骤1，首先设置测试域名opt.test.example.com的 A 记录为1.1.1.1，并设置 TTL 为 600 秒。
      • 此处的测试域名和测试 IP 都非真实的测试域名和测试 IP，仅为说明测试过程。
    • 步骤2， 通过遍布全国的测试客户端（IDC 及 LastMile）请求测试域名，其中包括直接指定目标递归 DNS 进行解析（IDC）和 http 请求中包含的 DNS 解析（LastMile）。
      • 本过程的目的使客户端使用的递归 DNS 都解析并缓存过opt.test.example.com的 A 记录为1.1.1.1
    • 步骤3，等待步骤2的全部测试全部结束后，修改测试域名opt.test.example.com的 A 记录为2.2.2.2，并设置 TTL 为 600 秒。
    • 步骤4，等待不小于 1 小时（数倍 600 秒的 TTL ）后，确保递归 DNS 缓存记录的 TTL 已经过期。
    • 步骤5，重复步骤2，通过全国各地的测试客户端重新请求测试域名。
      • 此处绝大部分测试客户端已经排除了客户端本地 DNS 缓存的影响，尽量直接向本地设置的递归 DNS 进行请求。
    • 步骤6，过滤掉干扰 DNS（如 LastMile 的路由器的内网 IP段等），仅保留本地运营商实际的递归 DNS 和目标公共 DNS 的数据记录进行统计，如果仍然存在会解析到已经过期的旧 IP 1.1.1.1,则认为该递归 DNS 开启了乐观 DNS，如果所有记录都为新的 IP2.2.2.2,则认为该递归 DNS 未开启乐观 DNS。
      • 为减少偶然情况的影响，以上测试步骤会执行多次。

测试数据

从目前目前国内的主流的递归 DNS 测试数据看，过半数（约60%左右）已经开启了乐观 DNS，本文仅列出测试数据，不详细点评。

公共 DNS 乐观 DNS 开启情况

本次测试了三家公共 DNS，119.29.29.29,114.114.114.114和223.5.5.5，其中119.29.29.29未开启乐观 DNS，114.114.114.114和223.5.5.5则开启了乐观 DNS。

运营商递归 DNS（LocalDNS/LDNS）乐观 DNS 开启情况

运营商递归 DNS 开启了乐观 DNS 的总体比列大约在 60% 左右，以下为详细数据

  • 该数据仅代表本次测试的统计情况。
IDC + LastMile 测试数据
  • 在所有的 93 个测试目标中共有 57 个测试目标测试到开启了乐观 DNS，占比 57 / 93 = 61.29%
  • 电信 15 个测试目标开启了乐观 DNS，占比 15 / 31 = 48.39%
  • 联通 25 个测试目标开启了乐观 DNS，占比 25 / 31 = 80.65%
  • 移动 17 个测试目标开启了乐观 DNS，占比 17 / 31 = 54.84%
IDC测试数据

虽然在 LastMile 的测试中，已经尽量规避了客户端本地 DNS 缓存的影响，但是我们仍不能保证一定未使用客户端本地缓存，所以单独列出 IDC 的测试数据。

在所有的 93 个测试目标我们通过各种渠道搜集到 81 个对应的 IDC 客户端，可以完全排除本地 DNS 缓存的影响，数据如下：

  • 共 47 个测试目标开启了乐观 DNS，占比 47 / 81 = 58.02%
  • 电信共测试了 27 个测试目标，其中 11 个测试目标开启了乐观 DNS，占比 11 / 27 = 40.74%
  • 联通共测试了 28 个测试目标，其中 22 个测试目标开启了乐观 DNS，占比 22 / 28 = 78.57%
  • 移动共测试了 28 个测试目标，其中 14 个测试目标开启了乐观 DNS，占比 14 / 28 = 50.00%

如何规避乐观DNS

如果业务域名的请求量较大，可以较快的触发递归 DNS 快速刷新到新的记录，那么乐观 DNS 可以微弱的降低解析时延，目前没有看到太明显的缺点，正常使用各递归 DNS 即可。

  • 请求量大的热域名，则缓存命中率高，总体时延降低有限。

然而在很多实际的业务中，对切换实时性要求比较高，但是访问量又没有那么大的中小域名，目前如此高比例非标准实现的乐观 DNS肯定会对业务存在一定的影响，此时就需要一些其他技术手段来对乐观 DNS 进行规避，下面介绍一些方法，其中部分方法比较常见，外网已经有很多的公开信息可以查询参考，此处就不展开详细介绍。

提前修改解析记录/保留旧IP一段时间

  • 如果是有规划的切换 IP 时，也可以考虑预留几天（如3天）的缓冲期，这段时间内新旧 IP 都保持可用，来降低 LocalDNS 会返回过期 IP 造成的影响。
    • 类似于修改域名的 NS，需要留几天的缓冲期保持新旧NS的记录都可用并同步更新
    • 不适用于临时或频繁的切换 IP
    • 即使保留 3 天的缓存，也不能保证完全刷新掉旧的IP
    • 感谢 @changlinli 提供

可以使用未开启乐观 DNS 的公共 DNS 来规避乐观 DNS，目前国内腾讯云 DNSPod 的公共 DNS 等是未开启乐观 DNS 可供选用。不同的使用方式有不同的接入方法，更多信息可以参考这里。

使用未开启乐观 DNS 的 公共DNS

通用的公共 DNS

  • 需要修改 WIFI/路由器 等使用的 DNS IP，有一定使用门槛，且普通 DNS 请求容易被劫持。

DoH/DoT(DoQ)

  • 需要较高的 PC 操作系统版本/浏览器/手机 OS（主流IOS/Android均支持）等支持，并进行配置，也有一定的使用门槛。

HttpDNS/HttpsDNS

近年来的常规方式，在各大 APP 中广泛使用，更多 HttpDNS 的介绍。

  • 优点：可以指定 HttpDNS 服务器，绕开 LocalDNS，DNS 控制自由度较高，且有丰富的统计信息查看等，即使在 HttpDNS 故障时，也可以降级回本地 LocalDNS
  • 缺点：使用场景受限，主要是在移动端 APP、PC 客户端等有端场景，其他的浏览器等场景使用受限；有改造接入门槛；请求次数收费等使用成本较高。

刷新递归 DNS 缓存

联系运营商主动刷新缓存

部分运营商（如天翼云域名无忧）提供了递归 DNS 缓存刷新接口，但是也存在比较多的问题价格很贵，使用不便等问题。

  • 价格很贵：三大运营商的缓存刷新服务一般为数千元/次，可以刷新某域名在本运营商所有省份的递归 DNS 缓存，如重大业务重大故障的切换需要刷新可以考虑使用，但是如果普通的切换也使用的话则明显成本太高。
  • 使用不便：一般需要单独联系各个渠道去购买或使用该功能，缺少一键全量刷新的手段。
  • 覆盖不全：除了三大运营商外，其他中小运营商和公共 DNS 很少提供公开的缓存刷新服务。

通过拨测客户端被动刷新缓存

通过各种不同的客户端或拨测工具，大量请求目标域名，触发对应的递归 DNS 被动的刷新缓存。

  • 公开免费的拨测工具对各种递归 DNS 的覆盖度不够完整。
  • 使用商业拨测工具大量拨测的价格也不低。