乐观 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 的覆盖度不够完整。
  • 使用商业拨测工具大量拨测的价格也不低。