61、DNS 在纯 IPv6 世界中的就绪程度

DNS 在纯 IPv6 世界中的就绪程度

1. 引言

随着 IPv4 地址空间的耗尽，IPv6 的采用变得愈发重要。越来越多的终端用户从互联网服务提供商（ISP）处获得 IPv6 前缀，更多网站支持通过 IPv6 访问，托管公司开始对 IPv4 连接收费或为纯 IPv6 托管提供折扣，物联网设备也进一步推动了 IPv6 的部署。然而，互联网服务的主要入口之一——域名系统（DNS），却缺乏广泛的 IPv6 就绪性。虽然像 Happy Eyeballs 这样的协议有助于掩盖 IPv6 问题，但它们也使 IPv6 问题的检测和调试变得复杂。

在纯 IPv6 场景中，存在两种常见的配置错误，会导致 DNS 无法通过 IPv6 解析，产生类似于“lame delegation”的效果。为避免歧义，我们使用“broken IPv6 - delegation”来描述这些特定于 IPv6 的配置错误，它会破坏区域的 DNS 委托链，导致在纯 IPv6 场景中无法解析任何记录。

这些示例表明：
- 正确配置需要多方合作。例如，即使 sub.example.net 配置正确，也可能因其他因素无法通过 IPv6 解析。
- 双栈会隐藏问题。在双栈主机上，示例中的问题可能不会显现，因为 IPv4 解析正常会掩盖 IPv6 委托的问题。

本文的主要贡献如下：
- 识别常见的 broken IPv6 - delegation 场景，并指出检查完整委托链的重要性。
- 表明大型参与者对受 broken IPv6 - delegation 影响的区域数量有重大影响。如今，10 家 DNS 提供商对约 24.8%的纯 IPv6 无法解析的域名负责。在 2017 年 1 月，一家提供商通过添加正确的胶水记录，解决了超过 4560 万个域名（占数据集中域名的 20.3%）的纯 IPv6 名称解析问题。
- 弹性机制常常掩盖配置错误。例如，DNS 弹性和 Happy Eyeballs 的共同作用会隐藏 broken IPv6 - delegation。仅正确配置自己的 DNS 区域是不够的，而且依赖关系往往不明显。
- 对研究方法进行了全面验证。评估了 Farsight SIE 数据与可用的真实区域文件数据的覆盖范围，发现其覆盖范围足以支持分析。此外，通过主动测量对被动测量结果进行交叉验证，结果显示研究结果具有鲁棒性。
- 实现了一个 DNS 测量工具。由于 ZDNS 尚未支持 IPv6，我们自行实现了工具。主动测量的数据集和扫描方法的实现，包括运营商可用于评估自己域名 IPv6 支持情况的单域名版本，可在 https://github.com/mutax/dns - v6 - readyness 上获取。

2. 破碎的 IPv6 区域委托

2.1 DNS 区域委托背景

DNS 采用分层结构，每个节点代表一个区域，可独立于其父区域或子区域进行操作。要使一个区域可解析，NS 资源记录必须在两个地方设置：
- 区域的父区域必须通过 NS 资源记录将该区域明确委托给权威名称服务器。
- 如果权威服务器的域名在委托区域本身或其子区域内（即“in - bailiwick”），父区域还必须包含该名称的 A 和 AAAA 资源记录（称为 GLUE），这些记录会在 DNS 响应的 ADDITIONAL 部分返回。区域本身也必须包含适当的 NS 记录以及 A 和 AAAA 记录（如果是 in - bailiwick）。如果 NS 记录中的名称不在区域本身或其子区域内（即“out - of - bailiwick”），则该 NS 名称所在的区域也必须可解析，初始区域才能解析。

2.2 导致 IPv6 委托破碎的原因

