[要約] RFC 8483は、Yeti DNSテストベッドの概要と目的を説明しています。Yeti DNSテストベッドは、IPv6ネットワーク上でのDNSシステムの実験とテストを目的としています。
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).
イエティDNSは実験的な非本番ルートサーバーテストベッドで、本番ルートサーバーインフラストラクチャへのリスクなしに技術的および運用上の実験を安全に実行できる環境を提供します。このドキュメントは、ルートサーバーシステム（インターネットのドメインネームシステムが設計および構築されているシステム）と類似しているが異なるシステムの展開の技術的および運用上の経験を文書化することのみを目的としています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
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/>).
特にルートサーバーシステムでは、技術革新と開発が見られます。たとえば、大規模なエニーキャスト展開、グローバルスケールでの不要なトラフィックの軽減、Response Rate Limiting [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 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.
イエティDNSプロジェクトは、このような種類の質問に答えるように設計された実験を提案または実行するために、技術コミュニティの誰もが利用できる非生産テストベッドを提供することを目的として、2015年5月に考案されました。プロジェクトの調整は、BII、TISF、およびWIDEプロジェクトによって提供されました。したがって、Yeti 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のイエティルートサーバーと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テストベッドシステムで有効に機能できるようにするために必要な構造変更のみです。特に、Yetiテストベッドシステムによって提供されるルートゾーンを構築するために、IANA公開ルートゾーンからトップレベルゾーンの委任が変更、追加、または削除されることはなく、ルートゾーンの変更は、近くのテストベッドに反映されます。リアルタイム。このドキュメントでは、明確にするために、IANA公開のルートゾーンから派生したゾーンをYeti-Rootゾーンと呼びます。
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.
イエティDNSテストベッドは、どちらもイエティルートゾーンとIANA公開ルートゾーンという同様のゾーンを提供するという意味で、ルートサーバーシステムと同様の機能を果たします。ただし、Yeti DNSテストベッドは、実験に参加するように明示的に構成されたクライアントにのみサービスを提供しますが、ルートサーバーシステムはインターネット全体にサービスを提供します。イエティDNSテストベッドの依存するエンドユーザーとシステムは既知であり、それらの操作はイエティプロジェクトのそれらと十分に調整されているため、効果的な測定と分析により、イエティ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.
このドキュメントでは、大文字の "R"と他の接頭辞のない "ルート"についての言及は、本番インターネットで使用される "IANAルート"システムを指します。イエティインフラストラクチャの適切な言及には、「イェティルートゾーン」、「イェティ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.
このセクションでは、Yeti DNSテストベッドの開発者が対処する必要があると見なしたトピックの例をいくつか示します。セクション1で述べたように、Yeti DNSは独立して調整されるプロジェクトであり、IETF、ICANN、IANA、またはその他のルートサーバーオペレーターとは提携していません。したがって、研究のトピックと領域は、彼ら自身の懸念に対処し、提供された情報とツールがより広い関心を持つことを期待して、Yetiプロジェクトの支持者によって（そしてそのために）選択されました。
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 どのようにしてテストベッドを構築し、インターネット上に展開して、ルートサーバーシステムを中断するリスクなしに、一般市民の参加を可能にすることができますか
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 イエティルートサーバー、イエティルートサーバーインスタンス、または中間配布ポイントの数が増えると、イエティルートゾーン分布のスケーリングプロパティはどのようになりますか？
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 イエティルートサーバーのクライアントがイエティルートサーバーの再番号付けイベントに反応できる速度を改善するには、どの自動メカニズムが役立つでしょうか？
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のみのYeti-Rootサーバーを使用する場合、運用上の悪影響はありますか？
o What effect does the IPv6 fragmentation model have on the operation of Yeti-Root servers, compared with that of IPv4?
o IPv6フラグメンテーションモデルは、IPv4のそれと比較して、Yeti-Rootサーバーの操作にどのような影響を与えますか？
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）を使用して、Yeti-Rootゾーンに署名することは現実的ですか？
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ロールオーバー計画は、Yetiテストベッドで期待どおりに機能しますか？
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.
テストベッドの目的は、図1に示すように、スタブリゾルバからのDNSクエリが再帰リゾルバによって仲介され、Yeti-Rootサーバーに配信され、Yeti-Rootサーバーで生成された対応する応答が返されるようにすることです。
,----------. ,-----------. ,------------.
| 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.
イエティDNSテストベッドを使用するには、イエティルートサーバーを使用するように再帰リゾルバーを構成する必要があります。その構成は、本番のルートサーバーシステム（付録A）に使用されている対応するヒントを置き換える、Yeti-Rootサーバー（しばしば「ヒントファイル」と呼ばれる）の名前とアドレスのリストで構成されます。 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.
イエティルートはIANAルートで使用されるキーではなく、イエティキーで署名されているため、リゾルバーのトラストアンカーで対応する変更が必要です。 Yeti-Rootヒントファイルの付録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.
イエティテストベッドを介したIANAからスタブリゾルバーへのデータフローを図2に示し、以降のセクションで詳しく説明します。
,----------------.
,-- / 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テストベッドの3つのコーディネーター：BII：北京インターネットインスティテュートWIDE：広範に統合された分散環境プロジェクトTISF：ポールヴィクシーによる共同エンジニアリングおよびセキュリティプロジェクト
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.
ルートはディストリビューションマスター（DM）にバインドされていないことに注意してください。 DMは、セクション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.
イエティルートゾーンは、ディストリビューションマスター（DM）と呼ばれる一連の内部マスターサーバーを通じてイエティDNSテストベッド内に分散されます。これらのサーバー要素は、Yeti-RootゾーンをすべてのYeti-Rootサーバーに配布します。イエティDMが配布用のイエティルートゾーンを構築する方法を以下に説明します。
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.
イエティDNS DMはルートサーバーシステムから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ルート、Cルート、Fルート、Gルート、Kルート、およびLルートから直接利用できます。 2つのサーバーXFR.CJR.DNS.ICANN.ORGおよびXFR.LAX.DNS.ICANN.ORG;ルートゾーンメンテナーとIANA機能オペレーターが管理するサイトからFTP経由。イエティDNSテストベッドは、Fルートからのゾーン転送を使用してルートゾーンを取得します。 F-Rootが各Yeti DMによってポーリングされるスケジュールは次のとおりです。
+-------------+-----------------------+
| 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テストベッドは、複数のDMを使用します。各DMは、自律的に動作し、兄弟と同等に動作します。単一の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.
イエティDNSテストベッドでは、ルートゾーンをイエティルートゾーンに変換するために、2つの異なるアプローチが個別に導入されています。上位レベルでは、これらのアプローチは、ルートゾーンの最小限の情報セットを、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.
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).
ルートゾーンは次のように変換され、イエティルートゾーンが作成されます。この変換は、各Yeti DNSプロジェクトDMで自律的に実行されます。各DMは、すべてのDM間で同期された、Yeti KSKおよびZSKキーペアの現在のセットの本物のコピーを運びます（セクション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>は現在、「ワイド」、「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. 頂点のネームサーバー（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. イエティNS RRsetは、すべてのイエティルートサーバーを含む頂点に追加されます。
7. Glue records (AAAA only, since Yeti-Root servers are v6-only) for all Yeti-Root servers are added.
7. すべてのYeti-Rootサーバーのグルーレコード（Yeti-Rootサーバーはv6のみであるため、AAAAのみ）が追加されます。
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.
イエティルートゾーンで公開された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 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.
ここで説明するアプローチは、安定した状態として実装および維持される2番目のものです。各DMは、他のDMと共有されない独自の専用ZSKキーペアでプロビジョニングされます。イエティルートDNSKEY RRsetは、アクティブなイエティルートKSKのセットと個々のDMごとのアクティブなZSKセットの和集合として、すべてのDMの上流で作成および署名されます。現在、各DMは、専用のZSK鍵ペアの秘密の部分のみをローカルで利用可能にする必要があり、他の秘密鍵の素材は共有されていません。高レベルのアプローチを図3に示します。
,----------. ,-----------.
.--------> 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].
ルートサーバーシステムからルートゾーンを取得し、頂点DNSKEY RRsetを置き換えて署名するプロセスは、DMで行われなくなりました。代わりに、中央の隠しマスターで行われます。署名付きDNSKEY RRsetの生成は、ICANN KSK鍵式典[ICANN2010]中に生成される署名付き鍵応答（SKR）の使用に類似しています。
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非表示マスターからソースデータ（変更前のイエティ署名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は、DMがDNSKEY RRsetを変更または署名する必要がなくなり、DMの一意のローカルZSKを使用して他のすべてのRRsetに署名することを除いて、セクション4.2.1で説明したものと同様の変換を実行します。
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で説明した変換の変更は、ルートゾーンからのNSECチェーンとルートゾーンのZSKを使用して生成されたすべてのRRSIG RRを保持するPINZ [PINZ]と呼ばれるイエティ実験として提案されました。 DNSKEY RRsetは引き続きルートゾーンKSKを置き換えるように変更されますが、ルートゾーンZSKはそのまま維持され、Yeti KSKを使用して頂点DNSKEYおよびNS RRsetで置換署名を生成します。ソースデータは引き続きルートサーバーシステムから隠しマスターを経由して一連のDMに流れますが、DMで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は、NOTIFY [RFC1996]メッセージを送信するYeti-Rootサーバーアドレスの完全なリストで構成されています。これは、ゾーン転送のアドレスベースのアクセス制御リストの基礎も形成します。アドレスによる認証は、より厳密なメカニズムに置き換えることができます（たとえば、トランザクション署名（TSIG）[RFC2845]を使用）。アドレスベースの制御を使用することで、Yeti-Rootサーバーオペレーター間で共有シークレットを配布する必要がなくなるため、これは執筆時点では行われていません。
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.
個々のイエティルートサーバーは、SOAおよびAXFRクエリを従来の方法で送信できるイエティDMアドレスのフルセットで構成されます。
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-Rootサーバーの追加または削除、Yeti-Rootサーバーの番号の再割り当て、DNSSECキーのロールオーバーなど、Yeti DNSテストベッドインフラストラクチャの変更では、すべてのDMで調整された変更を行う必要があります。イエティDNSテストベッドは、ルートサーバーシステムで観察されるよりも頻繁に変更される可能性があり、IANAルートサーバーよりも実質的に多くのイエティルートサーバーが含まれるため、イエティテストベッドでの手動変更プロセスは、より影響を受ける可能性があります。ヒューマンエラー。その結果、自動化された協調プロセスが実装されました。
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オペレーターは、各DMの操作に関連するすべてのサービスメタデータを含むGitリポジトリをローカルで実行します。すべてのイエティコーディネーター間で変更が必要で承認された場合、1人のDMオペレーター（通常BII）がローカルGitリポジトリを更新します。変更が有効になる時期として、将来（2日後）のシリアル番号が選択されます。次に、DMオペレーターは、変更を確認および編集する機会を持つ他の2つのDMオペレーターのGitリポジトリーに変更をプッシュします。ルートゾーンのシリアル番号が選択した番号を超えると、変更は自動的に個々のDMにプルされ、本番環境に昇格します。
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:
3つのGitリポジトリは、リモートサーバーとして構成することで同期されます。たとえば、BIIでは、次のように3つのDMのリポジトリすべてにプッシュします。
$ 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/ Yeti-Project / 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バイトは、EDNS（0）を使用しないUDPトランスポートを使用した最大DNSメッセージサイズです。 [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-Rootサーバーはこの最適化を使用しませんが、それぞれのオペレーターが選択した自由形式のネームサーバー名を使用します。つまり、ラベル圧縮を使用してプライミング応答のサイズを最小化する試みは行われません。このアプローチは、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).
イエティルートサーバーからのプライミング応答（ルートサーバーからの応答とは異なります）では、追加のセクションにサーバーアドレスが常に含まれるとは限りません。特に、BIND9を実行しているYeti-Rootサーバーは、構成パラメーター「minimum-responses」が設定されている場合、空の追加セクションを返します。これにより、リゾルバーは、各Yeti-Rootのアドレスを解決するために、一連の従来の再帰的ルックアップでプライミングプロセスを完了します。サーバ。 NSDを実行するYeti-Rootサーバーは、完全に追加された追加セクションを返します（もちろん、使用中の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 イエティルートサーバーで使用されているネームサーバーソフトウェアまたは構成を変更します。
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-Rootサーバーで従属できる1つ以上のゾーンにあるYeti-Rootサーバーの名前を分離し、必要に応じてサーバーの名前を変更して、プライミング応答の権限セクションに完全に入力できる信頼できるデータのソースをそれぞれに提供します。これは、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-Rootサーバーの名前を変更することによる潜在的な軽減策は、ルートゾーンに存在しない新しい最上位ラベルの発明を示唆しているため、考慮されませんでした。
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-Rootサーバーによって生成された空の追加セクションでさえ、テストされたすべてのリゾルバーソフトウェアには十分であるようです。リゾルバーは、解決する必要のある権限のあるサーバー名ごとに新しい再帰的ルックアップを実行するだけです。
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).
さまざまなボランティアが、Yeti-Rootサーバーとして機能する信頼できるサーバーを寄付しています。執筆時点では、25のイエティルートサーバーがグローバルに配布されており、そのうちの1つは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 |
+-------------------------------------+---------------+-------------+
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].
イエティルートサーバーの現在のリストは、最初に代替ヒントファイルの付録Aを使用し、その後通常のリゾルバープライミングプロセス[RFC8109]によって、参加しているリゾルバーが利用できるようになります。予測可能な将来のIPv6のみのインターネットのため、すべてのYeti-RootサーバーはIPv6のみです。したがって、Yeti-RootヒントファイルにはIPv4アドレスが含まれず、Yeti-RootゾーンにはIPv4グルーレコードが含まれません。 IPv6のみのテストベッドの根拠は、IETF SUNSET4 WG [SUNSET4]のコンテキストと同様に、IPv4がオフの場合にIPv6のみのルートが問題や影響に耐えられるかどうかをテストすることです。
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.
執筆時点では、ルートサーバーシステム内のすべてのルートサーバーがルートゾーンに加えてROOT-SERVERS.NETゾーンにサービスを提供しており、1つを除くすべてがARPAゾーンにもサービスを提供しています。イエティルートサーバーは、イエティルートゾーンのみにサービスを提供します。
Significant software diversity exists across the set of Yeti-Root servers, as reported by their volunteer operators at the time of writing:
執筆時にボランティアオペレーターによって報告されたように、イエティルートサーバーのセット全体でソフトウェアの重要な多様性が存在します。
o Platform: 18 of 25 Yeti-Root servers are implemented on a Virtual Private Server (VPS) rather than bare metal.
o プラットフォーム：25の18のYeti-Rootサーバーは、ベアメタルではなくVirtual Private Server（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 オペレーティングシステム：Linux（Ubuntu、Debian、CentOS、Red Hat、およびArchLinux）で実行される15個のYeti-Rootサーバー。 4はFreeBSDで実行されます。 NetBSDでは1。 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のYeti-RootサーバーはBIND9を使用します（バージョンは9.9.7と9.10.3の間で異なります）。 4 NSD（4.10および4.15）を使用します。 2 Knot（2.0.1および2.1.0）を使用します。 1はBundy（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.
イエティ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未満ですが、付録Cにまとめられているように、2017年にはさまざまなソースがアクティブであることが確認されました。
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.
トラフィックの負荷を増やすために、合成トラフィックがシステムに随時導入されています。アプローチには、RIPE ATLASなどの分散測定プラットフォームを使用してDNSクエリをイエティルートサーバーに送信し、トラフィック（後で非イエティリゾルバーからルートサーバーシステムに送信される）をキャプチャして、後で修正してイエティルートサーバーに向けて再生します。 。
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.
クエリと応答のトラフィックキャプチャは、DNSトラフィックへのパケットレベルの可視性を必要とする実験を見越して、YetiリゾルバーとYeti-Rootサーバーの両方のテストベッドで利用できます。
Traffic capture is performed on Yeti-Root servers using either
トラフィックキャプチャは、以下のいずれかを使用して、Yeti-Rootサーバーで実行されます。
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 pcaputils Debianパッケージ<https://packages.debian.org/sid/pcaputils>の一部であるpcapdumpと、トリガーされたファイルのアップロードを容易にするパッチ（<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.
すべてのイエティルートサーバーはIPv6接続で展開され、どのイエティルートサーバーのIPv4アドレスも利用できません（たとえば、イエティヒントファイルまたはDNS自体で）。この実装の決定により、Yeti-Rootシステムは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の両方が利用可能な場合、両方の使用に長けています。 1つのプロトコルで確実に到達できないサーバーは、DNS解決がエンドユーザーのパフォーマンスの認識のためのクリティカルパス上にある一般的なケースでエンドユーザーの利益のために、他のプロトコルよりも適切にクエリされる可能性があります。ただし、この最適化は、1つのプロトコルの体系的な問題を他のプロトコルによって隠すことができることも意味します。すべてのトラフィックを強制的に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.
イエティルートサーバー自体はIPv6を使用してのみ到達可能でしたが、実際のエンドユーザーはIPv6接続を持たないことがよくあります。テストベッドでは、IPv6のみのイエティルートサーバーが、デュアルスタックのイエティリゾルバーを使用して、シングルスタックの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で説明されているイエティルートサーバーの命名方式を選択すると、ラベルの圧縮が無効になります。それは大きなプライミング応答（25 NSレコードとそれに対応するグルーレコードを持つ最大1754オクテット）を作成します。セクション4.2.2で説明されているイエティルートゾーン変換アプローチは、特にKSKロールオーバー中に頂点DNSKEY RRsetを大幅に拡大します（3つのZSKと2つのKSKで最大1975オクテット）。したがって、断片化の発生率の増加が予想されました。
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.
イエティ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.
影響を調べるために、RIPE Atlasプローブが使用されました。イエティルートサーバーごとに、5つのリージョンからの100個のIPv6対応プローブを使用してAtlas測定を設定し、DO = 1のUDPトランスポートを使用して「./IN/DNSKEY」のDNSクエリを送信しました。この測定は、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応答の配信の失敗に限定されませんでした。 TCPを使用してDMからYeti-Rootゾーンを転送するときに、Yeti-Rootサーバーが失敗する2つのケースがありました。 DMログファイルは、ゾーン転送要求に対応する「ソケットが接続されていません」エラーを明らかにしました。さらなる実験により、NetBSD 6.1、NetBSD 7.0RC1、FreeBSD 10.0、Debian 3.2、およびVMWare ESXI 5.5の組み合わせにより、IPV6_USE_MIN_MTUが存在するにもかかわらず、クライアントとサーバー間で1440オクテットの高いTCP最大セグメントサイズ（MSS）値がネゴシエートされることが判明しました[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.
イエティリゾルバは、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 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のみの環境に展開されたリゾルバーは、アップストリームのデュアルスタックイエティリゾルバーを介してイエティDNSテストベッドに参加できました。 1つのケース（CERNET2）では、これはIPv4アドレスをイエティルートサーバーに割り当て、それらをデュアルスタック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.
イエティDNSテストベッドは、複数のDMを使用してイエティルートゾーンを配布します。これは、イエティルートサーバーの数を、単一の配布ソースでサポートできる数よりも多くの数にスケーリングできるようにし、冗長性を提供するアプローチです。ただし、複数のDMを使用すると、運用上の課題がいくつか発生しました。これについては、次のセクションで説明します。
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.
イエティルートサーバーは、イエティルートゾーンをスレーブとして機能するように構成されています。各スレーブはすべてのDMをマスターとして構成し、ゾーンの同期に冗長性を提供しました。
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 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).
イエティテストベッドの各DMは、機能的には同等ですが他のすべてのDMが提供するゾーンと一致しないイエティルートゾーンを提供しました（セクション4.3を参照）。他のすべてのRRsetの署名は、特定のバリアントを提供するDMのみが使用できる秘密鍵を使用して生成されるため、違いには、SOA.MNAMEフィールドのバリエーション、さらに重要な点として、頂点DNSKEY RRset以外のすべてのRRSIGのバリエーションが含まれます。ゾーンの（セクション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-Rootサーバーと一貫性のある単一のDM間のゾーン同期に使用できる実行可能なメカニズムです。ただし、そのYeti-Rootサーバーが別のDMを選択した場合、IXFRは安全なメカニズムではなくなります。異なるDM上の不一致ゾーン間の構造的な変更は、転送されたデルタに含まれず、その結果、ゾーンは内部的に一貫性のないものになります。このため、DMの変更後の最初の転送では、IXFRではなくAXFRが必要になります。
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.
イエティルートサーバーで使用されているDNSソフトウェアは、使用中のマスターサーバーに応じて、このIXFR / AXFRの混合をサポートしていません。上記のYeti-Rootシステムで説明されている環境は特異的であるため、これは当然のことです。従来のゾーン転送グラフには、すべてのノード間で合同なゾーンが含まれます。このため、すべてのYeti-Rootサーバーは、常に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はルートサーバーシステムをポーリングして、インターリーブされたスケジュールでルートゾーンの新しいリビジョンを探しました。その結果、さまざまなDMがルートゾーンの各リビジョンを取得し、イエティルートゾーンの対応するリビジョンをさまざまなタイミングで利用可能にすることが期待されていました。最初の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.
この配布メカニズムが与えられた場合、ルートゾーンの新しいリビジョンの公開と、任意のイエティルートサーバー上の対応するイエティルートゾーンの可用性との間の最大レイテンシは20分になることが予想されます。ルートゾーンの公開から20分以内に、少なくとも1つのDMがそのイエティゾーンにサービスを提供する必要があります。実際には、これは観察されませんでした。
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-Rootサーバーが、ルートゾーンの公開に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 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.
より一般的には、Yeti-Rootサーバーは、ルートゾーンの公開に20分以上、比較的頻繁には40分以上遅れることが定期的に観察されました。いくつかのケースでは、これはおそらく接続の問題の結果であると想定されるかもしれませんが、おそらくNOTIFYメッセージの配信を抑制します。 DM。そのDMがまだイエティルートゾーンの新しいリビジョンを提供していない場合、イエティルートサーバーの更新の遅延が自然に発生します。
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.
ルートゾーンからイエティルートゾーンへの変換を行うための2番目のアプローチ（セクション4.2.2）では、異なるDM ZSKからの混合RRSIGが1つのリゾルバーにキャッシュされる状況が発生します。
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.
特定のイエティルートサーバーがサービスを提供するイエティルートゾーンには、イエティルートゾーンをサービスするDMからそのイエティルートサーバーにZSKを使用して生成された署名が含まれることがわかります。リゾルバーでキャッシュされた署名は、任意のYeti-Rootサーバーから取得される可能性があるため、異なるZSKによって生成された署名の混合であることが期待されます。すべてのZSKが含まれているDNSKEY RRsetを介して、Yeti KSKによる署名によってすべての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）で「成功」を示していることが確認されました。その後、3つのDMで実装され、注意深く調整されて、すべてのイエティリゾルバーオペレーターとイエティのメーリングリストの参加者に公開されました。少なくとも45のイエティリゾルバー（イエティオペレーターによって展開）が監視されており、何か問題があった場合にレポートトリガーを設定していました。さらに、Yetiメーリングリストは、他の参加者からのエラー報告を受け付けています。これまでのところ、Yetiテストベッドはこの構成（複数のZSKを使用）で2年間運用されています。この構成は、個々の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.
このアプローチのもう1つの結果は、Yeti-Rootゾーンの頂点DNSKEY RRsetが、ルートゾーンの対応するDNSKEY RRsetよりもはるかに大きいことです。これにより、より多くのスペースが必要になり、特にKSKロールオーバー中にDNSKEY RRsetのクエリに対する応答が大きくなります。
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.
3つの関連するDNSSEC KSKロールオーバー演習は、ルートゾーンでのロールオーバーの計画と実行と同時に、Yeti DNSテストベッドで実行されました。これらの演習の簡単な説明を以下に示します。
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.
イエティDNSテストベッドで実行された最初のKSKロールオーバーは、発信KSKを廃止する前に、[RFC5011]で指定された30日間のホールドダウンタイマーを意図的に無視しました。
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.
この変更に続いて、一部（すべてではない）の検証イエティリゾルバーのクライアントで解決エラーが発生した（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:
2番目のYeti 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 |
+-----------------+----------------+----------+
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]を実行していた1つの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）によってKSKロールオーバーに関する一般的なアドバイスで強調されました。ルートゾーンでBIND 9 [ISC-BIND]のユーザーに。検証を実行するように構成されたすべてのビューに「管理対象キー」構成が存在する場合、すべてのビューのトラストアンカーは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応答のサイズの増加が予想されます。イエティDNSテストベッドで実行された3番目の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で説明されているように、Yeti DNSテストベッドでは、各DMは独自のZSKセットの制御を維持できます。 3つのDMのそれぞれによって同時ZSKロールオーバーが実行されるKSKロールオーバー中、存在する頂点DNSKEY RRの最大数は8（受信および送信KSKに加えて、3つの各ZSKの受信および送信）です。ただし、実際には、このような同時実行は発生しませんでした。 KSKロールオーバー中にBII ZSKのみがロールされたため、3つの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で説明されているように、RIPE Atlasプローブを使用して、DNSKEYクエリをイエティルートサーバーに直接送信しました。クエリと失敗の数が記録され、クエリが送信されたときの応答サイズに従って分類されました。結果の要約（[YetiLR]）は次のとおりです。
+---------------+----------+---------------+--------------+
| 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).
ここで簡単に説明されている一般的なアプローチは、ルートサーバーシステムとは別個であるがインターネット上でライブテストベッドとして構築されたイエティDNSテストベッドの設計が、汎用アクティブ測定機能（RIPEなど）の使用を容易にする方法の有用な例を提供します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システムの一般的なアプローチであり、運用トラフィックを理解するために、オペレーターはトラフィックを詳細に把握する必要があります。信頼できるサーバーの場合、クエリの受信時に提供されているゾーンの情報を使用して応答を合成できるため、多くの場合、受信クエリトラフィックのキャプチャで十分です。クエリは通常、断片化されないように十分に小さく、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 Many Mirror Verifier」（YmmV）を使用して応答したルートサーバーシステムから受信した応答と比較したいという要望があります。 。いくつかのイエティルートサーバーは、たとえばdnstapを使用して、ネームサーバー内から完全なDNSメッセージを回復することができました。ただし、すべてのサーバーがその機能を提供するわけではなく、一貫したアプローチが望まれました。
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トランスポートのフラグメンテーションと使用をトリガーすることが期待された（場合によっては設計された）実験を実行する要件により、フラグメントとTCPストリームの再構成を実行する新しいツールPcapParserが開発されました生のパケットキャプチャデータから。 PcapParserの簡単な説明は、付録Dに含まれています。
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は番号を付け直してから約13年経過しても、古いアドレスでトラフィックを受信し続けていました[Wessels2015]。
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-Rootサーバー名は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 particular, the Go DNS library. Bug reports were filed against both Knot and the Go DNS library, and both were resolved in subsequent releases.
Knot 2.0を実行するYeti-Rootサーバーは、以前の例へのポインタを使用して、長さゼロのラベル（ルートドメイン、多くの場合「。」として表される）を圧縮することが確認されました。このエンコーディングは合法ですが、ルートラベルのエンコードサイズを1オクテットから2オクテットに増やします。また、一部のクライアントソフトウェア、特に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.
イエティDNSは、DNSルートシステムのライブテストベッドとして設計および実装されました。これは、IANAによって公開されたルートゾーンから派生したルートゾーン（このドキュメントでは「Yeti-Root」）を提供し、テストベッドシステムでの機能を保証するために必要な構造変更のみを提供します。イエティ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-RootサーバーがYeti-Rootゾーンを取得できなかった2つのケース。 1220オクテットのTCP MSSを設定することで軽減されます（セクション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 3つの自律イエティルートゾーンの署名者と25のイエティルートサーバーで正常に動作し、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のサポートが実行されました。 「managed-keys」で構成された場合の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がルート（空の）ラベルに対してラベル圧縮を実行したことが確認されました。これにより、ルートラベル自体が1つだけを必要とするのに対し、ポインターは2つのオクテットとしてエンコードされるため（セクション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.
イエティ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のみのイエティルートサーバー：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応答サイズを減らす1つの可能な方法は、楕円曲線署名アルゴリズムに変更することです。これは原則としてKSKとZSKで別々に行うことができますが、RIPE NCCは最近調査を行い、一部のリゾルバーはKSKとZSKの両方が同じアルゴリズムを使用する必要があることを発見しました。これは、アルゴリズムロールにもKSKロールが含まれることを意味します。ルートでアルゴリズムロールを実行することは興味深い課題です。
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 ゾーン転送のスティッキー通知：イエティDNSテストベッドのゾーン転送メカニズムとしてのIXFRの非適用性は、各スレーブのマスターサーバーのスティッキー設定を実装することで軽減できます。これは、ゾーンの同等であるが一致しないバージョンが異なるマスターによって提供される場合（Yetiのように）、ゾーンの整合性を損なうことなく、最初のAXFR応答にIXFR要求を追跡できるようにするためです。
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の運用に影響を与える可能性があります。たとえば、ハッカーが1つのDMのGitリポジトリを危険にさらし、不要な変更をYeti DMシステムにプッシュする可能性があります。これにより、一定期間、不良ルートサーバーまたは不良キーが導入される可能性があります。
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-dns.org>および<github.com>で公開されています。ハッカーが偽のページを作成することでこれらのWebサイトを改ざんした場合、新しいリゾルバはその方法を失い、不正なルートで設定される可能性があります。
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は、Yeti DNSテストベッドの重要な研究目標です。ルートゾーンのDNSSECの中心的な機能を減らすために、複数の独立して操作されるDNSSEC署名者と複数の対応するZSKを使用して、Yeti-Rootゾーンに署名します（セクション4.2を参照）。 ICANNのKSKロールオーバーを検証するために、RFC 5011に従って、Yeti KSKを3回ロールしました。いくつかの観察があります（セクション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 NOTIFY）」、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。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、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]歌、L。、「ATR：大規模なDNS応答に対する追加の切り捨て応答」、作業中、draft-song-atr-large-resp-02、2018年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.、Colitti、L.、Kumari、W.、Vyncke、E.、Kaeo、M。、およびT. Taylor、「なぜ演算子はフラグメントをフィルタリングし、それが何を意味するのか」、進行中の作業、ドラフト- taylor-v6ops-fragdrop-02、2013年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メッセージフラグメント」、Work in Progress、draft-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 Auto Update」、コミット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/>.
[HOW_ATR_WORKS] Huston、G。、「ATRは実際どのように機能しますか？」、APNICブログ、2018年4月、<https://blog.apnic.net/2018/04/16/ how-well-does-atr-actually -work />。
[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。、およびR. Balasubramanian、「DNSSEC Key Management Implementation for the Root Zone（DRAFT）」、2010年5月、<http://www.root-dnssec.org/wp- content / uploads / 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 Rollover External Test Plan」、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。、「Dealing with IPv6 fragmentation in the DNS」、APNICブログ、2017年8月、<https://blog.apnic.net/2017/08/22/ dealing-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]リスク、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。、「Hierarchical Anycast for Global Service Distribution」、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、「Identifier Technology Innovation Report」、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。、「Yeti KSKロールオーバー中のDNSSECの問題」、Yeti 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。、「Yeti実験計画for PINZ」、Yeti DNSブログ、2018年5月、<http://yeti-dns.org/yeti/blog/2018/05/01/ Experiment-plan-for- 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]インターネットアーキテクチャボード、「IAB Technical Comment on the Unique DNS Root」、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 / RFC6891、2013年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]ブランシェ、M.、L-J。 Liman、「DNS Root Name Service Protocol and Deployment Requirements」、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 / RFC8324、2018年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）、「Services Expectations of Root Servers」、RSSAC001バージョン1、2015年12月、<https://www.icann.org/en/system/files/files/ rssac-001- root-service-expectations-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）Concluded WG」、<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、「Root Scaling Study：Description of the DNS Root Scaling Model」、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]アンドリュースM。、「TCPはIPV6_USE_MIN_MTUを尊重できません」、作業中、draft-andrews-tcp-and-ipv6-use-minmtu-04、2015年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、「Thirteen Years of 'Old J-Root'」、DNS-OARC Fall 2015 Workshop、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/ large-packet-impact-during -yeti-ksk-rollover.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
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.
イエティルートネームサーバーがプライミングリクエストに応答します。権限のあるサーバーは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
;; 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 IN NSyeti.bofh.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 IN NS yeti.ipv6.ernet.in。 。 86400 IN NS yeti.aquaray.com。 。 86400 IN NS yeti.jhcloos.net。 。 NS yeti.mind-dns.nlの86400 。 NS dahu1.yeti.eu.orgの86400。 。 NS dahu2.yeti.eu.orgの86400。 。 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。 。 NS yeti-dns01.dnsworkshop.orgの86400。 。 NS yeti-dns02.dnsworkshop.orgの86400。 。 NS 3f79bb7b435b05321651daefd374cd.yeti-dns.netの86400。 。 NS ca978112ca1bbdcafac231b39a23dc.yeti-dns.netの86400。 。 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 ==）
;; 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
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 |
+----------------------+---------------------------------+----------+
Various tools were developed to support the Yeti DNS testbed, a selection of which are described briefly below.
イエティ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 Many Mirror Verifier"）は、DNS管理者がリゾルバーからルートサーバーシステムに送信されたトラフィックを簡単かつ安全にキャプチャし、それをイエティルートサーバーに向けて再生するように設計されています。両方のシステムからの応答が記録および比較され、違いがログに記録されます。 <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で使用されるモジュールで、断片化されたIPv6データグラムとTCPセグメントをPCAPアーカイブから再構成し、それらに含まれる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-layer-fragmentationは、[FRAGMENTS]に基づいて、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>.
[ATR]と[HOW_ATR_WORKS]で説明されているように、DNS_ATRはDNS追加切り捨て応答（ATR）の実装です。 DNS_ATRは、リゾルバーと権限のあるサーバー間のプロキシとして機能し、クエリと応答をサイレントで透過的なリスナーとして転送します。指定されたしきい値（デフォルトでは1280オクテット）より大きい応答は、大きな応答の直後に送信される追加の切り捨てられた応答をトリガーします。 <https://github.com/songlinjian/ DNS_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.
一部のコメンテーターは、Yeti DNSプロジェクトが事実上代替ルートを運用しており、[RFC2826]で公開されたIABのコメントに異議を唱えていることに懸念を表明しています。他のそのような代替ルートは、新しいトップレベルラベルの導入、またはルートサーバーシステムに存在するトップレベルラベルの異なる使用により、DNSのネームスペースでエンドユーザーの混乱と不安定性を引き起こしたと考えられています。イエティDNSプロジェクトのコーディネーターは、この意味でイエティ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:
まず、著者は時間とリソースを寄付することにより、Yeti 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:
対面式の会議で、または事実上電話やメーリングリストを介して、Yetiに重要なアドバイスやコメントを提供してくれたすべての人々に感謝します。一部の個人は次のとおりです。
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.
ウー・エクアン、周宏仁、チェン・ユンチン、シャ・チョンフェン、タン・シオンヤン、リー・ユシャオ、フォン・ミン、チャン・トンクス、ドゥアン・シャオドン、ワン・ヤン、ワン・ジイ、ワン・レイ、ジャオ・ジフェン、チェン・ウェイ、ワン・ウェイ、ワン・ジロング、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ウィルソン、キルナム・チョン。
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:
著者はまた、Independent Submissions Editorial Boardと、このドキュメントの明確性を向上させるのに役立った意見を持つ次のレビューアーの支援を認めます。
Joe Abley, Paul Mockapetris, and Subramanian Moonesamy.
Joe Abley、Paul Mockapetris、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/
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/
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/
ドンl IU北京インターネットインスティテュート2階、5号館、58番ジンGH爱W UL U、BD A北京100176中国Eメール：No. 6 @比I group.com URI：HTTP：// woo woo。than I group .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、California 94062 United States of Email Email：vixie@tisf.net URI：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/
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/
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-travellers.org