yuzhang.github.io

#《RFC 8483: Yeti DNS Testbed》摘录

张宇哈尔滨工业大学 2019.07.04

Yeti DNS (雪人DNS)是一个实验性的、非生产性的根服务器测试床。目前，测试床中共有25台根服务器。它与当前根服务器系统相似，但不同。这篇文档记录部署该系统的技术和运行经验。用“DNS根”代表当前DNS的根，用“Yeti根”表示Yeti测试床的根。

[1] Yeti根采用IANA发布的根区，未对任何已分配顶级域进行更改、添加或删除。
[1] Yeti根服务器采用Yeti根KSK签名的DNSKEY资源记录集。
[4] 访问Yeti根的递归解析器需要配置Yeti根提示（hints）和Yeti根信任锚。
[4] 在IANA与Yeti根之间是3个分发主节点（Distribution Master, DM），负责更新根区并将根区分发到Yeti根。每个DM是自主的，实现了共享根区控制的思想。
[4.1] 每个DM从DNS根服务器（F根）获取SOA.SERIAL值，以此判断根区是否应更新，并通过未认证的区转送（zone transfer）从DNS根服务器来获取根区。
[4.2] 采用两种不同的根区转换方法将DNS根区中一个最小信息集合替换为Yeti测试床数据。
[4.2.1] 第一种根区转换方法是在DM之间共享KSK和ZSK集合：
1. SOA.MNAME设置为www.yeti-dns.org
2. SOA.RNAME设置为.yeti-dns.org，其中目前为“wide”，“bii”或“tisf”。
3. 删除所有DNSKEY，RRSIG和NSEC记录。
4. 删除DNS根服务器的NS资源记录集和对应的胶水资源记录集（A和AAAA）。
5. 添加一个Yeti根的DNSKEY资源记录集，包含所有Yeti的KSK和ZSK。
6. 添加一个Yeti根的NS资源记录集，包含所有Yeti根服务器。
7. 添加所有Yeti根的胶水记录（只有AAAA类型，由于Yeti根服务器只用于IPv6）。
8. 对Yeti根区签名：重新生成NSEC链；Yeti的KSK用于对DNSKEY资源记录集签名；共享的ZSK用来对所有其他资源记录集签名。
[4.2.2] 第二种根区转换方法是每个DM用各自的ZSK，没有共享的KSK：
1. 设立一个中央隐藏主节点（Hidden Master，HM），负责获取DNS根区，将DNSKEY资源记录集合替换并签名。
2. 每个DM从HM获取根区数据。除了不需要更改DNSKEY资源记录集，根区转换过程与第一种方法类似。每个DM用各自的ZSK来对其他资源记录集签名。
[4.2.3] 对第二种根区转换方法的一个变化是保留DNS根区NSEC链和ZSK签名。该方法仍然替换DNS根区KSK，但DNS根区ZSK不变。Yeti根的KSK用来产生根的DNSKEY和NS资源记录集的签名（原文有问题，通过和宋林健的沟通，实际是添加了一个新的ZSK来对NS签名）。数据从DNS根服务器系统经过HM到达DM，但在DM上不需要DNSSEC操作，并且DNS的NSEC和大多数资源记录集不变。该方法最小化对IANA根区的更改，提供了自动化验证。
[4.3] Yeti根区分发：每个DM通过NOTIFY消息来通知所有Yeti根服务器。Yeti根服务器基于DM的地址实现访问控制。
[4.4] 元数据同步：Yeti测试床设施变更（添加或移除Yeti根服务器，变更服务器IP地址，更新DNSSEC密钥等）都在DM上操作。DM之间同步通过Git仓库实现。
[4.5] Yeti根服务器命名：不考虑采用标签压缩将启动应答（包含根服务器列表）最小化，因为EDNS(0)已经被广泛采用。不同服务器软件返回启动应答的行为（是否包含胶水记录）无须一致。
[4.6] 25台Yeti根服务器中的18台通过VPS实现；15台服务器运行Linux，4台运行FreeBSD，1台NetBSD，1台Windows Server 2016；16台运行BIND9，4台运行NSD，2台运行Knot；1台运行Bundy；1台运行PowerDNS，一台运行MS DNS。
[4.7] 实验流量来自三个方面：来自用户的真实世界流量100qps；来自测量平台（RIPE ATLAS），；重放捕获的流量
[4.8] 流量捕获试用dnscap或pcapdump。
[5.1] Yeti根服务器只支持IPv6。IPv4用户通过双协议栈解析器来加入测试床。一个特例是在CERNET2中，Yeti根服务器被分配一个IPv4地址，采用双协议栈IVI转换设备。
[5.2.1] 区分发：Yeti根服务器被配置为从根服务器（salve），将3台DM配置为其主服务器（master）。除了DNSKEY资源记录集，每个DM使用不同的ZSK对根区签名。当Yeti根服务器更换DM时，采用AXFR来更新区数据。
[5.2.2] 测试中从一个DNS根区更新到DM发布新根区之间时延在20到40分钟。
[5.2.3] 由于不同DM采用不同ZSK来签名，递归解析器缓存中会混有不同ZSK签的RRSig，但这不影响签名验证。
[5.3] DNSSEC KSK轮转分三种情况：
[5.3.1] 在撤销当前KSK之前，有意忽略30天保留期。这导致部分解析器验证错误，只能手动更新解析器上的信任锚。
[5.3.2] KSK轮转与BIND9视图(View): 采用Pre-Publish（预发布，不同于double-signature）方案，并且BIND9配置多个视图时，会发生故障。解决方案是每个视图中配置“managed-keys”。
[5.3.3] 大应答：当KSK轮转时，DNSKEY资源记录最多可能有8个（新旧2个KSK，新旧2x3个ZSK，其中每个DM有自己的ZSK）。但实际只有BII经历了ZSK轮转，因此有3个ZKS加上2个KSK，共1975字节。递归解析器故障率为0.0687。
[5.4] 大DNS应答捕获：采用YmmV和PcapParser工具。
[5.5] 提示文件（Hints File）自动维护：开发了一个提示文件自动维护工具hintUpdate，自动化过程如下：
1. 使用本地解析器获取“./IN/NS”查询的应答。
2. 使用本地解析器获得每个域名服务器的IPv4和IPv6地址集合。
3. 从本地解析器验证所有签名。
4. 与当前提示文件比较，将旧的替换为新的。该工具在当前DNS根服务器系统中不会工作，由于单个根服务器的名字并不会被签名。
[6] 结论：通过Yeti DNS测试床建设和运行获得以下发现
- 在纯IPv6环境下运行；大应答传输有约7%的故障率。由于TCP分段的分片导致Yeti根服务器获取Yeti根区时的两个故障；通过设置TCP MSS为1220字节解决。
- 成功运行了3个自主的Yeti根区签名者和25台Yeti根服务器，确认了IXFR不适合通过不同路径来传递根区。
- ZSK大小增加到2048位，多次KSK轮转来检验解析器对RFC5011的支持；识别出了与配置了“managed-keys”的BIND9视图相关的缺陷。
- 使用自然的（而不是统一的）Yeti根服务器名字暴露出了是否在启动查询的应答中包含胶水记录的差异；除了低效，Yeti解析器功能正常。
- Knot2.0对根（空）标签进行标签压缩。由于指针被编码为2个字节，这导致指向根标签的编码大小增加。
- 开发了若干工具：针对大DNS应答的DNS分片和DNS附加截断应答（ATR），BIND9附加段胶水补丁，YmmV，以及用于捕获和镜像流量的IPv6区分片（defrag）。另外，开发了一个用于提示文件自动维护的工具。
未来工作：
- 启动应答截断和只支持TCP的Yeti根服务器：观察并测量启动应答截断的最坏情况，即将从UDP接收的所有启动查询所对应请求中TC标记设置为1，令客户端采用TCP来重试。该实验可以对只支持TCP的DNS的有用性获得更多认识。
- KSK ECDSA轮转：一种减小DNSKEY应答大小的方法是改为椭圆曲线签名算法。尽管原则上可以对KSK和ZSK分别进行更改，但RIPE NCC最近进行了研究并发现一些解析器需要KSK和ZSK采用相同算法。这意味着一次算法轮转也需要一次KSK轮转。（对于为什么不考虑ZSK算法轮转，宋林健的解释是，这里重点关注KSK算法轮转，因为它是解析器上的信任锚。）
- 用于区传送的Sticky Notify：IXFR作为区传送机制在Yeti DNS测试床上的不可用性可以通过为每个从服务器固定一个偏好的主服务器来缓解。在不同主服务器提供一个区的等价但不完全相同版本情况下，这使得初始AXFR应答之后进行IXFR请求，而不破坏区完整性。
- 用于区传送证书的密钥分发：在从服务器和主服务器之间共享秘密的使用需要密钥分发和管理，而其可扩展性并不适合有大量传送客户端的系统。可以被考虑其他密钥分发和认证方法。
- DNS是一个树形层次化数据库。数学上，其具有一个根节点以及父节点和子节点之间的依赖关系。所以，如果存在人为错误、恶意攻击、甚至异常地震，则父节点（在Yeti案例中的根）的任何故障和不稳定可能影响子节点。建议定义技术和实践来允许从小公司到国家的任何组织在其DNS中自给自足。
- 采用区块链等技术工具来去除对中央根权威的技术需求或者增加当前根的安全和稳定性。
[7] 安全考量：
- 三个DM之间使用Git来同步服务元数据。任何Git相关安全问题都可能影响Yeti的DM运行。
- Yeti解析器需要来自和发布的Yeti提示文件和信任锚。
- 为了降低DNSSEC对根区的中心功能，采用了多个独立运行的签名者和多个ZSK对根区签名。