64、野外 DNS 解析器的 TTL 违规现象研究

野外 DNS 解析器的 TTL 违规现象研究

1. 引言

在网络服务中，服务运营商需要同步管理 DNS 记录及其安全信息。例如，电子邮件服务器可将其证书信息作为 DNS 记录（TLSA）发布，供发送方交叉检查证书。当更新凭据信息（如公钥）时，通常会提前发布更新的 DNS 记录，并等待至少一个 TTL（或两倍 TTL）时间，期望 DNS 解析器清除旧缓存。然而，DNS 客户端是否遵循此做法并不明确，解析器可能会缓存 DNS 响应超过其 TTL，这会对安全和性能产生负面影响。

测量 DNS TTL 违规情况具有挑战性，以往的方法存在难以复制、扩展以及主要关注公共 DNS 解析器等问题。本文探索了一种使用住宅代理服务 BrightData 检测 DNS 解析器 TTL 违规的替代方法。

2. 背景与相关工作

2.1 相关工作

过去有许多关于 DNS 解析器 TTL 违规的研究，采用了不同的数据集和方法：
- 2004 年，Pang 等人使用大型 CDN Akamai 的 DNS 日志测量 TTL 违规，发现 47% 的客户端使用过期 DNS 记录。
- 2013 年，Callahan 等人从 90 个家庭的住宅网络测量发现，13.7% 的用户连接使用过期 DNS 记录。
- Schomp 等人通过从 100 个 PlanetLab 节点向开放解析器发送 DNS 查询，发现 81% 的开放解析器不能始终返回正确的 TTL 值。
- 一些研究发现，小 TTL（如 20 秒）更容易出现 TTL 违规。
- 最近，RIPE 实验室使用 9119 个独特的 RIPE Atlas 探针报告称，4.1% 的测量解析器增加了 TTL 值，1.97% 的解析器降低了 TTL 值。

这些研究虽然识别了不同的 TTL 违规情况，但难以提供互联网上的整体 TTL 违规情况。

2.2 BrightData

BrightData 是一个住宅代理服务，以前称为 Luminati，是付费的 HTTP/S 代理服务，通过安装了 Hola Unblocker 的住宅节点（出口节点）路由流量。其工作流程如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    A(客户端):::process -->|HTTP 请求| B(超级代理):::process
    B -->|DNS 请求（健康检查）| C(DNS 服务器):::process
    B -->|转发请求| D(出口节点):::process
    D -->|DNS 请求| C
    D -->|获取 HTTP 响应| E(Web 服务器):::process
    D -->|转发响应| B
    B -->|返回响应| A

BrightData 提供了一些选项来控制出口节点：
- 出口节点偏好 ：客户端可通过在 HTTP 请求中添加 -country-XX （XX 为 ISO 国家代码）或 -asn-YY （YY 为 AS 编号）参数选择出口节点所在的国家或自治系统。还可添加 -session-XX （XX 为随机数）参数选择相同的出口节点，60 秒内使用相同会话号可选择同一节点。
- 出口节点持久性 ：客户端可从 HTTP 响应头 x-luminati-ip 中获取出口节点 IP 地址的哈希值。在 HTTP 请求中添加 -ip-XX （XX 为 IP 地址哈希值）选项，若节点可用，可使用同一出口节点，这有助于测量解析器的 TTL 违规行为。
- DNS 请求位置 ：默认情况下，DNS 解析在超级代理端完成并缓存。客户端可在 HTTP 请求中指定 dns-remote 选项，使 DNS 解析由出口节点使用其 DNS 服务器完成。

3. 野外 TTL 扩展情况

3.1 方法

测量和识别扩展 TTL 的解析器看似简单，但实际操作中，客户端可能使用多个具有多个上游解析器的 DNS 解析器，会收到多个 DNS 响应，且无法确定出口节点实际使用的响应，难以识别扩展 TTL 的解析器。