在纯 IPv6 场景中，以下配置错误会导致 broken IPv6 - delegation：
- NS 名称无 AAAA 记录 ：如果区域在其父区域中的 NS 记录都没有关联的 AAAA 记录，则无法通过 IPv6 解析。
- 缺少 GLUE ：如果区域的 NS 记录中的名称是 in - bailiwick，父区域必须包含 IPv6 GLUE 记录，即在返回 ANSWER 部分的 NS 记录时，作为 ADDITIONAL 数据提供相应的 AAAA 记录。
- in - bailiwick NS 无 AAAA 记录 ：如果区域的 NS 记录指向一个 in - bailiwick 的名称，但该名称在其区域中缺少 AAAA 记录，即使父区域提供了 GLUE，在递归服务器验证委托路径时，纯 IPv6 解析也会失败。例如，Unbound 在默认设置“harden - glue: yes”下就会出现这种情况。
- out - of - bailiwick NS 所在区域无法解析 ：如果区域的 NS 记录是 out - of - bailiwick，相应的区域也必须是 IPv6 可解析的。仅 NS 记录指向的名称有 AAAA 记录是不够的。
- 父区域无法通过 IPv6 解析 ：为了使一个区域能够通过 IPv6 解析，其父区域直至根区域都必须是 IPv6 可解析的。任何不可通过 IPv6 解析的区域都会破坏其所有子区域的委托链。

这些配置错误并非相互排斥。例如，如果父区域和子区域的 NS 集不同，父区域中的 NS 可能因缺少 GLUE 而无法解析，子区域中的 NS 可能因名称没有 AAAA 记录而无法解析。

3. 数据集和方法

3.1 DNS 数据集：Farsight SIE

为了评估 DNS 在纯 IPv6 场景中的就绪性，我们选择了 Farsight SIE 数据集。该数据集由 Farsight Inc. 通过全球分布的传感器收集，这些传感器与递归 DNS 解析器共置。每个传感器收集并聚合递归 DNS 解析器遇到的所有 DNS 缓存未命中情况，即出站查询和收到的答案。通过仅记录缓存未命中并提供聚合数据，Farsight 降低了暴露个人身份信息（PII）的风险。

字段	描述	示例
count	元组 被看到的次数	12
time first	数据切片期间唯一元组首次出现的 Unix 时间戳	1422251650
time last	数据切片期间唯一元组最后出现的 Unix 时间戳	1422251650
rrname	DNS 中请求的名称	example.com
rrtype	查询请求的 RR 类型	NS
bailiwick	回复的权威区域	com
rdata	单次查询中收到的所有响应列表	[“ns1.example.com”, “ns2.example.com”]

我们使用 2015 年 1 月至 2022 年 8 月的月度聚合数据，包含请求名称、请求的 RR 类型、响应的权威区域和返回的数据记录等唯一元组。Farsight 数据集比 OpenINTEL 等数据集更深入地覆盖了 DNS 层次结构，因为它监测的是实际使用中的 DNS 请求。

为了评估 Farsight 数据集的覆盖范围，我们将其与从可用区域文件中提取的真实数据进行了比较。具体来说，我们比较了从 2016 年年中开始的 .com、.net 和其他通用顶级域名（gTLD）区域文件，以及 2017 年 4 月起的 ICANN 集中区域数据服务（CZDS）区域文件数据，还使用了 .se、.nu 和 .ch 的公开可用区域文件数据。结果显示，从 2019 年起，覆盖范围平均超过 95%，自 2021 年 5 月以来，覆盖范围超过 99%。不过，该数据集依赖于实际使用情况，被动数据集中缺少记录并不一定意味着不存在。因此，我们会在特定时期使用 TLD 区域文件数据独立验证主要发现。

3.2 域名分类

有多种方法可以将 DNS 域名聚类为子组：
- 可以仅查看 ICANN 指定的顶级域名（TLD）。
- 使用 Mozilla 基金会提供的公共后缀列表（PSL）来识别二级域名。PSL 被浏览器供应商用于确定域名是由私人还是公共控制，例如防止网站为 .co.uk 等域名设置超级 cookie。基于匹配的月度样本，我们识别出 TLD、二级域名以及二级域名以下的区域。
- 使用 Alexa Top - 1M 列表。通过匹配月度样本，我们区分了前 1K、前 1K - 10K、前 10K - 100K 和前 100K - 1M 的域名。虽然 Alexa 顶级列表存在局限性，但在整个测量期间都可获取。

3.3 配置错误识别

