Independent Submission L. Song, Ed.
Request for Comments: 8483 D. Liu
Category: Informational Beijing Internet Institute
ISSN: 2070-1721 P. Vixie
TISF
A. Kato
Keio/WIDE
S. Kerr
October 2018
Independent Submission L. Song, Ed.
Request for Comments: 8483 D. Liu
Category: Informational Beijing Internet Institute
ISSN: 2070-1721 P. Vixie
TISF
A. Kato
Keio/WIDE
S. Kerr
October 2018
Yeti DNS Testbed
雪人DNS试验台
Abstract
摘要
Yeti DNS is an experimental, non-production root server testbed that provides an environment where technical and operational experiments can safely be performed without risk to production root server infrastructure. This document aims solely to document the technical and operational experience of deploying a system that is similar to but different from the Root Server system (on which the Internet's Domain Name System is designed and built).
Yeti DNS是一个实验性的、非生产性的根服务器测试平台，它提供了一个可以安全地执行技术和操作实验的环境，而不会对生产根服务器基础设施造成风险。本文档旨在记录部署与根服务器系统（Internet域名系统的设计和构建基于根服务器系统）相似但不同的系统的技术和操作经验。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8483.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8483.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation and Conventions . . . . . . . . . . . . 5
3. Areas of Study . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Implementation of a Testbed like the Root Server System . 5
3.2. Yeti-Root Zone Distribution . . . . . . . . . . . . . . . 5
3.3. Yeti-Root Server Names and Addressing . . . . . . . . . . 5
3.4. IPv6-Only Yeti-Root Servers . . . . . . . . . . . . . . . 6
3.5. DNSSEC in the Yeti-Root Zone . . . . . . . . . . . . . . 6
4. Yeti DNS Testbed Infrastructure . . . . . . . . . . . . . . . 7
4.1. Root Zone Retrieval . . . . . . . . . . . . . . . . . . . 8
4.2. Transformation of Root Zone to Yeti-Root Zone . . . . . . 9
4.2.1. ZSK and KSK Key Sets Shared between DMs . . . . . . . 10
4.2.2. Unique ZSK per DM; No Shared KSK . . . . . . . . . . 10
4.2.3. Preserving Root Zone NSEC Chain and ZSK RRSIGs . . . 11
4.3. Yeti-Root Zone Distribution . . . . . . . . . . . . . . . 12
4.4. Synchronization of Service Metadata . . . . . . . . . . . 12
4.5. Yeti-Root Server Naming Scheme . . . . . . . . . . . . . 13
4.6. Yeti-Root Servers . . . . . . . . . . . . . . . . . . . . 14
4.7. Experimental Traffic . . . . . . . . . . . . . . . . . . 16
4.8. Traffic Capture and Analysis . . . . . . . . . . . . . . 16
5. Operational Experience with the Yeti DNS Testbed . . . . . . 17
5.1. Viability of IPv6-Only Operation . . . . . . . . . . . . 17
5.1.1. IPv6 Fragmentation . . . . . . . . . . . . . . . . . 18
5.1.2. Serving IPv4-Only End-Users . . . . . . . . . . . . . 19
5.2. Zone Distribution . . . . . . . . . . . . . . . . . . . . 19
5.2.1. Zone Transfers . . . . . . . . . . . . . . . . . . . 19
5.2.2. Delays in Yeti-Root Zone Distribution . . . . . . . . 20
5.2.3. Mixed RRSIGs from Different DM ZSKs . . . . . . . . . 21
5.3. DNSSEC KSK Rollover . . . . . . . . . . . . . . . . . . . 22
5.3.1. Failure-Case KSK Rollover . . . . . . . . . . . . . . 22
5.3.2. KSK Rollover vs. BIND9 Views . . . . . . . . . . . . 22
5.3.3. Large Responses during KSK Rollover . . . . . . . . . 23
5.4. Capture of Large DNS Response . . . . . . . . . . . . . . 24
5.5. Automated Maintenance of the Hints File . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation and Conventions . . . . . . . . . . . . 5
3. Areas of Study . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Implementation of a Testbed like the Root Server System . 5
3.2. Yeti-Root Zone Distribution . . . . . . . . . . . . . . . 5
3.3. Yeti-Root Server Names and Addressing . . . . . . . . . . 5
3.4. IPv6-Only Yeti-Root Servers . . . . . . . . . . . . . . . 6
3.5. DNSSEC in the Yeti-Root Zone . . . . . . . . . . . . . . 6
4. Yeti DNS Testbed Infrastructure . . . . . . . . . . . . . . . 7
4.1. Root Zone Retrieval . . . . . . . . . . . . . . . . . . . 8
4.2. Transformation of Root Zone to Yeti-Root Zone . . . . . . 9
4.2.1. ZSK and KSK Key Sets Shared between DMs . . . . . . . 10
4.2.2. Unique ZSK per DM; No Shared KSK . . . . . . . . . . 10
4.2.3. Preserving Root Zone NSEC Chain and ZSK RRSIGs . . . 11
4.3. Yeti-Root Zone Distribution . . . . . . . . . . . . . . . 12
4.4. Synchronization of Service Metadata . . . . . . . . . . . 12
4.5. Yeti-Root Server Naming Scheme . . . . . . . . . . . . . 13
4.6. Yeti-Root Servers . . . . . . . . . . . . . . . . . . . . 14
4.7. Experimental Traffic . . . . . . . . . . . . . . . . . . 16
4.8. Traffic Capture and Analysis . . . . . . . . . . . . . . 16
5. Operational Experience with the Yeti DNS Testbed . . . . . . 17
5.1. Viability of IPv6-Only Operation . . . . . . . . . . . . 17
5.1.1. IPv6 Fragmentation . . . . . . . . . . . . . . . . . 18
5.1.2. Serving IPv4-Only End-Users . . . . . . . . . . . . . 19
5.2. Zone Distribution . . . . . . . . . . . . . . . . . . . . 19
5.2.1. Zone Transfers . . . . . . . . . . . . . . . . . . . 19
5.2.2. Delays in Yeti-Root Zone Distribution . . . . . . . . 20
5.2.3. Mixed RRSIGs from Different DM ZSKs . . . . . . . . . 21
5.3. DNSSEC KSK Rollover . . . . . . . . . . . . . . . . . . . 22
5.3.1. Failure-Case KSK Rollover . . . . . . . . . . . . . . 22
5.3.2. KSK Rollover vs. BIND9 Views . . . . . . . . . . . . 22
5.3.3. Large Responses during KSK Rollover . . . . . . . . . 23
5.4. Capture of Large DNS Response . . . . . . . . . . . . . . 24
5.5. Automated Maintenance of the Hints File . . . . . . . . . 24
5.6. Root Label Compression in Knot DNS Server . . . . . . . . 25
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Yeti-Root Hints File . . . . . . . . . . . . . . . . 33
Appendix B. Yeti-Root Server Priming Response . . . . . . . . . 34
Appendix C. Active IPv6 Prefixes in Yeti DNS Testbed . . . . . . 36
Appendix D. Tools Developed for Yeti DNS Testbed . . . . . . . . 36
Appendix E. Controversy . . . . . . . . . . . . . . . . . . . . 37
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
5.6. Root Label Compression in Knot DNS Server . . . . . . . . 25
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Yeti-Root Hints File . . . . . . . . . . . . . . . . 33
Appendix B. Yeti-Root Server Priming Response . . . . . . . . . 34
Appendix C. Active IPv6 Prefixes in Yeti DNS Testbed . . . . . . 36
Appendix D. Tools Developed for Yeti DNS Testbed . . . . . . . . 36
Appendix E. Controversy . . . . . . . . . . . . . . . . . . . . 37
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
The Domain Name System (DNS), as originally specified in [RFC1034] and [RFC1035], has proved to be an enduring and important platform upon which almost every end-user of the Internet relies. Despite its longevity, extensions to the protocol, new implementations, and refinements to DNS operations continue to emerge both inside and outside the IETF.
最初在[RFC1034]和[RFC1035]中规定的域名系统（DNS）已被证明是一个持久而重要的平台，几乎所有互联网最终用户都依赖它。尽管其寿命很长，但协议的扩展、新的实现和DNS操作的改进仍在IETF内外不断出现。
The Root Server system in particular has seen technical innovation and development, for example, in the form of wide-scale anycast deployment, the mitigation of unwanted traffic on a global scale, the widespread deployment of Response Rate Limiting [RRL], the introduction of IPv6 transport, the deployment of DNSSEC, changes in DNSSEC key sizes, and preparations to roll the root zone's Key Signing Key (KSK) and corresponding trust anchor. These projects created tremendous qualitative operational change and required impressive caution and study prior to implementation. They took place in parallel with the quantitative expansion or delegations for new TLDs (see <https://newgtlds.icann.org/>).
根服务器系统尤其经历了技术创新和发展，例如，大规模选播部署、在全球范围内缓解不必要的流量、广泛部署响应速率限制[RRL]、引入IPv6传输、部署DNSSEC、更改DNSSEC密钥大小、，以及准备滚动根区域的密钥签名密钥（KSK）和相应的信任锚。这些项目带来了巨大的质量操作变化，需要在实施前进行令人印象深刻的谨慎和研究。它们与新TLD的数量扩张或授权同时进行（见<https://newgtlds.icann.org/>).
Aspects of the operational structure of the Root Server system have been described in such documents as [TNO2009], [ISC-TN-2003-1], [RSSAC001], and [RFC7720]. Such references, considered together, provide sufficient insight into the operations of the system as a whole that it is straightforward to imagine structural changes to the Root Server system's infrastructure and to wonder what the operational implications of such changes might be.
根服务器系统的操作结构方面已在[TNO2009]、[ISC-TN-2003-1]、[RSSAC001]和[RFC7720]等文档中描述。综合考虑这些参考，可以充分了解整个系统的操作，因此可以直接想象根服务器系统基础结构的结构更改，并想知道这些更改可能会对操作产生什么影响。
The Yeti DNS Project was conceived in May 2015 with the aim of providing a non-production testbed that would be open for use by anyone from the technical community to propose or run experiments designed to answer these kinds of questions. Coordination for the
雪人DNS项目构思于2015年5月，旨在提供一个非生产性试验台，该试验台将开放供技术社区的任何人使用，以提出或运行旨在回答此类问题的实验。联合国系统的协调
project was provided by BII, TISF, and the WIDE Project. Thus, Yeti DNS is an independently coordinated project and is not affiliated with the IETF, ICANN, IANA, or any Root Server Operator. The objectives of the Yeti Project were set by the participants in the project based on experiments that they considered would provide valuable information.
该项目由BII、TISF和WIDE项目提供。因此，雪人DNS是一个独立协调的项目，不隶属于IETF、ICANN、IANA或任何根服务器运营商。雪人项目的目标是由项目参与者根据他们认为将提供有价值信息的实验确定的。
Many volunteers collaborated to build a distributed testbed that at the time of writing includes 25 Yeti root servers with 16 operators and handles experimental traffic from individual volunteers, universities, DNS vendors, and distributed measurement networks.
许多志愿者合作构建了一个分布式测试平台，在撰写本文时，该平台包括25个Yeti根服务器和16个运营商，并处理来自各个志愿者、大学、DNS供应商和分布式测量网络的实验流量。
By design, the Yeti testbed system serves the root zone published by the IANA with only those structural modifications necessary to ensure that it is able to function usefully in the Yeti testbed system instead of the production Root Server system. In particular, no delegation for any top-level zone is changed, added, or removed from the IANA-published root zone to construct the root zone served by the Yeti testbed system, and changes in the root zone are reflected in the testbed in near real-time. In this document, for clarity, we refer to the zone derived from the IANA-published root zone as the Yeti-Root zone.
根据设计，Yeti试验台系统只需对IANA发布的根区域进行必要的结构修改，以确保其能够在Yeti试验台系统而不是生产根服务器系统中有效运行。特别是，不会更改、添加或删除IANA发布的根区域的任何顶级区域的委托，以构建Yeti测试床系统所服务的根区域，并且根区域中的更改几乎实时反映在测试床中。在本文件中，为清楚起见，我们将源自IANA发布的根区的区域称为雪人根区。
The Yeti DNS testbed serves a similar function to the Root Server system in the sense that they both serve similar zones: the Yeti-Root zone and the IANA-published root zone. However, the Yeti DNS testbed only serves clients that are explicitly configured to participate in the experiment, whereas the Root Server system serves the whole Internet. Since the dependent end-users and systems of the Yeti DNS testbed are known and their operations well-coordinated with those of the Yeti project, it has been possible to deploy structural changes in the Yeti DNS testbed with effective measurement and analysis, something that is difficult or simply impractical in the production Root Server system.
Yeti DNS测试平台与根服务器系统具有类似的功能，因为它们都服务于类似的区域：Yeti根区域和IANA发布的根区域。然而，Yeti DNS测试平台只服务于显式配置为参与实验的客户端，而根服务器系统服务于整个互联网。由于已知Yeti DNS测试床的相关最终用户和系统，且其操作与Yeti项目的操作协调良好，因此可以通过有效的测量和分析在Yeti DNS测试床中部署结构更改，这在生产根服务器系统中是困难的或根本不可行的。
This document describes the motivation for the Yeti project, describes the Yeti testbed infrastructure, and provides the technical and operational experiences of some users of the Yeti testbed. This document neither addresses the relevant policies under which the Root Server system is operated nor makes any proposal for changing any aspect of its implementation or operation.
本文档描述了Yeti项目的动机，描述了Yeti试验台基础设施，并提供了Yeti试验台部分用户的技术和操作经验。本文档既不涉及根服务器系统运行所依据的相关策略，也不建议更改其实现或操作的任何方面。
Through the document, any mention of "Root" with an uppercase "R" and without other prefix, refers to the "IANA Root" systems used in the production Internet. Proper mentions of the Yeti infrastructure will be prefixed with "Yeti", like "Yeti-Root zone", "Yeti DNS", and so on.
在本文件中，任何提到的“Root”都带有大写字母“R”且没有其他前缀，指的是生产互联网中使用的“IANA Root”系统。适当地提及雪人基础设施将以“雪人”作为前缀，如“雪人根区”、“雪人DNS”等。
This section provides some examples of the topics that the developers of the Yeti DNS testbed considered important to address. As noted in Section 1, the Yeti DNS is an independently coordinated project and is not affiliated with the IETF, ICANN, IANA, or any Root Server Operator. Thus, the topics and areas for study were selected by (and for) the proponents of the Yeti project to address their own concerns and in the hope that the information and tools provided would be of wider interest.
本节提供了一些雪人DNS测试平台开发人员认为重要的主题示例。如第1节所述，雪人DNS是一个独立协调的项目，不隶属于IETF、ICANN、IANA或任何根服务器运营商。因此，雪人项目的支持者选择了研究的主题和领域，以解决他们自己的问题，并希望所提供的信息和工具能引起更广泛的兴趣。
Each example included below is illustrated with indicative questions.
下面包含的每个示例都用指示性问题进行了说明。
o How can a testbed be constructed and deployed on the Internet, allowing useful public participation without any risk of disruption of the Root Server system?
o 如何在Internet上构建和部署一个测试平台，允许有用的公众参与，而不存在根服务器系统中断的风险？
o How can representative traffic be introduced into such a testbed such that insights into the impact of specific differences between the testbed and the Root Server system can be observed?
o 如何将具有代表性的流量引入到这样的测试床中，以便观察到测试床和根服务器系统之间特定差异的影响？
o What are the scaling properties of Yeti-Root zone distribution as the number of Yeti-Root servers, Yeti-Root server instances, or intermediate distribution points increases?
o 随着Yeti根服务器、Yeti根服务器实例或中间分发点数量的增加，Yeti根区域分发的扩展特性是什么？
o What naming schemes other than those closely analogous to the use of ROOT-SERVERS.NET in the production root zone are practical, and what are their respective advantages and disadvantages?
o 除了与在生产根区域中使用ROOT-SERVERS.NET非常类似的命名方案外，还有哪些命名方案是实用的，它们各自的优缺点是什么？
o What are the risks and benefits of signing the zone that contains the names of the Yeti-Root servers?
o 签署包含雪人根服务器名称的区域有哪些风险和好处？
o What automatic mechanisms might be useful to improve the rate at which clients of Yeti-Root servers are able to react to a Yeti-Root server renumbering event?
o 哪些自动机制可能有助于提高Yeti根服务器的客户端能够对Yeti根服务器重新编号事件作出反应的速率？
o Are there negative operational effects in the use of IPv6-only Yeti-Root servers, compared to the use of servers that are dual-stack?
o 与使用双栈服务器相比，仅使用IPv6的雪人根服务器是否会对运营产生负面影响？
o What effect does the IPv6 fragmentation model have on the operation of Yeti-Root servers, compared with that of IPv4?
o 与IPv4相比，IPv6分段模型对Yeti根服务器的运行有什么影响？
o Is it practical to sign the Yeti-Root zone using multiple, independently operated DNSSEC signers and multiple corresponding Zone Signing Keys (ZSKs)?
o 使用多个独立操作的DNSSEC签名者和多个相应的区域签名密钥（ZSK）对雪人根区域进行签名是否可行？
o To what extent is [RFC5011] ("Automated Updates of DNS Security (DNSSEC) Trust Anchors") supported by resolvers?
o 解析程序对[RFC5011]（“DNS安全性（DNSSEC）信任锚的自动更新”）的支持程度如何？
o Does the KSK Rollover plan designed and in the process of being implemented by ICANN work as expected on the Yeti testbed?
o 由ICANN设计并正在实施的KSK展期计划是否在雪人试验台上按预期运行？
o What is the operational impact of using much larger RSA key sizes in the ZSKs used in a root?
o 在根目录中使用的zsk中使用更大的RSA密钥会对操作产生什么影响？
o What are the operational consequences of choosing DNSSEC algorithms other than RSA to sign a root?
o 选择除RSA之外的DNSSEC算法对根进行签名会产生什么操作后果？
The purpose of the testbed is to allow DNS queries from stub resolvers, mediated by recursive resolvers, to be delivered to Yeti-Root servers, and for corresponding responses generated on the Yeti-Root servers to be returned, as illustrated in Figure 1.
该测试平台的目的是允许将来自存根解析程序（由递归解析程序介导）的DNS查询传递到Yeti根服务器，并返回Yeti根服务器上生成的相应响应，如图1所示。
,----------. ,-----------. ,------------.
| stub +------> | recursive +------> | Yeti-Root |
| resolver | <------+ resolver | <------+ nameserver |
`----------' `-----------' `------------'
^ ^ ^
| appropriate | Yeti-Root hints; | Yeti-Root zone
`- resolver `- Yeti-Root trust `- with DNSKEY RRset
configured anchor signed by
Yeti-Root KSK
,----------. ,-----------. ,------------.
| stub +------> | recursive +------> | Yeti-Root |
| resolver | <------+ resolver | <------+ nameserver |
`----------' `-----------' `------------'
^ ^ ^
| appropriate | Yeti-Root hints; | Yeti-Root zone
`- resolver `- Yeti-Root trust `- with DNSKEY RRset
configured anchor signed by
Yeti-Root KSK
Figure 1: High-Level Testbed Components
图1：高级测试台组件
To use the Yeti DNS testbed, a recursive resolver must be configured to use the Yeti-Root servers. That configuration consists of a list of names and addresses for the Yeti-Root servers (often referred to as a "hints file") that replaces the corresponding hints used for the production Root Server system (Appendix A). If resolvers are configured to validate DNSSEC, then they also need to be configured with a DNSSEC trust anchor that corresponds to a KSK used in the Yeti DNS Project, in place of the normal trust anchor set used for the Root Zone.
要使用Yeti DNS测试床，必须将递归解析器配置为使用Yeti根服务器。该配置包括Yeti根服务器（通常称为“提示文件”）的名称和地址列表，该列表替换用于生产根服务器系统的相应提示（附录a）。如果将解析程序配置为验证DNSSEC，则还需要使用对应于Yeti DNS项目中使用的KSK的DNSSEC信任锚来配置解析程序，以替代用于根区域的正常信任锚集。
Since the Yeti root(s) are signed with Yeti keys, rather than those used by the IANA Root, corresponding changes are needed in the resolver trust anchors. Corresponding changes are required in the Yeti-Root hints file Appendix A. Those changes would be properly rejected as bogus by any validator using the production Root Server system's root zone trust anchor set.
由于Yeti根使用Yeti密钥签名，而不是IANA根使用的密钥，因此需要在解析器信任锚中进行相应的更改。Yeti根提示文件附录A中需要相应的更改。任何使用生产根服务器系统的根区域信任锚集的验证器都会正确地拒绝这些更改，因为它们是伪造的。
Stub resolvers become part of the Yeti DNS testbed by their use of recursive resolvers that are configured as described above.
存根解析器通过使用如上所述配置的递归解析器成为Yeti DNS测试平台的一部分。
The data flow from IANA to stub resolvers through the Yeti testbed is illustrated in Figure 2 and is described in more detail in the sections that follow.
图2说明了通过Yeti测试台从IANA到存根解析器的数据流，并在后面的章节中进行了更详细的描述。
,----------------.
,-- / IANA Root Zone / ---.
| `----------------' |
| | |
| | | Root Zone
,--------------. ,---V---. ,---V---. ,---V---.
| Yeti Traffic | | BII | | WIDE | | TISF |
| Collection | | DM | | DM | | DM |
`----+----+----' `---+---' `---+---' `---+---'
| | ,-----' ,-------' `----.
| | | | | Yeti-Root
^ ^ | | | Zone
| | ,---V---. ,---V---. ,---V---.
| `---+ Yeti | | Yeti | . . . . . . . | Yeti |
| | Root | | Root | | Root |
| `---+---' `---+---' `---+---'
| | | | DNS
| | | | Response
| ,--V----------V-------------------------V--.
`---------+ Yeti Resolvers |
`--------------------+---------------------'
| DNS
| Response
,--------------------V---------------------.
| Yeti Stub Resolvers |
`------------------------------------------'
,----------------.
,-- / IANA Root Zone / ---.
| `----------------' |
| | |
| | | Root Zone
,--------------. ,---V---. ,---V---. ,---V---.
| Yeti Traffic | | BII | | WIDE | | TISF |
| Collection | | DM | | DM | | DM |
`----+----+----' `---+---' `---+---' `---+---'
| | ,-----' ,-------' `----.
| | | | | Yeti-Root
^ ^ | | | Zone
| | ,---V---. ,---V---. ,---V---.
| `---+ Yeti | | Yeti | . . . . . . . | Yeti |
| | Root | | Root | | Root |
| `---+---' `---+---' `---+---'
| | | | DNS
| | | | Response
| ,--V----------V-------------------------V--.
`---------+ Yeti Resolvers |
`--------------------+---------------------'
| DNS
| Response
,--------------------V---------------------.
| Yeti Stub Resolvers |
`------------------------------------------'
The three coordinators of the Yeti DNS testbed: BII : Beijing Internet Institute WIDE: Widely Integrated Distributed Environment Project TISF: A collaborative engineering and security project by Paul Vixie
雪人DNS试验台的三位协调员：BII：北京互联网研究所范围：广泛集成分布式环境项目TISF：Paul Vixie的协作工程和安全项目
Figure 2: Testbed Data Flow
图2：测试台数据流
Note that the roots are not bound to Distribution Masters (DMs). DMs update their zone on a schedule described in Section 4.1. Each DM that updates the latest zone can notify all roots, so the zone transfer can happen between any DM and any root.
请注意，根不绑定到分发主机（DMs）。DMs按照第4.1节所述的时间表更新其区域。每个更新最新分区的DM都可以通知所有根，因此分区传输可以在任何DM和任何根之间进行。
The Yeti-Root zone is distributed within the Yeti DNS testbed through a set of internal master servers that are referred to as Distribution Masters (DMs). These server elements distribute the Yeti-Root zone to all Yeti-Root servers. The means by which the Yeti DMs construct the Yeti-Root zone for distribution is described below.
Yeti根区域通过一组称为分发主机（DMs）的内部主服务器分布在Yeti DNS测试台内。这些服务器元素将Yeti根区域分发给所有Yeti根服务器。雪人DMs构建雪人根系分布区的方法如下所述。
Since Yeti DNS DMs do not receive DNS NOTIFY [RFC1996] messages from the Root Server system, a polling approach is used to determine when new revisions of the root zone are available from the production Root Server system. Each Yeti DM requests the Root Zone SOA record from a Root server that permits unauthenticated zone transfers of the root zone, and performs a zone transfer from that server if the retrieved value of SOA.SERIAL is greater than that of the last retrieved zone.
由于Yeti DNS DMs不从根服务器系统接收DNS NOTIFY[RFC1996]消息，因此使用轮询方法确定何时可以从生产根服务器系统获得根区域的新版本。每个Yeti DM从根服务器请求根区域SOA记录，该根服务器允许根区域的未经验证的区域传输，如果检索到的SOA.SERIAL值大于上次检索到的区域值，则从该服务器执行区域传输。
At the time of writing, unauthenticated zone transfers of the Root Zone are available directly from B-Root, C-Root, F-Root, G-Root, K-Root, and L-Root; two servers XFR.CJR.DNS.ICANN.ORG and XFR.LAX.DNS.ICANN.ORG; and via FTP from sites maintained by the Root Zone Maintainer and the IANA Functions Operator. The Yeti DNS testbed retrieves the Root Zone using zone transfers from F-Root. The schedule on which F-Root is polled by each Yeti DM is as follows:
在撰写本文时，根区域的未经验证的区域传输可直接从B-Root、C-Root、F-Root、G-Root、K-Root和L-Root获得；两台服务器XFR.CJR.DNS.ICANN.ORG和XFR.LAX.DNS.ICANN.ORG；通过根区域维护人员和IANA功能运营商维护的站点的FTP。Yeti DNS测试床使用来自F-Root的区域传输检索根区域。每个雪人DM轮询F-Root的时间表如下：
+-------------+-----------------------+
| DM Operator | Time |
+-------------+-----------------------+
| BII | UTC hour + 00 minutes |
| WIDE | UTC hour + 20 minutes |
| TISF | UTC hour + 40 minutes |
+-------------+-----------------------+
+-------------+-----------------------+
| DM Operator | Time |
+-------------+-----------------------+
| BII | UTC hour + 00 minutes |
| WIDE | UTC hour + 20 minutes |
| TISF | UTC hour + 40 minutes |
+-------------+-----------------------+
The Yeti DNS testbed uses multiple DMs, each of which acts autonomously and equivalently to its siblings. Any single DM can act to distribute new revisions of the Yeti-Root zone and is also responsible for signing the RRsets that are changed as part of the transformation of the Root Zone into the Yeti-Root zone described in Section 4.2. This multiple DM model intends to provide a basic structure to implement the idea of shared zone control as proposed in [ITI2014].
雪人DNS测试台使用多个DMs，每个DMs都与它的兄弟节点自主地、等效地工作。任何一个DM都可以发布雪人根区的新版本，并且还负责签署作为第4.2节所述将根区转换为雪人根区的一部分而更改的RRSET。该多DM模型旨在提供一个基本结构，以实现[ITI2014]中提出的共享区域控制理念。
Two distinct approaches have been deployed in the Yeti DNS testbed, separately, to transform the Root Zone into the Yeti-Root zone. At a high level, the approaches are equivalent in the sense that they replace a minimal set of information in the root zone with corresponding data for the Yeti DNS testbed; the mechanisms by which the transforms are executed are different, however. The approaches are discussed in Sections 4.2.1 and 4.2.2.
在Yeti DNS测试平台中分别部署了两种不同的方法，以将根区域转换为Yeti根区域。在高层次上，这些方法是等效的，因为它们用雪人DNS试验台的相应数据替换根区域中的最小信息集；然而，执行转换的机制是不同的。第4.2.1节和第4.2.2节讨论了这些方法。
A third approach has also been proposed, but not yet implemented. The motivations and changes implied by that approach are described in Section 4.2.3.
还提出了第三种方法，但尚未实施。第4.2.3节描述了该方法隐含的动机和变化。
The approach described here was the first to be implemented. It features entirely autonomous operation of each DM, but also requires secret key material (the private key in each of the Yeti-Root KSK and ZSK key pairs) to be distributed and maintained on each DM in a coordinated way.
这里描述的方法是第一个实施的方法。它的特点是每个DM完全自主操作，但也要求在每个DM上以协调的方式分发和维护秘密密钥材料（Yeti Root KSK和ZSK密钥对中的私钥）。
The Root Zone is transformed as follows to produce the Yeti-Root zone. This transformation is carried out autonomously on each Yeti DNS Project DM. Each DM carries an authentic copy of the current set of Yeti KSK and ZSK key pairs, synchronized between all DMs (see Section 4.4).
根区按如下方式变换，以生成雪人根区。此转换在每个雪人DNS项目上自动执行。每个DM都携带当前一组Yeti KSK和ZSK密钥对的真实副本，在所有DM之间同步（见第4.4节）。
1. SOA.MNAME is set to www.yeti-dns.org.
1. SOA.MNAME设置为www.yeti-dns.org。
2. SOA.RNAME is set to <dm-operator>.yeti-dns.org, where <dm-operator> is currently one of "wide", "bii", or "tisf".
2. SOA.RNAME设置为<dm operator>.yeti-dns.org，其中<dm operator>当前为“wide”、“bii”或“tisf”之一。
3. All DNSKEY, RRSIG, and NSEC records are removed.
3. 删除所有DNSKEY、RRSIG和NSEC记录。
4. The apex Name Server (NS) RRset is removed, with the corresponding root server glue (A and AAAA) RRsets.
4. 删除apex名称服务器（NS）RRset，并使用相应的根服务器胶水（A和AAAA）RRset。
5. A Yeti DNSKEY RRset is added to the apex, comprising the public parts of all Yeti KSK and ZSKs.
5. 顶点添加了一个雪人DNSKEY RRset，包括所有雪人KSK和ZSK的公共部分。
6. A Yeti NS RRset is added to the apex that includes all Yeti-Root servers.
6. 将Yeti NS RRset添加到包含所有Yeti根服务器的apex中。
7. Glue records (AAAA only, since Yeti-Root servers are v6-only) for all Yeti-Root servers are added.
7. 添加了所有Yeti根服务器的粘合记录（仅AAAA，因为Yeti根服务器仅为v6）。
8. The Yeti-Root zone is signed: the NSEC chain is regenerated; the Yeti KSK is used to sign the DNSKEY RRset; and the shared ZSK is used to sign every other RRset.
8. 雪人根部区域被标记：NSEC链被再生；雪人KSK用于签署DNSKEY RRset；共享的ZSK用于对其他RRset进行签名。
Note that the SOA.SERIAL value published in the Yeti-Root zone is identical to that found in the root zone.
请注意，在Yeti根区域中发布的SOA.SERIAL值与在根区域中发现的值相同。
The approach described here was the second to be implemented and maintained as stable state. Each DM is provisioned with its own, dedicated ZSK key pairs that are not shared with other DMs. A Yeti-Root DNSKEY RRset is constructed and signed upstream of all DMs as the union of the set of active Yeti-Root KSKs and the set of active ZSKs for every individual DM. Each DM now only requires the secret
这里描述的方法是第二种被实现并保持为稳定状态的方法。每个DM都配置有自己的专用ZSK密钥对，这些密钥对不与其他DM共享。构建雪人根DNSKEY RRset，并在所有DM的上游签名，作为每个DM的活动雪人根KSK集和活动ZSK集的并集。每个DM现在只需要这个秘密
part of its own dedicated ZSK key pairs to be available locally, and no other secret key material is shared. The high-level approach is illustrated in Figure 3.
它自己的专用ZSK密钥对的一部分将在本地可用，并且不会共享其他密钥材料。高级方法如图3所示。
,----------. ,-----------.
.--------> BII ZSK +---------> Yeti-Root |
| signs `----------' signs `-----------'
|
,-----------. | ,----------. ,-----------.
| Yeti KSK +-+--------> TISF ZSK +---------> Yeti-Root |
`-----------' | signs `----------' signs `-----------'
|
| ,----------. ,-----------.
`--------> WIDE ZSK +---------> Yeti-Root |
signs `----------' signs `-----------'
,----------. ,-----------.
.--------> BII ZSK +---------> Yeti-Root |
| signs `----------' signs `-----------'
|
,-----------. | ,----------. ,-----------.
| Yeti KSK +-+--------> TISF ZSK +---------> Yeti-Root |
`-----------' | signs `----------' signs `-----------'
|
| ,----------. ,-----------.
`--------> WIDE ZSK +---------> Yeti-Root |
signs `----------' signs `-----------'
Figure 3: Unique ZSK per DM
图3：每个DM的唯一ZSK
The process of retrieving the Root Zone from the Root Server system and replacing and signing the apex DNSKEY RRset no longer takes place on the DMs; instead, it takes place on a central Hidden Master. The production of signed DNSKEY RRsets is analogous to the use of Signed Key Responses (SKRs) produced during ICANN KSK key ceremonies [ICANN2010].
从根服务器系统检索根区域并替换和签署apex DNSKEY RRset的过程不再在DMs上进行；相反，它发生在一个中央隐藏主控台上。签名DNSKEY RRSET的生成与ICANN KSK密钥仪式期间生成的签名密钥响应（SKR）的使用类似[ICANN2010]。
Each DM now retrieves source data (with a premodified and Yeti-signed DNSKEY RRset, but otherwise unchanged) from the Yeti DNS Hidden Master instead of from the Root Server system.
现在，每个DM从Yeti DNS隐藏主机而不是从根服务器系统检索源数据（使用经过预修改和Yeti签名的DNSKEY RRset，但在其他方面保持不变）。
Each DM carries out a similar transformation to that described in Section 4.2.1, except that DMs no longer need to modify or sign the DNSKEY RRset, and the DM's unique local ZSK is used to sign every other RRset.
每个DM执行与第4.2.1节所述类似的转换，但DM不再需要修改或签署DNSKEY RRset，并且DM的唯一本地ZSK用于签署其他每个RRset。
A change to the transformation described in Section 4.2.2 has been proposed as a Yeti experiment called PINZ [PINZ], which would preserve the NSEC chain from the Root Zone and all RRSIG RRs generated using the Root Zone's ZSKs. The DNSKEY RRset would continue to be modified to replace the Root Zone KSKs, but Root Zone ZSKs would be kept intact, and the Yeti KSK would be used to generate replacement signatures over the apex DNSKEY and NS RRsets. Source data would continue to flow from the Root Server system through the Hidden Master to the set of DMs, but no DNSSEC operations would be required on the DMs, and the source NSEC and most RRSIGs would remain intact.
第4.2.2节中描述的转换的变更被提议为一个名为PINZ[PINZ]的雪人实验，该实验将保留根区的NSEC链以及使用根区的ZSK生成的所有RRSIG RRs。DNSKEY RRK集将继续修改以替换根区KSK，但根区ZSK将保持不变，而雪人KSK将用于生成顶点DNSKEY和NS RRK集上的替换签名。源数据将继续从根服务器系统通过隐藏主机流向DMs集，但DMs上不需要DNSSEC操作，并且源NSEC和大多数RRSIG将保持不变。
This approach has been suggested in order to keep minimal changes from the IANA Root zone and provide cryptographically verifiable confidence that no owner name in the root zone had been changed in the process of producing the Yeti-Root zone from the Root Zone, thereby addressing one of the concerns described in Appendix E in a way that can be verified automatically.
提出这种方法是为了保持IANA根区的最小变化，并提供加密验证的信心，即在根区生产雪人根区的过程中，根区中没有所有者名称发生变化，从而以可自动验证的方式解决附录E中描述的问题之一。
Each Yeti DM is configured with a full list of Yeti-Root server addresses to send NOTIFY [RFC1996] messages to. This also forms the basis for an address-based access-control list for zone transfers. Authentication by address could be replaced with more rigorous mechanisms (e.g., using Transaction Signatures (TSIGs) [RFC2845]). This has not been done at the time of writing since the use of address-based controls avoids the need for the distribution of shared secrets amongst the Yeti-Root server operators.
每个Yeti DM都配置了一个完整的Yeti根服务器地址列表，用于向其发送通知[RFC1996]消息。这也构成了区域传输基于地址的访问控制列表的基础。可以用更严格的机制（例如，使用事务签名（TSIGs）[RFC2845]）代替地址认证。由于使用基于地址的控件避免了在Yeti根服务器操作员之间分发共享机密的需要，因此在编写本文时还没有这样做。
Individual Yeti-Root servers are configured with a full set of Yeti DM addresses to which SOA and AXFR queries may be sent in the conventional manner.
单个Yeti根服务器配置有一整套Yeti DM地址，SOA和AXFR查询可以以传统方式发送到这些地址。
Changes in the Yeti DNS testbed infrastructure such as the addition or removal of Yeti-Root servers, renumbering Yeti-Root servers, or DNSSEC key rollovers require coordinated changes to take place on all DMs. The Yeti DNS testbed is subject to more frequent changes than are observed in the Root Server system and includes substantially more Yeti-Root servers than there are IANA Root Servers, and hence a manual change process in the Yeti testbed would be more likely to suffer from human error. An automated and cooperative process was consequently implemented.
Yeti DNS测试平台基础设施的更改，如添加或删除Yeti根服务器、重新编号Yeti根服务器或DNSSEC密钥滚动，需要在所有DMs上进行协调更改。与根服务器系统相比，Yeti DNS测试床的更改频率更高，并且包含的Yeti根服务器数量远远超过IANA根服务器数量，因此Yeti测试床中的手动更改过程更有可能出现人为错误。因此，实施了一个自动化和协作的过程。
The theory of this operation is that each DM operator runs a Git repository locally, containing all service metadata involved in the operation of each DM. When a change is desired and approved among all Yeti coordinators, one DM operator (usually BII) updates the local Git repository. A serial number in the future (in two days) is chosen for when the changes become active. The DM operator then pushes the changes to the Git repositories of the other two DM operators who have a chance to check and edit the changes. When the serial number of the root zone passes the number chosen, the changes are pulled automatically to individual DMs and promoted to production.
此操作的原理是，每个DM操作员在本地运行一个Git存储库，其中包含每个DM操作中涉及的所有服务元数据。当需要在所有Yeti协调员之间进行更改并获得批准时，一个DM操作员（通常是BII）会更新本地Git存储库。当更改激活时，将选择未来（两天内）的序列号。然后，DM操作员将更改推送到另外两个DM操作员的Git存储库，这两个DM操作员有机会检查和编辑更改。当根区域的序列号超过所选的编号时，更改将自动拉至各个DMs并升级到生产。
The three Git repositories are synchronized by configuring them as remote servers. For example, at BII we push to all three DMs' repositories as follows:
通过将这三个Git存储库配置为远程服务器来同步它们。例如，在BII，我们将所有三个DMs存储库推送到如下位置：
$ git remote -v
origin yeticonf@yeti-conf.dns-lab.net:dm (fetch)
origin yeticonf@yeti-conf.dns-lab.net:dm (push)
origin yeticonf@yeti-dns.tisf.net:dm (push)
origin yeticonf@yeti-repository.wide.ad.jp:dm (push)
$ git remote -v
origin yeticonf@yeti-conf.dns-lab.net:dm (fetch)
origin yeticonf@yeti-conf.dns-lab.net:dm (push)
origin yeticonf@yeti-dns.tisf.net:dm (push)
origin yeticonf@yeti-repository.wide.ad.jp:dm (push)
For more detailed information on DM synchronization, please see this document in Yeti's GitHub repository: <https://github.com/BII-Lab/ Yeti-Project/blob/master/doc/Yeti-DM-Sync.md>.
有关DM同步的更多详细信息，请参阅Yeti的GitHub存储库中的此文档：<https://github.com/BII-Lab/ 雪人项目/blob/master/doc/Yeti DM Sync.md>。
The current naming scheme for Root Servers was normalized to use single-character host names ("A" through "M") under the domain ROOT-SERVERS.NET, as described in [RSSAC023]. The principal benefit of this naming scheme was that DNS label compression could be used to produce a priming response that would fit within 512 bytes at the time it was introduced, where 512 bytes is the maximum DNS message size using UDP transport without EDNS(0) [RFC6891].
如[RSSAC023]所述，根服务器的当前命名方案已规范化，在域Root-Servers.NET下使用单字符主机名（“A”到“M”）。此命名方案的主要好处是，DNS标签压缩可用于产生启动响应，该响应在引入时可容纳512字节，其中512字节是使用UDP传输（不含EDN）的最大DNS消息大小（0）[RFC6891]。
Yeti-Root servers do not use this optimization, but rather use free-form nameserver names chosen by their respective operators -- in other words, no attempt is made to minimize the size of the priming response through the use of label compression. This approach aims to challenge the need to minimize the priming response in a modern DNS ecosystem where EDNS(0) is prevalent.
Yeti根服务器不使用这种优化，而是使用由各自操作员选择的自由格式名称服务器名称——换句话说，没有尝试通过使用标签压缩来最小化启动响应的大小。这种方法旨在挑战在EDNS（0）盛行的现代DNS生态系统中最小化启动响应的需要。
Priming responses from Yeti-Root servers (unlike those from Root Servers) do not always include server addresses in the additional section. In particular, Yeti-Root servers running BIND9 return an empty additional section if the configuration parameter "minimum-responses" is set, forcing resolvers to complete the priming process with a set of conventional recursive lookups in order to resolve addresses for each Yeti-Root server. The Yeti-Root servers running NSD were observed to return a fully populated additional section (depending, of course, on the EDNS buffer size in use).
来自Yeti根服务器的启动响应（与来自根服务器的响应不同）并不总是在附加部分中包含服务器地址。特别是，如果设置了配置参数“minimum responses”，则运行BIND9的Yeti根服务器将返回一个空的附加部分，从而迫使解析程序通过一组传统的递归查找来完成启动过程，以便解析每个Yeti根服务器的地址。观察到运行NSD的Yeti根服务器返回一个完全填充的附加部分（当然，这取决于使用的EDNS缓冲区大小）。
Various approaches to normalize the composition of the priming response were considered, including:
考虑了使启动反应成分正常化的各种方法，包括：
o Require use of DNS implementations that exhibit a desired behavior in the priming response.
o 要求使用在启动响应中表现出所需行为的DNS实现。
o Modify nameserver software or configuration as used by Yeti-Root servers.
o 修改Yeti根服务器使用的名称服务器软件或配置。
o Isolate the names of Yeti-Root servers in one or more zones that could be slaved on each Yeti-Root server, renaming servers as necessary, giving each a source of authoritative data with which the authority section of a priming response could be fully populated. This is the approach used in the Root Server system with the ROOT-SERVERS.NET zone.
o 隔离一个或多个区域中Yeti根服务器的名称，这些区域可以在每个Yeti根服务器上使用，必要时重命名服务器，为每个服务器提供一个权威数据源，可以完全填充启动响应的权威部分。这是根服务器系统和Root-SERVERS.NET区域中使用的方法。
The potential mitigation of renaming all Yeti-Root servers using a scheme that would allow their names to exist directly in the root zone was not considered because that approach implies the invention of new top-level labels not present in the Root Zone.
未考虑使用允许其名称直接存在于根区域的方案重命名所有Yeti根服务器的潜在缓解措施，因为该方法意味着发明根区域中不存在的新顶级标签。
Given the relative infrequency of priming queries by individual resolvers and the additional complexity or other compromises implied by each of those mitigations, the decision was made to make no effort to ensure that the composition of priming responses was identical across servers. Even the empty additional sections generated by Yeti-Root servers running BIND9 seem to be sufficient for all resolver software tested; resolvers simply perform a new recursive lookup for each authoritative server name they need to resolve.
考虑到个别解析程序引发查询的频率相对较低，以及这些缓解措施所隐含的额外复杂性或其他折衷，因此决定不努力确保引发响应的组成在服务器上是相同的。即使是运行BIND9的Yeti根服务器生成的空附加部分似乎也足以满足所有测试的解析器软件；解析程序只需对需要解析的每个权威服务器名称执行新的递归查找。
Various volunteers have donated authoritative servers to act as Yeti-Root servers. At the time of writing, there are 25 Yeti-Root servers distributed globally, one of which is named using a label as specified in IDNA2008 [RFC5890] (it is shown in the following list in punycode).
各种志愿者捐赠了权威服务器作为雪人根服务器。在撰写本文时，全球分布着25台雪人根服务器，其中一台使用IDNA2008[RFC5890]中指定的标签命名（如以下punycode列表所示）。
+-------------------------------------+---------------+-------------+
| Name | Operator | Location |
+-------------------------------------+---------------+-------------+
| bii.dns-lab.net | BII | CHINA |
| yeti-ns.tsif.net | TSIF | USA |
| yeti-ns.wide.ad.jp | WIDE Project | Japan |
| yeti-ns.as59715.net | as59715 | Italy |
| dahu1.yeti.eu.org | Dahu Group | France |
| ns-yeti.bondis.org | Bond Internet | Spain |
| | Systems | |
| yeti-ns.ix.ru | Russia | MSK-IX |
| yeti.bofh.priv.at | CERT Austria | Austria |
| yeti.ipv6.ernet.in | ERNET India | India |
| yeti-dns01.dnsworkshop.org | dnsworkshop | Germany |
| | /informnis | |
| dahu2.yeti.eu.org | Dahu Group | France |
| yeti.aquaray.com | Aqua Ray SAS | France |
| yeti-ns.switch.ch | SWITCH | Switzerland |
| yeti-ns.lab.nic.cl | NIC Chile | Chile |
| yeti-ns1.dns-lab.net | BII | China |
| yeti-ns2.dns-lab.net | BII | China |
| yeti-ns3.dns-lab.net | BII | China |
| ca...a23dc.yeti-dns.net | Yeti-ZA | South |
| | | Africa |
| 3f...374cd.yeti-dns.net | Yeti-AU | Australia |
| yeti1.ipv6.ernet.in | ERNET India | India |
| xn--r2bi1c.xn--h2bv6c0a.xn--h2brj9c | ERNET India | India |
| yeti-dns02.dnsworkshop.org | dnsworkshop | USA |
| | /informnis | |
| yeti.mind-dns.nl | Monshouwer | Netherlands |
| | Internet | |
| | Diensten | |
| yeti-ns.datev.net | DATEV | Germany |
| yeti.jhcloos.net. | jhcloos | USA |
+-------------------------------------+---------------+-------------+
+-------------------------------------+---------------+-------------+
| Name | Operator | Location |
+-------------------------------------+---------------+-------------+
| bii.dns-lab.net | BII | CHINA |
| yeti-ns.tsif.net | TSIF | USA |
| yeti-ns.wide.ad.jp | WIDE Project | Japan |
| yeti-ns.as59715.net | as59715 | Italy |
| dahu1.yeti.eu.org | Dahu Group | France |
| ns-yeti.bondis.org | Bond Internet | Spain |
| | Systems | |
| yeti-ns.ix.ru | Russia | MSK-IX |
| yeti.bofh.priv.at | CERT Austria | Austria |
| yeti.ipv6.ernet.in | ERNET India | India |
| yeti-dns01.dnsworkshop.org | dnsworkshop | Germany |
| | /informnis | |
| dahu2.yeti.eu.org | Dahu Group | France |
| yeti.aquaray.com | Aqua Ray SAS | France |
| yeti-ns.switch.ch | SWITCH | Switzerland |
| yeti-ns.lab.nic.cl | NIC Chile | Chile |
| yeti-ns1.dns-lab.net | BII | China |
| yeti-ns2.dns-lab.net | BII | China |
| yeti-ns3.dns-lab.net | BII | China |
| ca...a23dc.yeti-dns.net | Yeti-ZA | South |
| | | Africa |
| 3f...374cd.yeti-dns.net | Yeti-AU | Australia |
| yeti1.ipv6.ernet.in | ERNET India | India |
| xn--r2bi1c.xn--h2bv6c0a.xn--h2brj9c | ERNET India | India |
| yeti-dns02.dnsworkshop.org | dnsworkshop | USA |
| | /informnis | |
| yeti.mind-dns.nl | Monshouwer | Netherlands |
| | Internet | |
| | Diensten | |
| yeti-ns.datev.net | DATEV | Germany |
| yeti.jhcloos.net. | jhcloos | USA |
+-------------------------------------+---------------+-------------+
The current list of Yeti-Root servers is made available to a participating resolver first using a substitute hints file Appendix A and subsequently by the usual resolver priming process [RFC8109]. All Yeti-Root servers are IPv6-only, because of the IPv6-only Internet of the foreseeable future, and hence the Yeti-Root hints file contains no IPv4 addresses and the Yeti-Root zone contains no IPv4 glue records. Note that the rationale of an IPv6-only testbed is to test whether an IPv6-only root can survive any problem or impact when IPv4 is turned off, much like the context of the IETF SUNSET4 WG [SUNSET4].
当前的Yeti根服务器列表首先使用替代提示文件附录a提供给参与的冲突解决程序，然后通过通常的冲突解决程序启动过程提供[RFC8109]。所有Yeti根服务器都是仅限IPv6的，因为在可预见的未来只有IPv6的Internet，因此Yeti根提示文件不包含IPv4地址，Yeti根区域不包含IPv4胶水记录。请注意，纯IPv6测试床的基本原理是测试当IPv4关闭时，纯IPv6根目录是否能够经受住任何问题或影响，这与IETF SUNSET4 WG[SUNSET4]的上下文非常相似。
At the time of writing, all root servers within the Root Server system serve the ROOT-SERVERS.NET zone in addition to the root zone, and all but one also serve the ARPA zone. Yeti-Root servers serve the Yeti-Root zone only.
在撰写本文时，根服务器系统中的所有根服务器都为根服务器.NET区域提供服务，除了根区域外，其他所有根服务器都为ARPA区域提供服务。雪人根服务器仅服务于雪人根区域。
Significant software diversity exists across the set of Yeti-Root servers, as reported by their volunteer operators at the time of writing:
正如他们的志愿者操作员在撰写本文时所报告的那样，Yeti根服务器组中存在着显著的软件多样性：
o Platform: 18 of 25 Yeti-Root servers are implemented on a Virtual Private Server (VPS) rather than bare metal.
o 平台：25个Yeti根服务器中有18个是在虚拟专用服务器（VPS）上实现的，而不是在裸机上实现的。
o Operating System: 15 Yeti-Root servers run on Linux (Ubuntu, Debian, CentOS, Red Hat, and ArchLinux); 4 run on FreeBSD; 1 on NetBSD; and 1 on Windows Server 2016.
o 操作系统：15台Yeti根服务器在Linux上运行（Ubuntu、Debian、CentOS、Red Hat和ArchLinux）；4在FreeBSD上运行；1关于NetBSD；Windows Server 2016上有1个。
o DNS software: 16 of 25 Yeti-Root servers use BIND9 (versions varying between 9.9.7 and 9.10.3); 4 use NSD (4.10 and 4.15); 2 use Knot (2.0.1 and 2.1.0); 1 uses Bundy (1.2.0); 1 uses PowerDNS (4.1.3); and 1 uses MS DNS (10.0.14300.1000).
o DNS软件：25个雪人根服务器中有16个使用BIND9（版本在9.9.7和9.10.3之间变化）；4使用NSD（4.10和4.15）；2使用结（2.0.1和2.1.0）；1使用邦迪（1.2.0）；1使用PowerDNS（4.1.3）；1使用MS DNS（10.0.14300.1000）。
For the Yeti DNS testbed to be useful as a platform for experimentation, it needs to carry statistically representative traffic. Several approaches have been taken to load the system with traffic, including both real-world traffic triggered by end-users and synthetic traffic.
为了使Yeti DNS测试平台能够用作实验平台，它需要承载具有统计代表性的流量。已经采取了几种方法向系统加载流量，包括由最终用户触发的真实世界流量和合成流量。
Resolvers that have been explicitly configured to participate in the testbed, as described in Section 4, are a source of real-world, end-user traffic. Due to an efficient cache mechanism, the mean query rate is less than 100 qps in the Yeti testbed, but a variety of sources were observed as active during 2017, as summarized in Appendix C.
如第4节所述，已明确配置为参与测试床的解析器是真实世界最终用户流量的来源。由于高效的缓存机制，Yeti试验台的平均查询率低于100 qps，但2017年期间观察到各种来源活跃，如附录C所总结。
Synthetic traffic has been introduced to the system from time to time in order to increase traffic loads. Approaches include the use of distributed measurement platforms such as RIPE ATLAS to send DNS queries to Yeti-Root servers and the capture of traffic (sent from non-Yeti resolvers to the Root Server system) that was subsequently modified and replayed towards Yeti-Root servers.
为了增加交通负荷，系统不时引入合成交通。方法包括使用分布式测量平台（如成熟的ATLAS）向Yeti根服务器发送DNS查询，以及捕获流量（从非Yeti解析程序发送到根服务器系统），随后对Yeti根服务器进行修改和重播。
Traffic capture of queries and responses is available in the testbed in both Yeti resolvers and Yeti-Root servers in anticipation of experiments that require packet-level visibility into DNS traffic.
在Yeti解析程序和Yeti根服务器的测试床上都可以获得查询和响应的流量捕获，以预期需要对DNS流量进行数据包级可见性的实验。
Traffic capture is performed on Yeti-Root servers using either
流量捕获在Yeti根服务器上执行，使用
o dnscap <https://www.dns-oarc.net/tools/dnscap> or
o dnscap<https://www.dns-oarc.net/tools/dnscap>或
o pcapdump, part of the pcaputils Debian package <https://packages.debian.org/sid/pcaputils>, with a patch to facilitate triggered file upload (see <https://bugs.debian.org/ cgi-bin/bugreport.cgi?bug=545985>).
o pcapdump，pcaputils Debian包的一部分<https://packages.debian.org/sid/pcaputils>，带有便于触发文件上载的修补程序（请参阅<https://bugs.debian.org/ cgi-bin/bugreport.cgi？bug=545985>）。
PCAP-format files containing packet captures are uploaded using rsync to central storage.
包含数据包捕获的PCAP格式文件使用rsync上传到中央存储器。
The following sections provide commentary on the operation and impact analyses of the Yeti DNS testbed described in Section 4. More detailed descriptions of observed phenomena are available in the Yeti DNS mailing list archives <http://lists.yeti-dns.org/pipermail/ discuss/> and on the Yeti DNS blog <https://yeti-dns.org/blog.html>.
以下各节对第4节中描述的雪人DNS试验台的运行和影响分析进行了说明。雪人DNS邮件列表档案中提供了观察到的现象的更详细描述<http://lists.yeti-dns.org/pipermail/ 在雪人DNS博客上讨论/>和<https://yeti-dns.org/blog.html>.
All Yeti-Root servers were deployed with IPv6 connectivity, and no IPv4 addresses for any Yeti-Root server were made available (e.g., in the Yeti hints file or in the DNS itself). This implementation decision constrained the Yeti-Root system to be v6 only.
所有Yeti根服务器都部署了IPv6连接，并且没有提供任何Yeti根服务器的IPv4地址（例如，在Yeti提示文件或DNS本身中）。此实施决策将Yeti根系统限制为仅v6。
DNS implementations are generally adept at using both IPv4 and IPv6 when both are available. Servers that cannot be reliably reached over one protocol might be better queried over the other, to the benefit of end-users in the common case where DNS resolution is on the critical path for end-users' perception of performance. However, this optimization also means that systemic problems with one protocol can be masked by the other. By forcing all traffic to be carried over IPv6, the Yeti DNS testbed aimed to expose any such problems and make them easier to identify and understand. Several examples of IPv6-specific phenomena observed during the operation of the testbed are described in the sections that follow.
DNS实现通常擅长在IPv4和IPv6都可用时同时使用。在DNS解析位于最终用户感知性能的关键路径上的常见情况下，通过一种协议无法可靠访问的服务器可能比通过另一种协议更好地查询，以利于最终用户。然而，这种优化也意味着一个协议的系统性问题可以被另一个协议掩盖。通过强制所有流量通过IPv6传输，Yeti DNS测试平台旨在暴露任何此类问题，并使其更易于识别和理解。在测试台运行期间观察到的IPv6特定现象的几个示例在下面的部分中进行了描述。
Although the Yeti-Root servers themselves were only reachable using IPv6, real-world end-users often have no IPv6 connectivity. The testbed was also able to explore the degree to which IPv6-only Yeti-Root servers were able to serve single-stack, IPv4-only end-user populations through the use of dual-stack Yeti resolvers.
虽然Yeti根服务器本身只能通过IPv6访问，但现实世界的最终用户通常没有IPv6连接。该测试平台还能够通过使用双栈Yeti解析器，探索仅IPv6的Yeti根服务器能够在多大程度上为单栈、仅IPv4的最终用户群体提供服务。
In the Root Server system, structural changes with the potential to increase response sizes (and hence fragmentation, fallback to TCP transport, or both) have been exercised with great care, since the impact on clients has been difficult to predict or measure. The Yeti DNS testbed is experimental and has the luxury of a known client base, making it far easier to make such changes and measure their impact.
在根服务器系统中，由于对客户端的影响很难预测或测量，因此对可能增加响应大小（从而导致碎片、回退到TCP传输或两者）的结构更改进行了非常谨慎的操作。雪人DNS测试平台是实验性的，拥有已知客户群的优势，使得进行此类更改和测量其影响变得更加容易。
Many of the experimental design choices described in this document were expected to trigger larger responses. For example, the choice of naming scheme for Yeti-Root servers described in Section 4.5 defeats label compression. It makes a large priming response (up to 1754 octets with 25 NS records and their corresponding glue records); the Yeti-Root zone transformation approach described in Section 4.2.2 greatly enlarges the apex DNSKEY RRset especially during the KSK rollover (up to 1975 octets with 3 ZSKs and 2 KSKs). Therefore, an increased incidence of fragmentation was expected.
本文件中描述的许多实验设计选择预计会触发更大的响应。例如，第4.5节中描述的Yeti根服务器命名方案的选择会破坏标签压缩。它产生了巨大的启动响应（多达1754个八位组，有25个NS记录和相应的胶水记录）；第4.2.2节中描述的雪人根区转换方法极大地扩大了apex DNSKEY RRset，特别是在KSK翻转期间（最多1975个八位组，具有3个ZSK和2个KSK）。因此，预计碎片化的发生率会增加。
The Yeti DNS testbed provides service on IPv6 only. However, middleboxes (such as firewalls and some routers) are not friendly on IPv6 fragments. There are reports of a notable packet drop rate due to the mistreatment of middleboxes on IPv6 fragments [FRAGDROP] [RFC7872]. One APNIC study [IPv6-frag-DNS] reported that 37% of endpoints using IPv6-capable DNS resolvers cannot receive a fragmented IPv6 response over UDP.
Yeti DNS测试平台仅在IPv6上提供服务。但是，中间盒（如防火墙和一些路由器）对IPv6片段不友好。有报道称，由于IPv6碎片上的中间盒受到虐待[FRAGDROP][RFC7872]，数据包丢失率显著。APNIC的一项研究[IPv6 frag DNS]报告说，使用支持IPv6的DNS解析器的端点中有37%无法通过UDP接收分段IPv6响应。
To study the impact, RIPE Atlas probes were used. For each Yeti-Root server, an Atlas measurement was set up using 100 IPv6-enabled probes from five regions, sending a DNS query for "./IN/DNSKEY" using UDP transport with DO=1. This measurement, when carried out concurrently with a Yeti KSK rollover, further exacerbating the potential for fragmentation, identified a 7% failure rate compared with a non-fragmented control. A failure rate of 2% was observed with response sizes of 1414 octets, which was surprising given the expected prevalence of 1500-octet (Ethernet-framed) MTUs.
为了研究影响，使用了成熟的Atlas探针。对于每个Yeti根服务器，使用来自五个地区的100个启用IPv6的探测器建立Atlas测量，使用UDP传输发送对“/IN/DNSKEY”的DNS查询，DO=1。当与Yeti KSK翻滚同时进行时，进一步加剧了碎片的可能性，与非碎片控制相比，该测量确定了7%的故障率。当响应大小为1414个八位字节时，观察到故障率为2%，考虑到1500个八位字节（以太网帧）MTU的预期流行率，这是令人惊讶的。
The consequences of fragmentation were not limited to failures in delivering DNS responses over UDP transport. There were two cases where a Yeti-Root server failed when using TCP to transfer the Yeti-Root zone from a DM. DM log files revealed "socket is not connected" errors corresponding to zone transfer requests. Further experimentation revealed that combinations of NetBSD 6.1, NetBSD 7.0RC1, FreeBSD 10.0, Debian 3.2, and VMWare ESXI 5.5 resulted in a high TCP Maximum Segment Size (MSS) value of 1440 octets being negotiated between client and server despite the presence of the IPV6_USE_MIN_MTU socket option, as described in [USE_MIN_MTU]. The
碎片化的后果不仅限于通过UDP传输传递DNS响应的失败。有两种情况下，Yeti根服务器在使用TCP从DM传输Yeti根区域时失败。DM日志文件显示与区域传输请求对应的“套接字未连接”错误。进一步的实验表明，NetBSD 6.1、NetBSD 7.0RC1、FreeBSD 10.0、Debian 3.2和VMWare ESXI 5.5的组合导致客户端和服务器之间协商的高TCP最大段大小（MSS）值为1440个八位字节，尽管存在IPV6_USE_MIN_MTU套接字选项，如[USE_MIN_MTU]中所述。这个
mismatch appears to cause outbound segments of a size greater than 1280 octets to be dropped before sending. Setting the local TCP MSS to 1220 octets (chosen as 1280 - 60, the size of the IPv6 TCP header with no other extension headers) was observed to be a pragmatic mitigation.
不匹配似乎会导致发送前删除大小大于1280个八位字节的出站段。将本地TCP MSS设置为1220个八位字节（选择为1280-60，IPv6 TCP头的大小没有其他扩展头）被认为是一种实用的缓解措施。
Yeti resolvers have been successfully used by real-world end-users for general name resolution within a number of participant organizations, including resolution of names to IPv4 addresses and resolution by IPv4-only end-user devices.
Yeti解析器已成功地被现实世界的最终用户用于许多参与组织内的通用名称解析，包括将名称解析为IPv4地址和仅IPv4的最终用户设备解析。
Some participants, recognizing the operational importance of reliability in resolver infrastructure and concerned about the stability of their IPv6 connectivity, chose to deploy Yeti resolvers in parallel to conventional resolvers, making both available to end-users. While the viability of this approach provides a useful data point, end-users using Yeti resolvers exclusively provided a better opportunity to identify and understand any failures in the Yeti DNS testbed infrastructure.
一些与会者认识到冲突解决程序基础设施可靠性的操作重要性，并担心其IPv6连接的稳定性，因此选择与传统冲突解决程序并行部署Yeti冲突解决程序，以便最终用户能够使用这两种解决方案。虽然这种方法的可行性提供了有用的数据点，但专门使用Yeti解析器的最终用户提供了更好的机会来识别和理解Yeti DNS测试平台基础设施中的任何故障。
Resolvers deployed in IPv4-only environments were able to join the Yeti DNS testbed by way of upstream, dual-stack Yeti resolvers. In one case (CERNET2), this was done by assigning IPv4 addresses to Yeti-Root servers and mapping them in dual-stack IVI translation devices [RFC6219].
部署在仅IPv4环境中的解析程序能够通过上游双堆栈Yeti解析程序加入Yeti DNS测试平台。在一个案例（CERNET2）中，这是通过将IPv4地址分配给Yeti根服务器并将其映射到双堆栈IVI转换设备[RFC6219]来实现的。
The Yeti DNS testbed makes use of multiple DMs to distribute the Yeti-Root zone, an approach that would allow the number of Yeti-Root servers to scale to a higher number than could be supported by a single distribution source and that provided redundancy. The use of multiple DMs introduced some operational challenges, however, which are described in the following sections.
Yeti DNS测试台使用多个DMs来分发Yeti根区域，这种方法允许Yeti根服务器的数量扩展到比单个分发源支持的数量更高的数量，并提供冗余。然而，多个DMs的使用带来了一些操作挑战，这些挑战将在以下章节中描述。
Yeti-Root servers were configured to serve the Yeti-Root zone as slaves. Each slave had all DMs configured as masters, providing redundancy in zone synchronization.
雪人根服务器配置为作为从属服务器服务雪人根区域。每个从机都将所有DMs配置为主机，从而在区域同步中提供冗余。
Each DM in the Yeti testbed served a Yeti-Root zone that was functionally equivalent but not congruent to that served by every other DM (see Section 4.3). The differences included variations in the SOA.MNAME field and, more critically, in the RRSIGs for everything other than the apex DNSKEY RRset, since signatures for all
雪人试验台中的每个DM提供的雪人根区功能等同，但与其他DM提供的功能不一致（见第4.3节）。这些差异包括SOA.MNAME字段中的变化，更重要的是，除了apex DNSKEY RRset之外的所有内容的RRSIG中都有变化，因为签名代表所有人
other RRsets are generated using a private key that is only available to the DM serving its particular variant of the zone (see Sections 4.2.1 and 4.2.2).
其他RRSET使用私钥生成，该私钥仅适用于为其特定区域变体服务的DM（见第4.2.1和4.2.2节）。
Incremental Zone Transfer (IXFR), as described in [RFC1995], is a viable mechanism to use for zone synchronization between any Yeti-Root server and a consistent, single DM. However, if that Yeti-Root server ever selected a different DM, IXFR would no longer be a safe mechanism; structural changes between the incongruent zones on different DMs would not be included in any transferred delta, and the result would be a zone that was not internally self-consistent. For this reason, the first transfer after a change of DM would require AXFR not IXFR.
如[RFC1995]所述，增量区域传输（IXFR）是一种可行的机制，可用于任何Yeti根服务器和一致的单个DM之间的区域同步。然而，如果雪人根服务器选择了不同的DM，IXFR将不再是一种安全机制；不同DMs上不一致区域之间的结构变化不会包含在任何转移三角洲中，其结果将是一个内部不一致的区域。因此，更改DM后的第一次传输将需要AXFR而不是IXFR。
None of the DNS software in use on Yeti-Root servers supports this mixture of IXFR/AXFR according to the master server in use. This is unsurprising, given that the environment described above in the Yeti-Root system is idiosyncratic; conventional zone transfer graphs involve zones that are congruent between all nodes. For this reason, all Yeti-Root servers are configured to use AXFR at all times, and never IXFR, to ensure that zones being served are internally self-consistent.
根据所使用的主服务器，在Yeti根服务器上使用的DNS软件都不支持这种IXFR/AXFR的混合。这并不奇怪，因为上述雪人根系的环境是特殊的；传统的区域转移图涉及所有节点之间一致的区域。因此，所有Yeti根服务器都配置为始终使用AXFR，而不是IXFR，以确保所服务的区域在内部是自一致的。
Each Yeti DM polled the Root Server system for a new revision of the root zone on an interleaved schedule, as described in Section 4.1. Consequently, different DMs were expected to retrieve each revision of the root zone, and make a corresponding revision of the Yeti-Root zone available, at different times. The availability of a new revision of the Yeti-Root zone on the first DM would typically precede that of the last by 40 minutes.
如第4.1节所述，每个Yeti DM根据交错计划轮询根服务器系统，以获得根区域的新版本。因此，不同的DMs预计将检索根区的每个版本，并在不同时间提供相应版本的雪人根区。在第一个DM上提供新版本的雪人根部区域通常比最后一个DM提前40分钟。
Given this distribution mechanism, it might be expected that the maximum latency between the publication of a new revision of the root zone and the availability of the corresponding Yeti-Root zone on any Yeti-Root server would be 20 minutes, since in normal operation at least one DM should serve that Yeti-Zone within 20 minutes of root zone publication. In practice, this was not observed.
考虑到这种分发机制，发布新版本的根区域和在任何Yeti根服务器上提供相应的Yeti根区域之间的最大延迟可能为20分钟，因为在正常操作中，至少一个DM应在根区发布后20分钟内为雪人区提供服务。在实践中，没有观察到这一点。
In one case, a Yeti-Root server running Bundy 1.2.0 on FreeBSD 10.2-RELEASE was found to lag root zone publication by as much as ten hours. Upon investigation, this was found to be due to software defects that were subsequently corrected.
在一个案例中，发现在FreeBSD 10.2-RELEASE上运行Bundy 1.2.0的Yeti根服务器使根区域发布延迟了10个小时。经调查，发现这是由于软件缺陷导致的，随后进行了纠正。
More generally, Yeti-Root servers were observed routinely to lag root zone publication by more than 20 minutes, and relatively often by more than 40 minutes. Whilst in some cases this might be assumed to
更一般地说，雪人根服务器通常被观察到根区发布延迟超过20分钟，相对而言，延迟超过40分钟。而在某些情况下，这可能被认为是
be a result of connectivity problems, perhaps suppressing the delivery of NOTIFY messages, it was also observed that Yeti-Root servers receiving a NOTIFY from one DM would often send SOA queries and AXFR requests to a different DM. If that DM were not yet serving the new revision of the Yeti-Root zone, a delay in updating the Yeti-Root server would naturally result.
由于连接性问题，可能会抑制NOTIFY消息的传递，还观察到，从一个DM接收NOTIFY的Yeti根服务器通常会向另一个DM发送SOA查询和AXFR请求。如果该DM尚未为新版本的Yeti Root zone提供服务，那么自然会导致更新Yeti Root服务器的延迟。
The second approach for doing the transformation of Root Zone to Yeti-Root zone (Section 4.2.2) introduces a situation where mixed RRSIGs from different DM ZSKs are cached in one resolver.
将根区域转换为雪人根区域的第二种方法（第4.2.2节）引入了一种情况，即来自不同DM ZSK的混合RRSIG缓存在一个解析器中。
It is observed that the Yeti-Root zone served by any particular Yeti-Root server will include signatures generated using the ZSK from the DM that served the Yeti-Root zone to that Yeti-Root server. Signatures cached at resolvers might be retrieved from any Yeti-Root server, and hence are expected to be a mixture of signatures generated by different ZSKs. Since all ZSKs can be trusted through the signature by the Yeti KSK over the DNSKEY RRset, which includes all ZSKs, the mixture of signatures was predicted not to be a threat to reliable validation.
可以观察到，由任何特定雪人根服务器服务的雪人根区域将包括使用ZSK从为雪人根区域服务的DM到该雪人根服务器生成的签名。解析程序中缓存的签名可以从任何Yeti根服务器检索，因此应该是由不同ZSK生成的签名的混合。由于所有ZSK都可以通过Yeti KSK在DNSKEY RRset（包括所有ZSK）上的签名进行信任，因此预计签名的混合不会对可靠验证构成威胁。
It was first tested in BII's lab environment as a proof of concept. It was observed in the resolver's DNSSEC log that the process of verifying an RDATA set shows "success" with a key (keyid) in the DNSKEY RRset. It was implemented later in three DMs that were carefully coordinated and made public to all Yeti resolver operators and participants in Yeti's mailing list. At least 45 Yeti resolvers (deployed by Yeti operators) were being monitored and had set a reporting trigger if anything was wrong. In addition, the Yeti mailing list is open for error reports from other participants. So far, the Yeti testbed has been operated in this configuration (with multiple ZSKs) for 2 years. This configuration has proven workable and reliable, even when rollovers of individual ZSKs are on different schedules.
作为概念证明，它首先在BII的实验室环境中进行了测试。在解析器的DNSSEC日志中观察到，验证RDATA集的过程显示DNSKEY RRset中的密钥（keyid）为“成功”。它后来在三个DMs中实施，经过仔细协调，并向所有Yeti解析器操作员和Yeti邮件列表的参与者公开。至少有45台雪人分解器（由雪人操作员部署）受到监控，如果出现任何问题，会设置报告触发器。此外，雪人邮件列表对其他参与者的错误报告开放。到目前为止，雪人试验台已经在这种配置下运行了2年（具有多个ZSK）。这种配置已被证明是可行和可靠的，即使单个ZSK的翻车计划不同。
Another consequence of this approach is that the apex DNSKEY RRset in the Yeti-Root zone is much larger than the corresponding DNSKEY RRset in the Root Zone. This requires more space and produces a larger response to the query for the DNSKEY RRset especially during the KSK rollover.
这种方法的另一个结果是，雪人根区的顶点DNSKEY RRset远大于根区的相应DNSKEY RRset。这需要更多的空间，并对DNSKEY RRset的查询产生更大的响应，尤其是在KSK滚动期间。
At the time of writing, the Root Zone KSK is expected to undergo a carefully orchestrated rollover as described in [ICANN2016]. ICANN has commissioned various tests and has published an external test plan [ICANN2017].
在撰写本文时，根区域KSK预计将经历[ICANN2016]中所述的精心安排的过渡。ICANN已经委托进行了各种测试，并发布了一份外部测试计划[ICANN2017]。
Three related DNSSEC KSK rollover exercises were carried out on the Yeti DNS testbed, somewhat concurrent with the planning and execution of the rollover in the root zone. Brief descriptions of these exercises are included below.
在雪人DNS试验台上进行了三次相关的DNSSEC KSK翻滚演习，在一定程度上与根区翻滚的规划和执行同步。下文简要介绍了这些练习。
The first KSK rollover that was executed on the Yeti DNS testbed deliberately ignored the 30-day hold-down timer specified in [RFC5011] before retiring the outgoing KSK.
在Yeti DNS测试台上执行的第一次KSK翻转故意忽略了[RFC5011]中指定的30天保持计时器，然后退出KSK。
It was confirmed that clients of some (but not all) validating Yeti resolvers experienced resolution failures (received SERVFAIL responses) following this change. Those resolvers required administrator intervention to install a functional trust anchor before resolution was restored.
经确认，部分（但不是全部）验证Yeti解析程序的客户端在此更改后出现解析失败（收到SERVFAIL响应）。在恢复解析之前，这些解析程序需要管理员干预才能安装功能性信任锚。
The second Yeti KSK rollover was designed with similar phases to the ICANN's KSK rollover, although with modified timings to reduce the time required to complete the process. The "slot" used in this rollover was ten days long, as follows:
第二次雪人KSK展期的设计阶段与ICANN的KSK展期阶段相似，但修改了时间安排，以减少完成该过程所需的时间。本次展期中使用的“时段”为10天，如下所示：
+-----------------+----------------+----------+
| | Old Key: 19444 | New Key |
+-----------------+----------------+----------+
| slot 1 | pub+sign | |
| slot 2, 3, 4, 5 | pub+sign | pub |
| slot 6, 7 | pub | pub+sign |
| slot 8 | revoke | pub+sign |
| slot 9 | | pub+sign |
+-----------------+----------------+----------+
+-----------------+----------------+----------+
| | Old Key: 19444 | New Key |
+-----------------+----------------+----------+
| slot 1 | pub+sign | |
| slot 2, 3, 4, 5 | pub+sign | pub |
| slot 6, 7 | pub | pub+sign |
| slot 8 | revoke | pub+sign |
| slot 9 | | pub+sign |
+-----------------+----------------+----------+
During this rollover exercise, a problem was observed on one Yeti resolver that was running BIND 9.10.4-p2 [KROLL-ISSUE]. That resolver was configured with multiple views serving clients in different subnets at the time that the KSK rollover began. DNSSEC validation failures were observed following the completion of the KSK rollover, triggered by the addition of a new view that was intended to serve clients from a new subnet.
在这次翻滚练习中，在运行BIND 9.10.4-p2[KROLL-ISSUE]的一个Yeti解析器上发现了一个问题。在KSK滚动开始时，该解析器配置了多个视图，为不同子网中的客户端提供服务。在KSK翻转完成后，观察到DNSSEC验证失败，该翻转由添加新视图触发，该视图旨在为来自新子网的客户端提供服务。
BIND 9.10 requires "managed-keys" configuration to be specified in every view, a detail that was apparently not obvious to the operator in this case and that was subsequently highlighted by the Internet Systems Consortium (ISC) in their general advice relating to KSK rollover in the root zone to users of BIND 9 [ISC-BIND]. When the "managed-keys" configuration is present in every view that is configured to perform validation, trust anchors for all views are updated during a KSK rollover.
BIND 9.10要求在每个视图中指定“托管密钥”配置，在这种情况下，运营商显然不清楚这一细节，互联网系统联盟（ISC）随后在向BIND 9[ISC-BIND]用户提供的有关根区域KSK翻转的一般建议中强调了这一细节。当“托管密钥”配置出现在配置为执行验证的每个视图中时，所有视图的信任锚都会在KSK滚动期间更新。
Since a KSK rollover necessarily involves the publication of outgoing and incoming public keys simultaneously, an increase in the size of DNSKEY responses is expected. The third KSK rollover carried out on the Yeti DNS testbed was accompanied by a concerted effort to observe response sizes and their impact on end-users.
由于KSK滚动必然涉及同时发布传出和传入公钥，因此预计DNSKEY响应的大小会增加。在Yeti DNS试验台上进行的第三次KSK翻转伴随着一项共同的努力，以观察响应大小及其对最终用户的影响。
As described in Section 4.2.2, in the Yeti DNS testbed each DM can maintain control of its own set of ZSKs, which can undergo rollover independently. During a KSK rollover where concurrent ZSK rollovers are executed by each of three DMs, the maximum number of apex DNSKEY RRs present is eight (incoming and outgoing KSK, plus incoming and outgoing of each of three ZSKs). In practice, however, such concurrency did not occur; only the BII ZSK was rolled during the KSK rollover, and hence only three DNSKEY RRset configurations were observed:
如第4.2.2节所述，在雪人DNS试验台中，每个DM可以保持对其自己的一组ZSK的控制，这些ZSK可以独立进行翻滚。在KSK过渡期间，三个DM中的每一个都执行并发的ZSK过渡，apex DNSKEY RRs的最大数量为八个（传入和传出KSK，加上三个ZSK中的每一个传入和传出）。然而，在实践中，这种并发并没有发生；KSK翻滚期间，仅翻滚BII ZSK，因此仅观察到三种DNSKEY RRset配置：
o 3 ZSKs and 2 KSKs, DNSKEY response of 1975 octets;
o 3个ZSK和2个KSK，1975个八位组的DNSKEY反应；
o 3 ZSKs and 1 KSK, DNSKEY response of 1414 octets; and
o 3个ZSK和1个KSK，1414个八位字节的DNSKEY反应；和
o 2 ZSKs and 1 KSK, DNSKEY response of 1139 octets.
o 2个ZSK和1个KSK，1139个八位组的DNSKEY反应。
RIPE Atlas probes were used as described in Section 5.1.1 to send DNSKEY queries directly to Yeti-Root servers. The numbers of queries and failures were recorded and categorized according to the response sizes at the time the queries were sent. A summary of the results ([YetiLR]) is as follows:
如第5.1.1节所述，使用成熟的Atlas探针直接向Yeti根服务器发送DNSKEY查询。记录查询和失败的数量，并根据发送查询时的响应大小进行分类。结果总结（[YetiLR]）如下：
+---------------+----------+---------------+--------------+
| Response Size | Failures | Total Queries | Failure Rate |
+---------------+----------+---------------+--------------+
| 1139 | 274 | 64252 | 0.0042 |
| 1414 | 3141 | 126951 | 0.0247 |
| 1975 | 2920 | 42529 | 0.0687 |
+---------------+----------+---------------+--------------+
+---------------+----------+---------------+--------------+
| Response Size | Failures | Total Queries | Failure Rate |
+---------------+----------+---------------+--------------+
| 1139 | 274 | 64252 | 0.0042 |
| 1414 | 3141 | 126951 | 0.0247 |
| 1975 | 2920 | 42529 | 0.0687 |
+---------------+----------+---------------+--------------+
The general approach illustrated briefly here provides a useful example of how the design of the Yeti DNS testbed, separate from the Root Server system but constructed as a live testbed on the Internet, facilitates the use of general-purpose active measurement facilities (such as RIPE Atlas probes) as well as internal passive measurement (such as packet capture).
此处简要说明的一般方法提供了一个有用的示例，说明了Yeti DNS测试床的设计（与根服务器系统分离，但构建为Internet上的实时测试床）如何促进通用主动测量设施（如成熟的Atlas探针）以及内部被动测量的使用（如数据包捕获）。
Packet capture is a common approach in production DNS systems where operators require fine-grained insight into traffic in order to understand production traffic. For authoritative servers, capture of inbound query traffic is often sufficient, since responses can be synthesized with knowledge of the zones being served at the time the query was received. Queries are generally small enough not to be fragmented, and even with TCP transport are generally packed within a single segment.
数据包捕获是生产DNS系统中的一种常见方法，在生产DNS系统中，运营商需要对流量进行细粒度的了解，以便了解生产流量。对于权威服务器，捕获入站查询流量通常就足够了，因为响应可以与接收查询时所服务区域的知识进行合成。查询通常很小，不会出现碎片，即使使用TCP传输，查询也通常打包在单个段中。
The Yeti DNS testbed has different requirements; in particular, there is a desire to compare responses obtained from the Yeti infrastructure with those received from the Root Server system in response to a single query stream (e.g., using the "Yeti Many Mirror Verifier" (YmmV) as described in Appendix D). Some Yeti-Root servers were capable of recovering complete DNS messages from within nameservers, e.g., using dnstap; however, not all servers provided that functionality, and a consistent approach was desirable.
雪人DNS试验台有不同的要求；特别是，希望将从Yeti基础设施获得的响应与从根服务器系统接收的响应进行比较，以响应单个查询流（例如，使用附录D中描述的“Yeti多镜像验证器”（YmmV））。一些Yeti根服务器能够从名称服务器内恢复完整的DNS消息，例如，使用dnstap；然而，并不是所有的服务器都提供这种功能，一致的方法是可取的。
The requirement to perform passive capture of responses from the wire together with experiments that were expected (and in some cases designed) to trigger fragmentation and use of TCP transport led to the development of a new tool, PcapParser, to perform fragment and TCP stream reassembly from raw packet capture data. A brief description of PcapParser is included in Appendix D.
由于需要从电线上执行被动捕获响应，以及预期（在某些情况下设计）触发碎片和使用TCP传输的实验，因此开发了一种新工具PcapParser，用于从原始数据包捕获数据执行碎片和TCP流重组。附录D中包含了PCP装置的简要说明。
Renumbering events in the Root Server system are relatively rare. Although each such event is accompanied by the publication of an updated hints file in standard locations, the task of updating local copies of that file used by DNS resolvers is manual, and the process has an observably long tail. For example, in 2015 J-Root was still receiving traffic at its old address some thirteen years after renumbering [Wessels2015].
在根服务器系统中重新编号事件相对较少。尽管每次此类事件都伴随着在标准位置发布更新的提示文件，但更新DNS解析程序使用的该文件的本地副本的任务是手动的，并且该过程具有明显的长尾。例如，2015年，J-Root在重新编号[Wessels2015]大约13年后仍在其旧地址接收流量。
The observed impact of these old, deployed hints files is minimal, likely due to the very low frequency of such renumbering events. Even the oldest of hints files would still contain some accurate root server addresses from which priming responses could be obtained.
所观察到的这些旧的、已部署的提示文件的影响很小，这可能是由于此类重新编号事件的频率很低。即使是最旧的提示文件也会包含一些精确的根服务器地址，从中可以获得启动响应。
By contrast, due to the experimental nature of the system and the fact that it is operated mainly by volunteers, Yeti-Root servers are added, removed, and renumbered with much greater frequency. A tool to facilitate automatic maintenance of hints files was therefore created: [hintUpdate].
相比之下，由于系统的实验性质以及主要由志愿者操作的事实，雪人根服务器的添加、删除和重新编号频率要高得多。因此，创建了一个便于自动维护提示文件的工具：[hintUpdate]。
The automated procedure followed by the hintUpdate tool is as follows.
hintUpdate工具遵循的自动化过程如下所示。
1. Use the local resolver to obtain a response to the query "./IN/NS".
1. 使用本地解析器获取对查询“/IN/NS”的响应。
2. Use the local resolver to obtain a set of IPv4 and IPv6 addresses for each name server.
2. 使用本地解析程序为每个名称服务器获取一组IPv4和IPv6地址。
3. Validate all signatures obtained from the local resolvers and confirm that all data is signed.
3. 验证从本地解析程序获得的所有签名，并确认所有数据都已签名。
4. Compare the data obtained to that contained within the currently active hints file; if there are differences, rotate the old one away and replace it with a new one.
4. 将获得的数据与当前活动提示文件中包含的数据进行比较；如果存在差异，请将旧的旋转掉，并替换为新的。
This tool would not function unmodified when used in the Root Server system, since the names of individual Root Servers (e.g., A.ROOT-SERVERS.NET) are not DNSSEC signed. All Yeti-Root server names are DNSSEC signed, however, and hence this tool functions as expected in that environment.
在根服务器系统中使用此工具时，未经修改，无法正常工作，因为单个根服务器（例如A.Root-Servers.NET）的名称未经DNSSEC签名。但是，所有Yeti根服务器名称都是DNSSEC签名的，因此该工具在该环境中的功能与预期相同。
[RFC1035] specifies that domain names can be compressed when encoded in DNS messages, and can be represented as one of
[RFC1035]指定在DNS消息中编码时可以压缩域名，并且可以表示为
1. a sequence of labels ending in a zero octet;
1. 以零八位字节结尾的一系列标签；
2. a pointer; or
2. 指针；或
3. a sequence of labels ending with a pointer.
3. 以指针结尾的标签序列。
The purpose of this flexibility is to reduce the size of domain names encoded in DNS messages.
这种灵活性的目的是减少DNS消息中编码的域名的大小。
It was observed that Yeti-Root servers running Knot 2.0 would compress the zero-length label (the root domain, often represented as ".") using a pointer to an earlier example. Although legal, this encoding increases the encoded size of the root label from one octet to two; it was also found to break some client software -- in
据观察，运行Knot 2.0的Yeti根服务器将使用指向早期示例的指针压缩零长度标签（根域，通常表示为“.”）。虽然合法，但这种编码将根标签的编码大小从一个八位组增加到两个八位组；还发现它破坏了一些客户端软件——在
particular, the Go DNS library. Bug reports were filed against both Knot and the Go DNS library, and both were resolved in subsequent releases.
特别是Go DNS库。针对Knot和Go DNS库提交了错误报告，并在后续版本中解决了这两个问题。
Yeti DNS was designed and implemented as a live DNS root system testbed. It serves a root zone ("Yeti-Root" in this document) derived from the root zone published by the IANA with only those structural modifications necessary to ensure its function in the testbed system. The Yeti DNS testbed has proven to be a useful platform to address many questions that would be challenging to answer using the production Root Server system, such as those included in Section 3.
Yeti DNS是作为一个实时DNS根系统测试平台设计和实现的。它提供一个根区（本文中的“雪人根”），该根区源自IANA发布的根区，仅需进行必要的结构修改，以确保其在试验台系统中的功能。Yeti DNS测试平台已被证明是一个有用的平台，可以解决许多使用生产根服务器系统难以回答的问题，如第3节中包含的问题。
Indicative findings following from the construction and operation of the Yeti DNS testbed include:
从雪人DNS试验台的建造和运行中得出的以下指示性结果包括：
o Operation in a pure IPv6-only environment; confirmation of a significant failure rate in the transmission of large responses (~7%), but no other persistent failures observed. Two cases in which Yeti-Root servers failed to retrieve the Yeti-Root zone due to fragmentation of TCP segments; mitigated by setting a TCP MSS of 1220 octets (see Section 5.1.1).
o 在纯IPv6环境中运行；确认大响应传输中的重大故障率（~7%），但未观察到其他持续故障。两种情况下，由于TCP段的碎片，Yeti根服务器无法检索Yeti根区域；通过将TCP MSS设置为1220个八位字节来缓解（见第5.1.1节）。
o Successful operation with three autonomous Yeti-Root zone signers and 25 Yeti-Root servers, and confirmation that IXFR is not an appropriate transfer mechanism of zones that are structurally incongruent across different transfer paths (see Section 5.2).
o 使用三个自主Yeti根区域签名者和25个Yeti根服务器成功运行，并确认IXFR不是跨不同传输路径的结构不一致区域的适当传输机制（见第5.2节）。
o ZSK size increased to 2048 bits and multiple KSK rollovers executed to exercise support of RFC 5011 in validating resolvers; identification of pitfalls relating to views in BIND9 when configured with "managed-keys" (see Section 5.3).
o ZSK大小增加到2048位，并执行多个KSK翻转，以在验证解析器时支持RFC 5011；当配置“托管密钥”时，识别与BIND9中视图相关的陷阱（见第5.3节）。
o Use of natural (non-normalized) names for Yeti-Root servers exposed some differences between implementations in the inclusion of additional-section glue in responses to priming queries; however, despite this inefficiency, Yeti resolvers were observed to function adequately (see Section 4.5).
o 对Yeti根服务器使用自然（非规范化）名称暴露了实现之间的一些差异，包括在响应启动查询时包含额外的节胶；然而，尽管效率低下，观察到雪人分解器功能正常（见第4.5节）。
o It was observed that Knot 2.0 performed label compression on the root (empty) label. This resulted in an increased encoding size for references to the root label, since a pointer is encoded as two octets whilst the root label itself only requires one (see Section 5.6).
o 据观察，Knot 2.0在根（空）标签上执行标签压缩。这导致根标签引用的编码大小增加，因为指针编码为两个八位字节，而根标签本身只需要一个八位字节（见第5.6节）。
o Some tools were developed in response to the operational experience of running and using the Yeti DNS testbed: DNS fragment and DNS Additional Truncated Response (ATR) for large DNS responses, a BIND9 patch for additional-section glue, YmmV, and IPv6 defrag for capturing and mirroring traffic. In addition, a tool to facilitate automatic maintenance of hints files was created (see Appendix D).
o 根据运行和使用Yeti DNS测试床的操作经验，开发了一些工具：用于大型DNS响应的DNS片段和DNS附加截断响应（ATR），用于附加节胶的BIND9补丁，用于捕获和镜像流量的YmmV和IPv6碎片整理。此外，还创建了一个工具，以促进提示文件的自动维护（见附录D）。
The Yeti DNS testbed was used only by end-users whose local infrastructure providers had made the conscious decision to do so, as is appropriate for an experimental, non-production system. So far, no serious user complaints have reached Yeti's mailing list during Yeti normal operation. Adding more instances into the Yeti root system may help to enhance the quality of service, but it is generally accepted that Yeti DNS performance is good enough to serve the purpose of DNS Root testbed.
Yeti DNS试验台仅由最终用户使用，其本地基础设施提供商已作出有意识的决定，这样做适用于实验性、非生产性系统。到目前为止，在雪人正常运行期间，没有严重的用户投诉到达雪人的邮件列表。向Yeti根系统中添加更多实例可能有助于提高服务质量，但通常认为Yeti DNS性能足以满足DNS根测试床的目的。
The experience gained during the operation of the Yeti DNS testbed suggested several topics worthy of further study:
雪人DNS试验台运行期间获得的经验提出了几个值得进一步研究的主题：
o Priming truncation and TCP-only Yeti-Root servers: observe and measure the worst-possible case for priming truncation by responding with TC=1 to all priming queries received over UDP transport, forcing clients to retry using TCP. This should also give some insight into the usefulness of TCP-only DNS in general.
o 启动截断和仅TCP的Yeti根服务器：通过对通过UDP传输接收到的所有启动查询响应TC=1，强制客户端使用TCP重试，观察并测量启动截断的最坏情况。这也应该让我们了解到仅TCP DNS在一般情况下的有用性。
o KSK ECDSA Rollover: one possible way to reduce DNSKEY response sizes is to change to an elliptic curve signing algorithm. While in principle this can be done separately for the KSK and the ZSK, the RIPE NCC has done research recently and discovered that some resolvers require that both KSK and ZSK use the same algorithm. This means that an algorithm roll also involves a KSK roll. Performing an algorithm roll at the root would be an interesting challenge.
o KSK ECDSA滚动：减少DNSKEY响应大小的一种可能方法是更改为椭圆曲线签名算法。虽然原则上这可以分别针对KSK和ZSK进行，但成熟的NCC最近进行了研究，发现一些解析器要求KSK和ZSK使用相同的算法。这意味着算法roll还涉及KSK roll。在根节点执行算法滚动将是一个有趣的挑战。
o Sticky Notify for zone transfer: the non-applicability of IXFR as a zone transfer mechanism in the Yeti DNS testbed could be mitigated by the implementation of a sticky preference for master server for each slave. This would be so that an initial AXFR response could be followed up with IXFR requests without compromising zone integrity in the case (as with Yeti) that equivalent but incongruent versions of a zone are served by different masters.
o Sticky Notify for zone transfer：在Yeti DNS测试床中，IXFR作为区域传输机制的不适用性可以通过为每个从属服务器实现主服务器的Sticky首选项来缓解。这将使得初始AXFR响应可以在不影响区域完整性的情况下，通过IXFR请求进行后续处理（与Yeti一样），因为不同的主服务器提供相同但不一致的区域版本。
o Key distribution for zone transfer credentials: the use of a shared secret between slave and master requires key distribution and management whose scaling properties are not ideally suited to systems with large numbers of transfer clients. Other approaches for key distribution and authentication could be considered.
o 区域传输凭据的密钥分发：在从机和主机之间使用共享密钥需要密钥分发和管理，其扩展特性不适合具有大量传输客户端的系统。可以考虑其他密钥分配和认证方法。
o DNS is a tree-based hierarchical database. Mathematically, it has a root node and dependency between parent and child nodes. So, any failures and instability of parent nodes (Root in Yeti's case) may impact their child nodes if there is a human mistake, a malicious attack, or even an earthquake. It is proposed to define technology and practices to allow any organization, from the smallest company to nations, to be self-sufficient in their DNS.
o DNS是一个基于树的分层数据库。从数学上讲，它有一个根节点以及父节点和子节点之间的依赖关系。因此，如果出现人为错误、恶意攻击甚至地震，父节点的任何故障和不稳定（以Yeti为例）都可能影响其子节点。建议定义技术和实践，以允许任何组织，从最小的公司到国家，在其DNS中实现自给自足。
o In Section 3.12 of [RFC8324], a "Centrally Controlled Root" is viewed as an issue of DNS. In future work, it would be interesting to test some technical tools like blockchain [BC] to either remove the technical requirement for a central authority over the root or enhance the security and stability of the existing Root.
o 在[RFC8324]的第3.12节中，“集中控制的根目录”被视为DNS的一个问题。在未来的工作中，测试一些技术工具（如区块链[BC]）将是一件有趣的事情，以消除对根目录的中央权限的技术要求，或者增强现有根目录的安全性和稳定性。
As introduced in Section 4.4, service metadata is synchronized among 3 DMs using Git tool. Any security issue around Git may affect Yeti DM operation. For example, a hacker may compromise one DM's Git repository and push unwanted changes to the Yeti DM system; this may introduce a bad root server or bad key for a period of time.
如第4.4节所述，使用Git工具在3个DM之间同步服务元数据。Git周围的任何安全问题都可能影响Yeti DM的运行。例如，黑客可能会破坏一个DM的Git存储库，并将不需要的更改推送到YetiDM系统；这可能会在一段时间内引入错误的根服务器或错误的密钥。
The Yeti resolver needs the bootstrapping files to join the testbed, like the hints file and trust anchor of Yeti. All required information is published on <yeti-dns.org> and <github.com>. If a hacker tampers with those websites by creating a fake page, a new resolver may lose its way and be configured with a bad root.
Yeti解析器需要引导文件来加入测试平台，比如提示文件和Yeti的信任锚。所有必需的信息都发布在<yeti dns.org>和<github.com>上。如果黑客通过创建假页面篡改这些网站，新的解析程序可能会迷失方向，并被配置为错误的根。
DNSSEC is an important research goal in the Yeti DNS testbed. To reduce the central function of DNSSEC for Root zone, we sign the Yeti-Root zone using multiple, independently operated DNSSEC signers and multiple corresponding ZSKs (see Section 4.2). To verify ICANN's KSK rollover, we rolled the Yeti KSK three times according to RFC 5011, and we do have some observations (see Section 5.3). In addition, larger RSA key sizes were used in the testbed before 2048-bit keys were used in the ZSK signing process of the IANA Root zone.
DNSSEC是雪人DNS试验台的一个重要研究目标。为了减少DNSSEC对根区的中心功能，我们使用多个独立操作的DNSSEC签名器和多个相应的ZSK对雪人根区进行签名（见第4.2节）。为了验证ICANN的KSK滚动，我们根据RFC 5011滚动了雪人KSK三次，我们确实有一些观察结果（见第5.3节）。此外，在IANA根区域的ZSK签名过程中使用2048位密钥之前，测试台中使用了较大的RSA密钥大小。
This document has no IANA actions.
本文档没有IANA操作。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<https://www.rfc-editor.org/info/rfc1035>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, DOI 10.17487/RFC1995, August 1996, <https://www.rfc-editor.org/info/rfc1995>.
[RFC1995]Ohta，M.，“DNS中的增量区域转移”，RFC 1995，DOI 10.17487/RFC1995，1996年8月<https://www.rfc-editor.org/info/rfc1995>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC1996]Vixie，P.，“区域变更即时通知机制（DNS通知）”，RFC 1996，DOI 10.17487/RFC1996，1996年8月<https://www.rfc-editor.org/info/rfc1996>.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, <https://www.rfc-editor.org/info/rfc5011>.
[RFC5011]StJohns，M.“DNS安全（DNSSEC）信任锚的自动更新”，STD 74，RFC 5011，DOI 10.17487/RFC5011，2007年9月<https://www.rfc-editor.org/info/rfc5011>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<https://www.rfc-editor.org/info/rfc5890>.
[ATR] Song, L., "ATR: Additional Truncation Response for Large DNS Response", Work in Progress, draft-song-atr-large-resp-02, August 2018.
[ATR]Song，L.，“ATR：大型DNS响应的额外截断响应”，正在进行的工作，草稿-Song-ATR-Large-resp-022018年8月。
[BC] Wikipedia, "Blockchain", September 2018, <https://en.wikipedia.org/w/ index.php?title=Blockchain&oldid=861681529>.
[BC]维基百科，“区块链”，2018年9月<https://en.wikipedia.org/w/ index.php？title=Blockchain&oldid=861681529>。
[FRAGDROP] Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, M., and T. Taylor, "Why Operators Filter Fragments and What It Implies", Work in Progress, draft-taylor-v6ops-fragdrop-02, December 2013.
[FRAGDROP]Jaeggli，J.，Coletti，L.，Kumari，W.，Vyncke，E.，Kaeo，M.，和T.Taylor，“为什么操作员过滤碎片及其含义”，正在进行的工作，草稿-Taylor-v6ops-FRAGDROP-022013年12月。
[FRAGMENTS] Sivaraman, M., Kerr, S., and D. Song, "DNS message fragments", Work in Progress, draft-muks-dns-message-fragments-00, July 2015.
[片段]Sivaraman，M.，Kerr，S.和D.Song，“DNS消息片段”，正在进行的工作，草稿-muks-DNS-message-FRAGMENTS-00，2015年7月。
[hintUpdate] "Hintfile Auto Update", commit de428c0, October 2015, <https://github.com/BII-Lab/Hintfile-Auto-Update>.
[hintUpdate]“Hintfile自动更新”，提交de428c0，2015年10月<https://github.com/BII-Lab/Hintfile-Auto-Update>.
[HOW_ATR_WORKS] Huston, G., "How well does ATR actually work?", APNIC blog, April 2018, <https://blog.apnic.net/2018/04/16/ how-well-does-atr-actually-work/>.
[ATR的工作原理]休斯顿，G.，“ATR实际工作原理如何？”，APNIC博客，2018年4月<https://blog.apnic.net/2018/04/16/ atr的实际工作情况如何/>。
[ICANN2010] Schlyter, J., Lamb, R., and R. Balasubramanian, "DNSSEC Key Management Implementation for the Root Zone (DRAFT)", May 2010, <http://www.root-dnssec.org/wp-content/ uploads/2010/05/draft-icann-dnssec-keymgmt-01.txt>.
[ICANN2010]Schlyter，J.，Lamb，R.Balasubramanian，“DNSSEC根区密钥管理实施（草案）”，2010年5月<http://www.root-dnssec.org/wp-content/ 上传/2010/05/draft-icann-dnssec-keymgmt-01.txt>。
[ICANN2016] Design Team, "Root Zone KSK Rollover Plan", March 2016, <https://www.iana.org/reports/2016/ root-ksk-rollover-design-20160307.pdf>.
[ICANN2016]设计团队，“根区KSK过渡计划”，2016年3月<https://www.iana.org/reports/2016/ root-ksk-rollover-design-20160307.pdf>。
[ICANN2017] ICANN, "2017 KSK Rollover External Test Plan", July 2016, <https://www.icann.org/en/system/files/files/ ksk-rollover-external-test-plan-22jul16-en.pdf>.
[ICANN2017]ICANN，“2017年KSK滚动外部测试计划”，2016年7月<https://www.icann.org/en/system/files/files/ ksk-rollover-external-test-plan-22jul16-en.pdf>。
[IPv6-frag-DNS] Huston, G., "Dealing with IPv6 fragmentation in the DNS", APNIC blog, August 2017, <https://blog.apnic.net/2017/08/22/ dealing-ipv6-fragmentation-dns>.
[IPv6 frag DNS]Huston，G.，“在DNS中处理IPv6碎片”，APNIC博客，2017年8月<https://blog.apnic.net/2017/08/22/ 处理-ipv6-fragmentation-dns>。
[ISC-BIND] Risk, V., "2017 Root Key Rollover - What Does it Mean for BIND Users?", Internet Systems Consortium, December 2016, <https://www.isc.org/blogs/2017-root-key-rollover-what-does-it-mean-for-bind-users/>.
[ISC-BIND]Risk，V.，“2017根密钥滚动-对BIND用户意味着什么？”，互联网系统联盟，2016年12月<https://www.isc.org/blogs/2017-root-key-rollover-what-does-it-mean-for-bind-users/>.
[ISC-TN-2003-1] Abley, J., "Hierarchical Anycast for Global Service Distribution", March 2003, <http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt>.
[ISC-TN-2003-1]Abley，J.“全球服务分布的分层选播”，2003年3月<http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt>.
[ITI2014] ICANN, "Identifier Technology Innovation Report", May 2014, <https://www.icann.org/en/system/files/files/ iti-report-15may14-en.pdf>.
[ITI2014]ICANN，“标识符技术创新报告”，2014年5月<https://www.icann.org/en/system/files/files/ iti-report-15may14-en.pdf>。
[KROLL-ISSUE] Song, D., "A DNSSEC issue during Yeti KSK rollover", Yeti DNS blog, October 2016, <http://yeti-dns.org/yeti/blog/ 2016/10/26/A-DNSSEC-issue-during-Yeti-KSK-rollover.html>.
[KROLL-ISSUE]Song，D.，“雪人KSK过渡期间的DNSSEC问题”，雪人DNS博客，2016年10月<http://yeti-dns.org/yeti/blog/ 2016/10/26/A-DNSSEC-issue-during-Yeti-KSK-rollover.html>。
[PINZ] Song, D., "Yeti experiment plan for PINZ", Yeti DNS blog, May 2018, <http://yeti-dns.org/yeti/blog/2018/05/01/ Experiment-plan-for-PINZ.html>.
[PINZ]Song，D.，“PINZ的雪人实验计划”，雪人DNS博客，2018年5月<http://yeti-dns.org/yeti/blog/2018/05/01/ PINZ.html>的实验计划。
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 2000, <https://www.rfc-editor.org/info/rfc2826>.
[RFC2826]互联网体系结构委员会，“关于唯一DNS根的IAB技术评论”，RFC 2826，DOI 10.17487/RFC2826，2000年5月<https://www.rfc-editor.org/info/rfc2826>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, <https://www.rfc-editor.org/info/rfc2845>.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake 3rd，D.，和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 2845，DOI 10.17487/RFC2845，2000年5月<https://www.rfc-editor.org/info/rfc2845>.
[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", RFC 6219, DOI 10.17487/RFC6219, May 2011, <https://www.rfc-editor.org/info/rfc6219>.
[RFC6219]Li，X.，Bao，C.，Chen，M.，Zhang，H.，和J.Wu，“针对IPv4/IPv6共存和过渡的中国教育和研究网络（CERNET）IVI翻译设计和部署”，RFC 6219，DOI 10.17487/RFC6219，2011年5月<https://www.rfc-editor.org/info/rfc6219>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.
[RFC6891]Damas，J.，Graff，M.，和P.Vixie，“DNS的扩展机制（EDNS（0）），STD 75，RFC 6891，DOI 10.17487/RFC68911913年4月<https://www.rfc-editor.org/info/rfc6891>.
[RFC7720] Blanchet, M. and L-J. Liman, "DNS Root Name Service Protocol and Deployment Requirements", BCP 40, RFC 7720, DOI 10.17487/RFC7720, December 2015, <https://www.rfc-editor.org/info/rfc7720>.
[RFC7720]Blanchet，M.和L-J.Liman，“DNS根名称服务协议和部署要求”，BCP 40，RFC 7720，DOI 10.17487/RFC7720，2015年12月<https://www.rfc-editor.org/info/rfc7720>.
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, <https://www.rfc-editor.org/info/rfc7872>.
[RFC7872]Gont，F.，Linkova，J.，Chown，T.，和W.Liu，“关于在现实世界中使用IPv6扩展头丢弃数据包的观察”，RFC 7872，DOI 10.17487/RFC7872，2016年6月<https://www.rfc-editor.org/info/rfc7872>.
[RFC8109] Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS Resolver with Priming Queries", BCP 209, RFC 8109, DOI 10.17487/RFC8109, March 2017, <https://www.rfc-editor.org/info/rfc8109>.
[RFC8109]Koch，P.，Larson，M.，和P.Hoffman，“使用启动查询初始化DNS解析程序”，BCP 209，RFC 8109，DOI 10.17487/RFC8109，2017年3月<https://www.rfc-editor.org/info/rfc8109>.
[RFC8324] Klensin, J., "DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?", RFC 8324, DOI 10.17487/RFC8324, February 2018, <https://www.rfc-editor.org/info/rfc8324>.
[RFC8324]Klensin，J.，“DNS隐私、授权、特殊用途、编码、字符、匹配和根结构：再次查看的时间？”RFC 8324，DOI 10.17487/RFC83242018年2月<https://www.rfc-editor.org/info/rfc8324>.
[RRL] Vixie, P. and V. Schryver, "Response Rate Limiting in the Domain Name System (DNS RRL)", June 2012, <http://www.redbarn.org/dns/ratelimits>.
[RRL]Vixie，P.和V.Schryver，“域名系统中的响应速率限制（DNS RRL）”，2012年6月<http://www.redbarn.org/dns/ratelimits>.
[RSSAC001] Root Server System Advisory Committee (RSSAC), "Service Expectations of Root Servers", RSSAC001 Version 1, December 2015, <https://www.icann.org/en/system/files/files/ rssac-001-root-service-expectations-04dec15-en.pdf>.
[RSSAC001]根服务器系统咨询委员会（RSSAC），“根服务器的服务期望”，RSSAC001版本1，2015年12月<https://www.icann.org/en/system/files/files/ rssac-001-root-service-expections-04dec15-en.pdf>。
[RSSAC023] Root Server System Advisory Committee (RSSAC), "History of the Root Server System", November 2016, <https://www.icann.org/en/system/files/files/ rssac-023-04nov16-en.pdf>.
[RSSAC023]根服务器系统咨询委员会（RSSAC），“根服务器系统的历史”，2016年11月<https://www.icann.org/en/system/files/files/ rssac-023-04nov16-en.pdf>。
[SUNSET4] IETF, "Sunsetting IPv4 (sunset4) Concluded WG", <https://datatracker.ietf.org/wg/sunset4/about/>.
[SUNSET4]IETF，“Sunsetting IPv4（SUNSET4）工作组结束”<https://datatracker.ietf.org/wg/sunset4/about/>.
[TNO2009] Gijsen, B., Jamakovic, A., and F. Roijers, "Root Scaling Study: Description of the DNS Root Scaling Model", TNO report, September 2009, <https://www.icann.org/en/system/files/files/ root-scaling-model-description-29sep09-en.pdf>.
[TNO2009]Gijsen，B.，Jamakovic，A.，和F.Roijers，“根标度研究：DNS根标度模型的描述”，TNO报告，2009年9月<https://www.icann.org/en/system/files/files/ root-scaling-model-description-29sep09-en.pdf>。
[USE_MIN_MTU] Andrews, M., "TCP Fails To Respect IPV6_USE_MIN_MTU", Work in Progress, draft-andrews-tcp-and-ipv6-use-minmtu-04, October 2015.
[USE_-MIN_-MTU]Andrews，M.，“TCP未能遵守IPV6_-USE_-MIN_-MTU”，正在进行的工作，草稿-Andrews-TCP-and-IPV6-USE-minmtu-042015年10月。
[Wessels2015] Wessels, D., Castonguay, J., and P. Barber, "Thirteen Years of 'Old J-Root'", DNS-OARC Fall 2015 Workshop, October 2015, <https://indico.dns-oarc.net/event/24/ session/10/contribution/10/material/slides/0.pdf>.
[Wessels2015]Wessels，D.，Castonguay，J.和P.Barber，“老J-Root十三年”，DNS-OARC 2015年秋季研讨会，2015年10月<https://indico.dns-oarc.net/event/24/ session/10/contribution/10/material/slides/0.pdf>。
[YetiLR] "Observation on Large response issue during Yeti KSK rollover", Yeti DNS blog, August 2017, <https://yeti-dns.org/yeti/blog/2017/08/02/ large-packet-impact-during-yeti-ksk-rollover.html>.
[YetiLR]“在Yeti KSK过渡期间对大响应问题的观察”，Yeti DNS博客，2017年8月<https://yeti-dns.org/yeti/blog/2017/08/02/ yeti ksk滚动期间的大数据包影响。html>。
The following hints file (complete and accurate at the time of writing) causes a DNS resolver to use the Yeti DNS testbed in place of the production Root Server system and hence participate in experiments running on the testbed.
以下提示文件（编写时完整且准确）导致DNS解析程序使用Yeti DNS测试床代替生产根服务器系统，从而参与在测试床上运行的实验。
Note that some lines have been wrapped in the text that follows in order to fit within the production constraints of this document. Wrapped lines are indicated with a blackslash character ("\"), following common convention.
请注意，为了符合本文档的生产约束，以下文本中已包装了一些行。按照常见惯例，用黑色斜杠字符（\）表示换行线。
. 3600000 IN NS bii.dns-lab.net
bii.dns-lab.net 3600000 IN AAAA 240c:f:1:22::6
. 3600000 IN NS yeti-ns.tisf.net
yeti-ns.tisf.net 3600000 IN AAAA 2001:559:8000::6
. 3600000 IN NS yeti-ns.wide.ad.jp
yeti-ns.wide.ad.jp 3600000 IN AAAA 2001:200:1d9::35
. 3600000 IN NS yeti-ns.as59715.net
yeti-ns.as59715.net 3600000 IN AAAA \
2a02:cdc5:9715:0:185:5:203:53
. 3600000 IN NS dahu1.yeti.eu.org
dahu1.yeti.eu.org 3600000 IN AAAA \
2001:4b98:dc2:45:216:3eff:fe4b:8c5b
. 3600000 IN NS ns-yeti.bondis.org
ns-yeti.bondis.org 3600000 IN AAAA 2a02:2810:0:405::250
. 3600000 IN NS yeti-ns.ix.ru
yeti-ns.ix.ru 3600000 IN AAAA 2001:6d0:6d06::53
. 3600000 IN NS yeti.bofh.priv.at
yeti.bofh.priv.at 3600000 IN AAAA 2a01:4f8:161:6106:1::10
. 3600000 IN NS yeti.ipv6.ernet.in
yeti.ipv6.ernet.in 3600000 IN AAAA 2001:e30:1c1e:1::333
. 3600000 IN NS yeti-dns01.dnsworkshop.org
yeti-dns01.dnsworkshop.org \
3600000 IN AAAA 2001:1608:10:167:32e::53
. 3600000 IN NS yeti-ns.conit.co
yeti-ns.conit.co 3600000 IN AAAA \
2604:6600:2000:11::4854:a010
. 3600000 IN NS dahu2.yeti.eu.org
dahu2.yeti.eu.org 3600000 IN AAAA 2001:67c:217c:6::2
. 3600000 IN NS yeti.aquaray.com
yeti.aquaray.com 3600000 IN AAAA 2a02:ec0:200::1
. 3600000 IN NS yeti-ns.switch.ch
yeti-ns.switch.ch 3600000 IN AAAA 2001:620:0:ff::29
. 3600000 IN NS yeti-ns.lab.nic.cl
yeti-ns.lab.nic.cl 3600000 IN AAAA 2001:1398:1:21::8001
. 3600000 IN NS yeti-ns1.dns-lab.net
. 3600000 IN NS bii.dns-lab.net
bii.dns-lab.net 3600000 IN AAAA 240c:f:1:22::6
. 3600000 IN NS yeti-ns.tisf.net
yeti-ns.tisf.net 3600000 IN AAAA 2001:559:8000::6
. 3600000 IN NS yeti-ns.wide.ad.jp
yeti-ns.wide.ad.jp 3600000 IN AAAA 2001:200:1d9::35
. 3600000 IN NS yeti-ns.as59715.net
yeti-ns.as59715.net 3600000 IN AAAA \
2a02:cdc5:9715:0:185:5:203:53
. 3600000 IN NS dahu1.yeti.eu.org
dahu1.yeti.eu.org 3600000 IN AAAA \
2001:4b98:dc2:45:216:3eff:fe4b:8c5b
. 3600000 IN NS ns-yeti.bondis.org
ns-yeti.bondis.org 3600000 IN AAAA 2a02:2810:0:405::250
. 3600000 IN NS yeti-ns.ix.ru
yeti-ns.ix.ru 3600000 IN AAAA 2001:6d0:6d06::53
. 3600000 IN NS yeti.bofh.priv.at
yeti.bofh.priv.at 3600000 IN AAAA 2a01:4f8:161:6106:1::10
. 3600000 IN NS yeti.ipv6.ernet.in
yeti.ipv6.ernet.in 3600000 IN AAAA 2001:e30:1c1e:1::333
. 3600000 IN NS yeti-dns01.dnsworkshop.org
yeti-dns01.dnsworkshop.org \
3600000 IN AAAA 2001:1608:10:167:32e::53
. 3600000 IN NS yeti-ns.conit.co
yeti-ns.conit.co 3600000 IN AAAA \
2604:6600:2000:11::4854:a010
. 3600000 IN NS dahu2.yeti.eu.org
dahu2.yeti.eu.org 3600000 IN AAAA 2001:67c:217c:6::2
. 3600000 IN NS yeti.aquaray.com
yeti.aquaray.com 3600000 IN AAAA 2a02:ec0:200::1
. 3600000 IN NS yeti-ns.switch.ch
yeti-ns.switch.ch 3600000 IN AAAA 2001:620:0:ff::29
. 3600000 IN NS yeti-ns.lab.nic.cl
yeti-ns.lab.nic.cl 3600000 IN AAAA 2001:1398:1:21::8001
. 3600000 IN NS yeti-ns1.dns-lab.net
yeti-ns1.dns-lab.net 3600000 IN AAAA 2001:da8:a3:a027::6
. 3600000 IN NS yeti-ns2.dns-lab.net
yeti-ns2.dns-lab.net 3600000 IN AAAA 2001:da8:268:4200::6
. 3600000 IN NS yeti-ns3.dns-lab.net
yeti-ns3.dns-lab.net 3600000 IN AAAA 2400:a980:30ff::6
. 3600000 IN NS \
ca978112ca1bbdcafac231b39a23dc.yeti-dns.net
ca978112ca1bbdcafac231b39a23dc.yeti-dns.net \
3600000 IN AAAA 2c0f:f530::6
. 3600000 IN NS \
3e23e8160039594a33894f6564e1b1.yeti-dns.net
3e23e8160039594a33894f6564e1b1.yeti-dns.net \
3600000 IN AAAA 2803:80:1004:63::1
. 3600000 IN NS \
3f79bb7b435b05321651daefd374cd.yeti-dns.net
3f79bb7b435b05321651daefd374cd.yeti-dns.net \
3600000 IN AAAA 2401:c900:1401:3b:c::6
. 3600000 IN NS \
xn--r2bi1c.xn--h2bv6c0a.xn--h2brj9c
xn--r2bi1c.xn--h2bv6c0a.xn--h2brj9c \
3600000 IN AAAA 2001:e30:1c1e:10::333
. 3600000 IN NS yeti1.ipv6.ernet.in
yeti1.ipv6.ernet.in 3600000 IN AAAA 2001:e30:187d::333
. 3600000 IN NS yeti-dns02.dnsworkshop.org
yeti-dns02.dnsworkshop.org \
3600000 IN AAAA 2001:19f0:0:1133::53
. 3600000 IN NS yeti.mind-dns.nl
yeti.mind-dns.nl 3600000 IN AAAA 2a02:990:100:b01::53:0
yeti-ns1.dns-lab.net 3600000 IN AAAA 2001:da8:a3:a027::6
. 3600000 IN NS yeti-ns2.dns-lab.net
yeti-ns2.dns-lab.net 3600000 IN AAAA 2001:da8:268:4200::6
. 3600000 IN NS yeti-ns3.dns-lab.net
yeti-ns3.dns-lab.net 3600000 IN AAAA 2400:a980:30ff::6
. 3600000 IN NS \
ca978112ca1bbdcafac231b39a23dc.yeti-dns.net
ca978112ca1bbdcafac231b39a23dc.yeti-dns.net \
3600000 IN AAAA 2c0f:f530::6
. 3600000 IN NS \
3e23e8160039594a33894f6564e1b1.yeti-dns.net
3e23e8160039594a33894f6564e1b1.yeti-dns.net \
3600000 IN AAAA 2803:80:1004:63::1
. 3600000 IN NS \
3f79bb7b435b05321651daefd374cd.yeti-dns.net
3f79bb7b435b05321651daefd374cd.yeti-dns.net \
3600000 IN AAAA 2401:c900:1401:3b:c::6
. 3600000 IN NS \
xn--r2bi1c.xn--h2bv6c0a.xn--h2brj9c
xn--r2bi1c.xn--h2bv6c0a.xn--h2brj9c \
3600000 IN AAAA 2001:e30:1c1e:10::333
. 3600000 IN NS yeti1.ipv6.ernet.in
yeti1.ipv6.ernet.in 3600000 IN AAAA 2001:e30:187d::333
. 3600000 IN NS yeti-dns02.dnsworkshop.org
yeti-dns02.dnsworkshop.org \
3600000 IN AAAA 2001:19f0:0:1133::53
. 3600000 IN NS yeti.mind-dns.nl
yeti.mind-dns.nl 3600000 IN AAAA 2a02:990:100:b01::53:0
Here is the reply of a Yeti root name server to a priming request. The authoritative server runs NSD.
下面是Yeti根名称服务器对启动请求的回复。权威服务器运行NSD。
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62391
;; flags: qr aa rd; QUERY: 1, ANSWER: 26, AUTHORITY: 0, ADDITIONAL: 7
;; WARNING: recursion requested but not available
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62391
;; flags: qr aa rd; QUERY: 1, ANSWER: 26, AUTHORITY: 0, ADDITIONAL: 7
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1460
;; QUESTION SECTION:
;. IN NS
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1460
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION: . 86400 IN NS bii.dns-lab.net. . 86400 IN NS yeti.bofh.priv.at.
;; 答案部分：。NS bii.dns-lab.net中的86400。86400英寸，南雪人号，波夫号，priv.at。
. 86400 IN NS yeti.ipv6.ernet.in. . 86400 IN NS yeti.aquaray.com. . 86400 IN NS yeti.jhcloos.net. . 86400 IN NS yeti.mind-dns.nl. . 86400 IN NS dahu1.yeti.eu.org. . 86400 IN NS dahu2.yeti.eu.org. . 86400 IN NS yeti1.ipv6.ernet.in. . 86400 IN NS ns-yeti.bondis.org. . 86400 IN NS yeti-ns.ix.ru. . 86400 IN NS yeti-ns.lab.nic.cl. . 86400 IN NS yeti-ns.tisf.net. . 86400 IN NS yeti-ns.wide.ad.jp. . 86400 IN NS yeti-ns.datev.net. . 86400 IN NS yeti-ns.switch.ch. . 86400 IN NS yeti-ns.as59715.net. . 86400 IN NS yeti-ns1.dns-lab.net. . 86400 IN NS yeti-ns2.dns-lab.net. . 86400 IN NS yeti-ns3.dns-lab.net. . 86400 IN NS xn--r2bi1c.xn--h2bv6c0a.xn--h2brj9c. . 86400 IN NS yeti-dns01.dnsworkshop.org. . 86400 IN NS yeti-dns02.dnsworkshop.org. . 86400 IN NS 3f79bb7b435b05321651daefd374cd.yeti-dns.net. . 86400 IN NS ca978112ca1bbdcafac231b39a23dc.yeti-dns.net. . 86400 IN RRSIG NS 8 0 86400 ( 20171121050105 20171114050105 26253 . FUvezvZgKtlLzQx2WKyg+D6dw/pITcbuZhzStZfg+LNa DjLJ9oGIBTU1BuqTujKHdxQn0DcdFh9QE68EPs+93bZr VlplkmObj8f0B7zTQgGWBkI/K4Tn6bZ1I7QJ0Zwnk1mS BmEPkWmvo0kkaTQbcID+tMTodL6wPAgW1AdwQUInfy21 p+31GGm3+SU6SJsgeHOzPUQW+dUVWmdj6uvWCnUkzW9p +5en4+85jBfEOf+qiyvaQwUUe98xZ1TOiSwYvk5s/qiv AMjG6nY+xndwJUwhcJAXBVmGgrtbiR8GiGZfGqt748VX 4esLNtD8vdypucffem6n0T0eV1c+7j/eIA== )
. 86400英寸NS yeti.ipv6.ernet.IN。86400在NS yeti.aquaray.com。NS yeti.jhcloos.net中的86400。86400在NS yeti.mind-dns.nl。86400在NS dahu1.yeti.eu.org。86400在NS dahu2.yeti.eu.org。86400英寸NS yesti1.ipv6.ernet.IN。NS NS-yeti.bondis.org上的86400。86400英寸NS yeti-NS.ix.ru。86400英寸NS yeti-NS.lab.nic.cl。NS yeti-NS.tisf.net中的86400。86400英寸NS yeti-NS.wide.ad.jp。NS yeti-NS.datev.net中的86400。86400英寸NS yeti-NS.switch.ch。NS yeti-NS.as59715.net中的86400。NS yeti-ns1.dns-lab.net中的86400。NS yeti-ns2.dns-lab.net中的86400。NS yeti-ns3.dns-lab.net中的86400。86400英寸NS xn--r2bi1c.xn--h2bv6c0a.xn--h2brj9c。NS yeti-dns01.dnsworkshop.org中的86400。NS yeti-dns02.dnsworkshop.org中的86400。NS 3f79bb7b435b05321651daefd374cd.yeti-dns.net中的86400。NS ca978112ca1bbdcafac231b39a23dc.yeti-dns.net中的86400。RRSIG NS 8 0 86400中的86400（20171121121105105201201711011011012012017110110110110110110110110110110110110110110110110110110110110120171101101101101101101101101101101101101101101101101101101101101101101101101101101105105105201110110110110110110110110110110110110110110110110105 26253.这是一个中国的ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZMGGRTBIR8GIGZFGQT748VX 4ESLNTD8VDYPUFFEM6N0T0EV1C+7j/eIA==）
;; ADDITIONAL SECTION:
bii.dns-lab.net. 86400 IN AAAA 240c:f:1:22::6
yeti.bofh.priv.at. 86400 IN AAAA 2a01:4f8:161:6106:1::10
yeti.ipv6.ernet.in. 86400 IN AAAA 2001:e30:1c1e:1::333
yeti.aquaray.com. 86400 IN AAAA 2a02:ec0:200::1
yeti.jhcloos.net. 86400 IN AAAA 2001:19f0:5401:1c3::53
yeti.mind-dns.nl. 86400 IN AAAA 2a02:990:100:b01::53:0
;; ADDITIONAL SECTION:
bii.dns-lab.net. 86400 IN AAAA 240c:f:1:22::6
yeti.bofh.priv.at. 86400 IN AAAA 2a01:4f8:161:6106:1::10
yeti.ipv6.ernet.in. 86400 IN AAAA 2001:e30:1c1e:1::333
yeti.aquaray.com. 86400 IN AAAA 2a02:ec0:200::1
yeti.jhcloos.net. 86400 IN AAAA 2001:19f0:5401:1c3::53
yeti.mind-dns.nl. 86400 IN AAAA 2a02:990:100:b01::53:0
;; Query time: 163 msec
;; SERVER: 2001:4b98:dc2:45:216:3eff:fe4b:8c5b#53
;; WHEN: Tue Nov 14 16:45:37 +08 2017
;; MSG SIZE rcvd: 1222
;; Query time: 163 msec
;; SERVER: 2001:4b98:dc2:45:216:3eff:fe4b:8c5b#53
;; WHEN: Tue Nov 14 16:45:37 +08 2017
;; MSG SIZE rcvd: 1222
The following table shows the prefixes that were active during 2017.
下表显示了2017年期间活跃的前缀。
+----------------------+---------------------------------+----------+
| Prefix | Originator | Location |
+----------------------+---------------------------------+----------+
| 240c::/28 | BII | CN |
| 2001:6d0:6d06::/48 | MSK-IX | RU |
| 2001:1488::/32 | CZ.NIC | CZ |
| 2001:620::/32 | SWITCH | CH |
| 2001:470::/32 | Hurricane Electric, Inc. | US |
| 2001:0DA8:0202::/48 | BUPT6-CERNET2 | CN |
| 2001:19f0:6c00::/38 | Choopa, LLC | US |
| 2001:da8:205::/48 | BJTU6-CERNET2 | CN |
| 2001:62a::/31 | Vienna University Computer | AT |
| | Center | |
| 2001:67c:217c::/48 | AFNIC | FR |
| 2a02:2478::/32 | Profitbricks GmbH | DE |
| 2001:1398:1::/48 | NIC Chile | CL |
| 2001:4490:dc4c::/46 | NIB (National Internet | IN |
| | Backbone) | |
| 2001:4b98::/32 | Gandi | FR |
| 2a02:aa8:0:2000::/52 | T-Systems-Eltec | ES |
| 2a03:b240::/32 | Netskin GmbH | CH |
| 2801:1a0::/42 | Universidad de Ibague | CO |
| 2a00:1cc8::/40 | ICT Valle Umbra s.r.l. | IT |
| 2a02:cdc0::/29 | ORG-CdSB1-RIPE | IT |
+----------------------+---------------------------------+----------+
+----------------------+---------------------------------+----------+
| Prefix | Originator | Location |
+----------------------+---------------------------------+----------+
| 240c::/28 | BII | CN |
| 2001:6d0:6d06::/48 | MSK-IX | RU |
| 2001:1488::/32 | CZ.NIC | CZ |
| 2001:620::/32 | SWITCH | CH |
| 2001:470::/32 | Hurricane Electric, Inc. | US |
| 2001:0DA8:0202::/48 | BUPT6-CERNET2 | CN |
| 2001:19f0:6c00::/38 | Choopa, LLC | US |
| 2001:da8:205::/48 | BJTU6-CERNET2 | CN |
| 2001:62a::/31 | Vienna University Computer | AT |
| | Center | |
| 2001:67c:217c::/48 | AFNIC | FR |
| 2a02:2478::/32 | Profitbricks GmbH | DE |
| 2001:1398:1::/48 | NIC Chile | CL |
| 2001:4490:dc4c::/46 | NIB (National Internet | IN |
| | Backbone) | |
| 2001:4b98::/32 | Gandi | FR |
| 2a02:aa8:0:2000::/52 | T-Systems-Eltec | ES |
| 2a03:b240::/32 | Netskin GmbH | CH |
| 2801:1a0::/42 | Universidad de Ibague | CO |
| 2a00:1cc8::/40 | ICT Valle Umbra s.r.l. | IT |
| 2a02:cdc0::/29 | ORG-CdSB1-RIPE | IT |
+----------------------+---------------------------------+----------+
Various tools were developed to support the Yeti DNS testbed, a selection of which are described briefly below.
开发了各种工具来支持Yeti DNS测试平台，下面简要介绍其中的一部分。
YmmV ("Yeti Many Mirror Verifier") is designed to make it easy and safe for a DNS administrator to capture traffic sent from a resolver to the Root Server system and to replay it towards Yeti-Root servers. Responses from both systems are recorded and compared, and differences are logged. See <https://github.com/BII-Lab/ymmv>.
YmmV（“Yeti多镜像验证器”）旨在使DNS管理员能够轻松安全地捕获从解析程序发送到根服务器系统的流量，并将其重播到Yeti根服务器。记录并比较两个系统的响应，并记录差异。看<https://github.com/BII-Lab/ymmv>.
PcapParser is a module used by YmmV which reassembles fragmented IPv6 datagrams and TCP segments from a PCAP archive and extracts DNS messages contained within them. See <https://github.com/RunxiaWan/ PcapParser>.
PcapParser是YmmV使用的一个模块，它从PCAP存档中重新组装分段的IPv6数据报和TCP段，并提取其中包含的DNS消息。看<https://github.com/RunxiaWan/ PcapParser>。
DNS-layer-fragmentation implements DNS proxies that perform application-level fragmentation of DNS messages, based on [FRAGMENTS]. The idea with these proxies is to explore splitting DNS messages in the protocol itself, so they will not by fragmented by the IP layer. See <https://github.com/BII-Lab/DNS-layer-Fragmentation>.
DNS层碎片实现基于[碎片]执行DNS消息应用程序级碎片的DNS代理。这些代理的想法是探索在协议本身中拆分DNS消息，这样它们就不会被IP层分割。看<https://github.com/BII-Lab/DNS-layer-Fragmentation>.
DNS_ATR is an implementation of DNS Additional Truncated Response (ATR), as described in [ATR] and [HOW_ATR_WORKS]. DNS_ATR acts as a proxy between resolver and authoritative servers, forwarding queries and responses as a silent and transparent listener. Responses that are larger than a nominated threshold (1280 octets by default) trigger additional truncated responses to be sent immediately following the large response. See <https://github.com/songlinjian/ DNS_ATR>.
DNS_ATR是DNS附加截断响应（ATR）的一种实现，如[ATR]和[HOW_ATR_WORKS]中所述。DNS_ATR充当解析程序和权威服务器之间的代理，作为静默和透明的侦听器转发查询和响应。大于指定阈值（默认情况下为1280个八位字节）的响应会触发在大响应之后立即发送额外的截断响应。看<https://github.com/songlinjian/ DNS\u ATR>。
The Yeti DNS Project, its infrastructure and the various experiments that have been carried out using that infrastructure, have been described by people involved in the project in many public meetings at technical venues since its inception. The mailing lists using which the operation of the infrastructure has been coordinated are open to join, and their archives are public. The project as a whole has been the subject of robust public discussion.
雪人DNS项目、其基础设施以及使用该基础设施进行的各种实验，自项目启动以来，参与该项目的人员在技术场地的许多公开会议上都进行了描述。用于协调基础设施运行的邮件列表是开放的，其档案是公开的。整个项目一直是公众热烈讨论的主题。
Some commentators have expressed concern that the Yeti DNS Project is, in effect, operating an alternate root, challenging the IAB's comments published in [RFC2826]. Other such alternate roots are considered to have caused end-user confusion and instability in the namespace of the DNS by the introduction of new top-level labels or the different use of top-level labels present in the Root Server system. The coordinators of the Yeti DNS Project do not consider the Yeti DNS Project to be an alternate root in this sense, since by design the namespace enabled by the Yeti-Root zone is identical to that of the Root Zone.
一些评论员表示担心，雪人DNS项目实际上是在运行另一个根目录，挑战IAB在[RFC2826]中发表的评论。通过引入新的顶级标签或根服务器系统中存在的顶级标签的不同使用，其他此类备用根被认为已在DNS的命名空间中造成最终用户混乱和不稳定。YETI DNS项目的协调者并不认为YETIN DNS项目在这个意义上是替代根，因为通过设计，雪蒂根区启用的命名空间与根区的命名空间相同。
Some commentators have expressed concern that the Yeti DNS Project seeks to influence or subvert administrative policy relating to the Root Server system, in particular in the use of DNSSEC trust anchors not published by the IANA and the use of Yeti-Root servers in regions where governments or other organizations have expressed interest in operating a Root Server. The coordinators of the Yeti-Root project observe that their mandate is entirely technical and has no ambition to influence policy directly; they do hope, however, that technical findings from the Yeti DNS Project might act as a useful resource for the wider technical community.
一些评论员表示担心雪人DNS项目试图影响或颠覆与根服务器系统相关的管理政策，特别是在使用IANA未发布的DNSSEC信任锚以及在政府或其他组织表示有兴趣运营根服务器的地区使用Yeti根服务器方面。雪人根项目的协调员观察到，他们的任务完全是技术性的，没有直接影响政策的野心；然而，他们确实希望来自雪人DNS项目的技术发现能够为更广泛的技术社区提供有用的资源。
Acknowledgments
致谢
Firstly, the authors would like to acknowledge the contributions from the people who were involved in the implementation and operation of the Yeti DNS by donating their time and resources. They are:
首先，作者要感谢参与雪人DNS的实施和运营的人们贡献了他们的时间和资源。他们是：
Tomohiro Ishihara, Antonio Prado, Stephane Bortzmeyer, Mickael Jouanne, Pierre Beyssac, Joao Damas, Pavel Khramtsov, Dmitry Burkov, Dima Burkov, Kovalenko Dmitry, Otmar Lendl, Praveen Misra, Carsten Strotmann, Edwin Gomez, Daniel Stirnimann, Andreas Schulze, Remi Gacogne, Guillaume de Lafond, Yves Bovard, Hugo Salgado, Kees Monshouwer, Li Zhen, Daobiao Gong, Andreas Schulze, James Cloos, and Runxia Wan.
石原友弘、安东尼奥·普拉多、斯蒂芬·波茨迈耶、米克尔·朱安、皮埃尔·贝萨克、若昂·达马斯、帕维尔·克拉姆佐夫、德米特里·布尔科夫、迪玛·布尔科夫、科瓦连科·德米特里、奥特玛·伦德尔、普拉文·米斯拉、卡斯滕·斯特罗特曼、埃德温·戈麦斯、丹尼尔·斯蒂尼曼、安德烈亚斯·舒尔茨、雷米·加科涅、纪尧姆·德拉丰、伊夫·博瓦德、雨果·萨尔加多、基斯·蒙苏沃、李珍、，龚道彪、安德烈亚斯·舒尔茨、詹姆斯·克罗斯和万润霞。
Thanks to all people who gave important advice and comments to Yeti, either in face-to-face meetings or virtually via phone or mailing list. Some of the individuals are as follows:
感谢所有在面对面会议或通过电话或邮件列表向雪人提供重要建议和意见的人。其中一些人如下：
Wu Hequan, Zhou Hongren, Cheng Yunqing, Xia Chongfeng, Tang Xiongyan, Li Yuxiao, Feng Ming, Zhang Tongxu, Duan Xiaodong, Wang Yang, Wang JiYe, Wang Lei, Zhao Zhifeng, Chen Wei, Wang Wei, Wang Jilong, Du Yuejing, Tan XiaoSheng, Chen Shangyi, Huang Chenqing, Ma Yan, Li Xing, Cui Yong, Bi Jun, Duan Haixing, Marc Blanchet, Andrew Sullivan, Suzanne Wolf, Terry Manderson, Geoff Huston, Jaap Akkerhuis, Kaveh Ranjbar, Jun Murai, Paul Wilson, and Kilnam Chonm.
吴鹤泉、周洪仁、程云卿、夏崇峰、唐雄燕、李玉晓、冯明、张通旭、段晓东、汪洋、王继业、王雷、赵志峰、陈伟、王伟、王吉龙、杜跃静、谭晓生、陈尚义、黄晨青、马燕、李兴、崔勇、毕骏、段海星、马克·布兰切特、安德鲁·沙利文、，苏珊·沃尔夫、特里·曼德森、杰夫·休斯顿、雅普·阿克胡伊斯、卡维·兰杰巴尔、琼·穆雷、保罗·威尔逊和基尔南·乔恩。
The authors also acknowledge the assistance of the Independent Submissions Editorial Board, and of the following reviewers whose opinions helped improve the clarity of this document:
作者还感谢《独立意见书》编辑委员会以及以下评审员的协助，他们的意见有助于提高本文件的清晰度：
Joe Abley, Paul Mockapetris, and Subramanian Moonesamy.
乔·阿贝利、保罗·莫卡佩特里斯和苏布拉曼尼安·穆内萨米。
Authors' Addresses
作者地址
Linjian Song (editor) Beijing Internet Institute 2nd Floor, Building 5, No.58 Jing Hai Wu Lu, BDA Beijing 100176 China Email: songlinjian@gmail.com URI: http://www.biigroup.com/
宋林建（编辑）北京互联网研究所北京市BDA京海五路58号5栋2楼100176中国电子邮件：songlinjian@gmail.comURI:http://www.biigroup.com/
Dong Liu Beijing Internet Institute 2nd Floor, Building 5, No.58 Jing Hai Wu Lu, BDA Beijing 100176 China Email: dliu@biigroup.com URI: http://www.biigroup.com/
北京市BDA京海五路58号5栋2楼东柳北京互联网研究所中国邮箱：100176dliu@biigroup.comURI:http://www.biigroup.com/
Paul Vixie TISF 11400 La Honda Road Woodside, California 94062 United States of America Email: vixie@tisf.net URI: http://www.redbarn.org/
Paul Vixie TISF 11400 La Honda Road Woodside，加利福尼亚州94062美利坚合众国电子邮件：vixie@tisf.netURI:http://www.redbarn.org/
Akira Kato Keio University/WIDE Project Graduate School of Media Design, 4-1-1 Hiyoshi, Kohoku Yokohama 223-8526 Japan Email: kato@wide.ad.jp URI: http://www.kmd.keio.ac.jp/
秋叶加藤庆应大学/广域项目媒体设计研究生院，4-1-1 Hiyoshi，Kohoku Yokohama 223-8526日本电子邮件：kato@wide.ad.jpURI:http://www.kmd.keio.ac.jp/
Shane Kerr Antoon Coolenlaan 41 Uithoorn 1422 GN The Netherlands Email: shane@time-travellers.org
Shane Kerr Antoon Coolenlaan 41 Uithoorn 1422 GN荷兰电子邮件：shane@time-旅行者网