为解决这些问题，针对每个不同的解析器返回不同的 A 记录，通过监控 HTTP 请求的传入 IP 地址来确定出口节点使用的 DNS 解析器。具体实验步骤如下：
1. 第一阶段（P1） ：让出口节点获取唯一子域名 http://<<UID>>.m.com ，从 HTTP 响应头中提取 x-luminati-ip 值，以便在 TTL 过期后选择相同的出口节点。
2. 在权威名称服务器上，为每个查询相同 qname 的解析器选择一个未用于该 qname 的 IP 地址，动态生成 A 记录以响应请求。创建一个映射表，将 qname 和解析器 IP 地址的元组映射到服务的 IP 地址。若观察到同一 qname 的 DNS 解析器数量超过 N（本实验中 N = 8），则将该出口节点排除在进一步分析之外。
3. 从 Web 服务器检查 HTTP 请求的 IP 地址目的地，在映射表中找到匹配的 DNS 解析器 IP 地址，从而确定出口节点使用的 DNS 解析器。
4. 立即从 DNS 权威名称服务器撤回所有 DNS 条目，忽略后续 DNS 请求，等待 TTL 使缓存的 DNS 响应过期。
5. 第二阶段 ：TTL 过期后，设置权威名称服务器提供指向未分配给任何 DNS 解析器的 IP 地址（IPnew）的 A 记录。使用 -ip-XX 选项选择相同的节点，让其再次获取 http://<<UID>>.m.com 。

3.2 结果

在测量期间，共发送 2068686 个唯一的 HTTP 查询，由 274570 个唯一的出口节点及其 27131 个解析器在 220 个国家的 9514 个 AS 中提供服务。

使用五种不同的 TTL（1、5、15、30 和 60 分钟）进行实验，识别潜在的 TTL 扩展解析器相对简单，当观察到出口节点仍使用旧 IP 地址连接到 Web 服务器时，可通过查找映射表将其标记为潜在的 TTL 扩展解析器。但当出口节点使用新 IP 地址时，不能简单地将第二阶段的所有解析器标记为 TTL 遵守解析器，只有在第一和第二阶段都出现的解析器才能标记为潜在的 TTL 遵守解析器。

由于使用出口节点作为代理来了解 DNS 解析器的行为，不能盲目使用结果来表征 DNS 解析器。因此，关注至少有 5 个出口节点的解析器，这使我们有 9031 个解析器和 234605 个出口节点。对于每个解析器，计算连接到旧 IP 地址的出口节点的比例，结果如下：
| TTL（分钟） | TTL 遵守解析器数量 | TTL 遵守解析器比例 | TTL 扩展解析器数量 | TTL 扩展解析器比例 | 混合行为解析器比例 |
| ---- | ---- | ---- | ---- | ---- | ---- |
| 60 | 4147 | 92.5% | 14 | 0.31% | 7.1% |
| 30 | - | - | 129 | 2.53% | - |
| 15 | - | - | 161 | 2.87% | - |
| 5 | - | - | 414 | 6.53% | - |
| 1 | - | - | 745 | 8.74% | - |

可以看出，TTL 扩展解析器的数量随着 TTL 值的减小而增加，且测量的 TTLx 扩展解析器集始终是 TTLy（TTLx < TTLy）扩展解析器集的子集，这表明一些解析器使用默认的最小 TTL 值。

3.3 交叉验证

对始终遵守（或扩展）1 分钟 TTL 的解析器进行交叉验证，共 7160 个解析器。
- 直接向解析器发送 DNS 查询，测试其是否响应以及是否扩展 TTL。
- 利用另一个住宅代理服务 ProxyRack 覆盖本地解析器。

验证结果如下表所示：
| 验证方式 | 遵守 TTL | 扩展 TTL |
| ---- | ---- | ---- |
| 直接扫描（遵守） | 197 | 0 |
| 直接扫描（扩展） | 0 | 16 |
| ProxyRack（遵守） | 381 | 1 |
| ProxyRack（扩展） | 0 | 62 |

结果显示，大部分可测量的解析器表现出一致的行为。ProxyRack 实验中发现的 TTL 违规解析器比直接扫描更多，这可能表明本地解析器更有可能扩展 TTL。

3.4 宏观分析

为了宏观了解 TTL 扩展现象，使用 CAIDA 的 AS 组织数据集将 AS 映射到 ISP 和国家。按国家和 AS 对出口节点进行分组，关注至少有 5 个出口节点的组。