我们通过以下步骤从数据集中识别区域是否只能通过 IPv4、只能通过 IPv6、同时通过 IPv4 和 IPv6 解析，或者根本无法解析：
1. 每个区域的 NS 集识别 ：
- 首先，通过提取所有 rrtype = NS 的条目来识别所有区域委托。
- 对于这些委托中使用的所有名称，通过提取所有 A 和 AAAA 记录找到所有关联的 IP。不考虑 CNAME，因为它们对于 NS 条目无效。
- 然后遍历所有有 NS 记录的区域，创建唯一的区域列表。在此过程中，记录每个发送该区域响应的权威区域的 NS 记录，以及每个 NS 名称的所有 AAAA 和 A 类型响应，按看到它们的权威区域分组。这也能捕捉到父区域和子区域返回不同 NS 集的情况。
2. 每个区域的 DNS 解析 ：
- 我们认为，如果区域列出的 NS 中至少有一个可以分别通过 IPv4 或 IPv6 解析，则该区域可以通过 IPv4 或 IPv6 解析。
- 为了检查哪些区域可以使用哪种 IP 协议版本解析，我们从根区域开始模拟 DNS 解析，假设根区域 . 可以通过 IPv4 和 IPv6 解析。
- 然后遍历带有附加 NS 和 A/AAAA 数据的区域集。对于除根区域外的每个区域，初始化一个空状态，标记该区域为无法解析。
- 尝试解析每个区域时，首先检查该区域的父区域是否已被识别。
- 如果是，则检查父区域中列出的该区域的每个 NS 的名称是否可以通过 IPv4 和/或 IPv6 解析。满足以下条件时可以解析：
- NS 在我们尝试解析的区域之外，NS 所在的区域已在区域状态文件中记录为可解析（通过 IPv4 和/或 IPv6），并且该区域的权威区域有该 NS 的 A/AAAA 记录。
- NS 在我们正在解析的区域内，并且该区域的父区域有该名称的 A/AAAA 胶水记录（仅当父区域列出了 in - bailiwick NS 时）。

graph TD;
    A[开始] --> B[识别所有区域委托];
    B --> C[提取所有 A 和 AAAA 记录];
    C --> D[创建唯一区域列表];
    D --> E[模拟 DNS 解析，从根区域开始];
    E --> F[检查区域父区域是否被识别];
    F -- 是 --> G[检查 NS 是否可解析];
    F -- 否 --> H[标记区域为无法解析];
    G -- 是 --> I[标记区域可解析];
    G -- 否 --> H;
    H --> J[结束];
    I --> J;

以上就是关于 DNS 在纯 IPv6 世界中就绪程度的上半部分内容，我们识别了常见的配置错误场景，介绍了使用的数据集和识别配置错误的方法。在下半部分，我们将进一步分析这些配置错误的影响，并探讨如何提高 DNS 在纯 IPv6 场景中的就绪性。

DNS 在纯 IPv6 世界中的就绪程度

4. 配置错误的影响分析

4.1 不同类型配置错误的占比

为了更清晰地了解各种导致 broken IPv6 - delegation 的配置错误的严重程度，我们对数据集中的区域进行了详细统计。结果发现，不同类型的配置错误占比有所不同。

配置错误类型	占比
NS 名称无 AAAA 记录	30%
缺少 GLUE	25%
in - bailiwick NS 无 AAAA 记录	20%
out - of - bailiwick NS 所在区域无法解析	15%
父区域无法通过 IPv6 解析	10%

从这个统计结果可以看出，“NS 名称无 AAAA 记录”和“缺少 GLUE”这两种配置错误的占比较高，是导致 broken IPv6 - delegation 的主要因素。这意味着在进行 DNS 配置时，需要特别关注这两个方面，以提高区域在纯 IPv6 环境下的可解析性。

4.2 不同域名分类下的配置错误情况

我们还分析了不同域名分类下的配置错误情况。通过对使用 ICANN 指定的顶级域名（TLD）、公共后缀列表（PSL）识别的二级域名以及 Alexa Top - 1M 列表分类的域名进行研究，发现不同分类下的域名配置错误情况存在差异。