按国家划分的 TTL 扩展情况

排名	国家	具有 TTL 扩展的出口节点数	总出口节点数	比例
1	多哥	91	106	85.84%
2	中国	1514	2425	62.43%
3	留尼汪岛	112	189	59.26%
4	牙买加	175	481	36.38%
5	荷属圣马丁	137	455	30.12%
6	法国	81	329	24.62%
7	科特迪瓦	68	288	23.61%
8	开曼群岛	105	461	22.77%
9	爱尔兰	347	1726	20.1%
10	瑞士	141	704	20.02%
11	西班牙	489	2603	18.79%
12	缅甸	136	762	17.85%
13	德国	36	226	15.93%
14	芬兰	300	1912	15.69%
15	俄罗斯	8808	57283	15.38%

可以看出，获取过期 DNS 响应的出口节点在全球广泛分布。

本地解析器的 TTL 扩展情况

关注至少有 5 个出口节点使用的 DNS 解析器，识别出 ISP 提供的 DNS 服务器。下表列出了前 15 个扩展 TTL 的本地解析器：
| 国家 | ISP | DNS 服务器数量 | 出口节点数量 |
| ---- | ---- | ---- | ---- |
| 俄罗斯 | PSJC Vimpelcom | 16 | 366 |
| 俄罗斯 | PSJC Rostelecom | 12 | 124 |
| 俄罗斯 | Net By Net | 8 | 58 |
| 俄罗斯 | TIS Dialog | 6 | 108 |
| 俄罗斯 | MTS PSJC | 4 | 69 |
| 俄罗斯 | MSK - IX | 4 | 36 |
| 中国 | 中国电信 | 13 | 125 |
| 中国 | 中国移动 | 7 | 39 |
| 中国 | 天津省级 | 5 | 50 |
| 中国 | 中国联通 | 4 | 27 |
| 南非 | MTN SA | 6 | 49 |
| 南非 | Neology | 5 | 97 |
| 开曼群岛 | Cable & Wireless | 7 | 88 |
| 中国香港 | HGC Global Communications | 4 | 38 |
| 特立尼达和多巴哥 | Columbus Comm | 6 | 115 |
| 土耳其 | Netonline Billisim | 5 | 84 |

大部分这些 ISP 和 DNS 解析器位于俄罗斯和中国，这强烈表明 TTL 扩展可能是由 ISP 强制实施的。

3.5 TTL 扩展的影响：CDN 案例研究

CDN 通常使用短 TTL 以提高性能（如负载均衡）或安全原因。TTL 扩展的解析器可能会影响 CDN 的响应能力。

关注 Tranco 1M 域名，识别使用 CDN 的域名。大多数 CDN 使用基于 DNS 的重定向方案，如 Akamai 使用 CNAME 记录将用户重定向到 CDN 基础设施。

使用 OpenINTEL 数据集收集 Tranco Top 1M 域名的 A 记录，包括完整的 CNAME 扩展。分析发现，CDN 的 A 记录 TTL 比其他域名短很多，例如 38% 的 CDN TTL 小于 60 秒。考虑到 8.74% 的解析器在 TTL 小于或等于 60 秒时扩展 TTL，这意味着这些解析器将扩展超过 38% 的 CDN 管理网站的 TTL，可能会损害 CDN 的响应能力。

以下是前 10 个 CDN 及其大多数域名使用的扩展 A 记录的 TTL：
| CDN | TTL | 域名数量 |
| ---- | ---- | ---- |
| Akamai | 20 | 12247 (99.9%) |
| CloudFlare | 300 | 10736 (98.7%) |
| Cloudfront | 60 | 9642 (99.8%) |
| Fastly | 30 | 6237 (98.6%) |
| Google | 300 | 2759 (98.8%) |
| Azure | 10 | 2536 (47.0%) |
| Netlify | 20 | 1531 (98.2%) |
| XCDN | 20 | 99 (47.8%) |
| Alibaba | 120 | 91 (58.7%) |
| CDN77 | 15 | 68 (91.8%) |

4. 总结与建议

4.1 研究总结

本次研究通过使用住宅代理服务 BrightData 对 DNS 解析器的 TTL 违规情况进行了全面的研究。发现 TTL 违规现象在野外较为普遍，存在 TTL 扩展和 DNSSEC 签名记录的 TTL 违规等情况。
- TTL 扩展情况 ：随着 TTL 值的减小，TTL 扩展解析器的数量不断增加，且部分解析器可能使用默认的最小 TTL 值。本地解析器比公共解析器更有可能扩展 TTL。
- 宏观分布 ：TTL 扩展现象在全球广泛分布，不同国家和 ISP 之间存在差异，部分国家和 ISP 的解析器 TTL 扩展比例较高。
- 对 CDN 的影响 ：CDN 通常使用短 TTL 来提高性能和安全性，但 TTL 扩展的解析器可能会损害 CDN 的响应能力。

4.2 建议

为了减少 DNS 解析器 TTL 违规带来的负面影响，提出以下建议：
- 服务运营商
- 在更新凭据信息时，充分考虑 DNS 解析器可能存在的 TTL 违规情况，适当延长等待时间，确保旧缓存被清除。
- 与 ISP 合作，推动其优化 DNS 解析器的配置，减少 TTL 扩展现象。
- ISP
- 优化 DNS 解析器的缓存策略，严格遵守 DNS 记录的 TTL 值，避免不必要的 TTL 扩展。
- 对 DNS 解析器进行定期监测和维护，及时发现和解决 TTL 违规问题。
- CDN 提供商
- 加强与 DNS 解析器运营商的沟通，了解其 TTL 策略，采取相应的措施来减轻 TTL 扩展对 CDN 性能的影响。
- 考虑采用其他技术手段，如 HTTP 缓存控制，来提高 CDN 的响应能力。

5. 未来研究方向

虽然本次研究对 DNS 解析器的 TTL 违规情况进行了较为深入的研究，但仍有一些问题值得进一步探讨：
- 更广泛的测量范围 ：本次研究主要使用了 BrightData 和 ProxyRack 等代理服务进行测量，未来可以考虑使用更多的数据源和测量方法，扩大测量范围，以更全面地了解 DNS 解析器的 TTL 违规情况。
- 深入分析 TTL 违规的原因 ：虽然发现了 TTL 扩展现象与 TTL 值、解析器类型等因素有关，但对于具体的原因还需要进一步深入分析，例如解析器软件的配置、网络环境等因素对 TTL 违规的影响。
- 提出有效的解决方案 ：基于对 TTL 违规情况的深入了解，未来可以研究提出更有效的解决方案，如开发新的 DNS 解析器缓存策略、优化 DNS 记录的更新机制等，以减少 TTL 违规带来的负面影响。

6. 结论

DNS 解析器的 TTL 违规现象是一个普遍存在的问题，会对网络服务的性能和安全性产生负面影响。通过本次研究，我们对 TTL 违规情况有了更深入的了解，包括 TTL 扩展的情况、宏观分布以及对 CDN 的影响等。同时，提出了相应的建议和未来研究方向，希望能够为解决 DNS 解析器 TTL 违规问题提供参考。

以下是本次研究的主要发现总结表格：
| 研究方面 | 主要发现 |
| ---- | ---- |
| TTL 扩展情况 | 随着 TTL 值减小，扩展解析器数量增加；本地解析器更易扩展 TTL |
| 宏观分布 | 全球广泛分布，部分国家和 ISP 扩展比例高 |
| 对 CDN 的影响 | 可能损害 CDN 响应能力，因 CDN 多使用短 TTL |

mermaid 格式流程图展示研究的整体流程：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    A(研究背景):::process --> B(使用 BrightData 测量):::process
    B --> C(识别 TTL 扩展解析器):::process
    C --> D(交叉验证):::process
    D --> E(宏观分析):::process
    E --> F(分析对 CDN 的影响):::process
    F --> G(总结与建议):::process
    G --> H(未来研究方向):::process

通过以上研究和分析，我们希望能够提高对 DNS 解析器 TTL 违规问题的认识，促进网络服务的稳定和安全运行。