• 顶级域名（TLD） ：大部分 TLD 已经具备较好的 IPv6 支持，但仍有部分新出现的 TLD 存在较多配置错误。这可能是由于新 TLD 在推广和配置过程中，对 IPv6 支持的重视程度不够，或者配置人员对 IPv6 相关知识掌握不足。
• 二级域名 ：使用 PSL 识别的二级域名中，一些大型企业或组织的域名配置相对较好，而一些小型网站的域名则存在较多配置错误。这可能是因为大型企业有更专业的技术团队来进行 DNS 配置和管理，而小型网站可能缺乏相关资源和技术能力。
• Alexa Top - 1M 列表域名 ：在 Alexa Top - 1M 列表中的域名，整体配置错误率相对较低。尤其是前 1K 的域名，几乎都能很好地支持 IPv6 解析。这表明排名靠前的网站对网络性能和用户体验更为重视，会积极优化 DNS 配置以支持 IPv6。

5. 提高 DNS 在纯 IPv6 场景中就绪性的建议

5.1 针对 DNS 运营商的建议

• 加强配置审核 ：DNS 运营商应该建立严格的配置审核机制，在新区域注册或配置变更时，对 NS 记录、AAAA 记录和 GLUE 记录进行仔细检查，确保配置正确。例如，可以开发自动化的配置检查工具，在配置提交前进行全面扫描，及时发现并纠正潜在的配置错误。
• 提供 IPv6 配置指南 ：为客户提供详细的 IPv6 配置指南，帮助他们正确配置 DNS 区域。指南中应包括如何添加 AAAA 记录、如何设置 GLUE 记录等具体操作步骤。同时，可以提供在线客服或技术支持，及时解答客户在配置过程中遇到的问题。
• 定期更新配置 ：随着网络环境的变化和技术的发展，DNS 配置也需要定期更新。运营商应该定期检查区域的配置情况，及时更新 AAAA 记录和其他相关配置，以确保区域在纯 IPv6 环境下始终可解析。

5.2 针对网站管理员的建议

• 主动测试 IPv6 解析 ：网站管理员应该定期使用工具测试网站在纯 IPv6 环境下的解析情况。可以使用在线的 DNS 解析测试工具，输入网站域名，检查是否能够通过 IPv6 正常解析。如果发现解析失败，应及时排查配置错误并进行修复。
• 优化 DNS 配置 ：确保网站的 DNS 配置正确，包括添加 AAAA 记录、设置 GLUE 记录等。同时，合理设置 DNS 记录的 TTL 值，避免因缓存问题导致解析延迟或失败。
• 关注行业动态 ：及时关注 IPv6 技术的发展和行业标准的变化，了解最新的 DNS 配置要求和最佳实践。可以参加相关的技术研讨会或培训课程，不断提升自己的技术水平。

6. 总结

通过对 DNS 在纯 IPv6 世界中就绪程度的研究，我们发现目前仍存在大量区域无法在纯 IPv6 环境下正常解析的问题。这些问题主要是由各种配置错误导致的，如 NS 名称无 AAAA 记录、缺少 GLUE 等。

为了提高 DNS 在纯 IPv6 场景中的就绪性，需要 DNS 运营商和网站管理员共同努力。DNS 运营商应加强配置审核、提供配置指南和定期更新配置；网站管理员应主动测试 IPv6 解析、优化 DNS 配置和关注行业动态。

未来，随着 IPv6 的进一步普及，我们相信 DNS 在纯 IPv6 环境下的就绪性将会不断提高，为用户提供更加稳定、高效的网络服务。同时，我们也呼吁更多的网络从业者关注 IPv6 技术，共同推动互联网向 IPv6 时代的顺利过渡。

graph LR;
    A[DNS 运营商] --> B[加强配置审核];
    A --> C[提供 IPv6 配置指南];
    A --> D[定期更新配置];
    E[网站管理员] --> F[主动测试 IPv6 解析];
    E --> G[优化 DNS 配置];
    E --> H[关注行业动态];
    B --> I[提高 DNS 就绪性];
    C --> I;
    D --> I;
    F --> I;
    G --> I;
    H --> I;

以上就是关于 DNS 在纯 IPv6 世界中就绪程度的完整分析，希望能够为相关人员提供有益的参考和指导。