rfc8483.txt   test8483.v2v3fixed.txt 
skipping to change at page 2, line 12 skipping to change at line 47
and how to provide feedback on it may be obtained at 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 Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Requirements Notation and Conventions . . . . . . . . . . . . 5 2. Requirements Notation and Conventions
3. Areas of Study . . . . . . . . . . . . . . . . . . . . . . . 5 3. Areas of Study
3.1. Implementation of a Testbed like the Root Server System . 5 3.1. Implementation of a Testbed like the Root Server
3.2. Yeti-Root Zone Distribution . . . . . . . . . . . . . . . 5 System
3.3. Yeti-Root Server Names and Addressing . . . . . . . . . . 5 3.2. Yeti-Root Zone Distribution
3.4. IPv6-Only Yeti-Root Servers . . . . . . . . . . . . . . . 6 3.3. Yeti-Root Server Names and Addressing
3.5. DNSSEC in the Yeti-Root Zone . . . . . . . . . . . . . . 6 3.4. IPv6-Only Yeti-Root Servers
4. Yeti DNS Testbed Infrastructure . . . . . . . . . . . . . . . 7 3.5. DNSSEC in the Yeti-Root Zone
4.1. Root Zone Retrieval . . . . . . . . . . . . . . . . . . . 8 4. Yeti DNS Testbed Infrastructure
4.2. Transformation of Root Zone to Yeti-Root Zone . . . . . . 9 4.1. Root Zone Retrieval
4.2.1. ZSK and KSK Key Sets Shared between DMs . . . . . . . 10 4.2. Transformation of Root Zone to Yeti-Root Zone
4.2.2. Unique ZSK per DM; No Shared KSK . . . . . . . . . . 10 4.2.1. ZSK and KSK Key Sets Shared between DMs
4.2.3. Preserving Root Zone NSEC Chain and ZSK RRSIGs . . . 11 4.2.2. Unique ZSK per DM; No Shared KSK
4.3. Yeti-Root Zone Distribution . . . . . . . . . . . . . . . 12 4.2.3. Preserving Root Zone NSEC Chain and ZSK
4.4. Synchronization of Service Metadata . . . . . . . . . . . 12 RRSIGs
4.5. Yeti-Root Server Naming Scheme . . . . . . . . . . . . . 13 4.3. Yeti-Root Zone Distribution
4.6. Yeti-Root Servers . . . . . . . . . . . . . . . . . . . . 14 4.4. Synchronization of Service Metadata
4.7. Experimental Traffic . . . . . . . . . . . . . . . . . . 16 4.5. Yeti-Root Server Naming Scheme
4.8. Traffic Capture and Analysis . . . . . . . . . . . . . . 16 4.6. Yeti-Root Servers
5. Operational Experience with the Yeti DNS Testbed . . . . . . 17 4.7. Experimental Traffic
5.1. Viability of IPv6-Only Operation . . . . . . . . . . . . 17 4.8. Traffic Capture and Analysis
5.1.1. IPv6 Fragmentation . . . . . . . . . . . . . . . . . 18 5. Operational Experience with the Yeti DNS Testbed
5.1.2. Serving IPv4-Only End-Users . . . . . . . . . . . . . 19 5.1. Viability of IPv6-Only Operation
5.2. Zone Distribution . . . . . . . . . . . . . . . . . . . . 19 5.1.1. IPv6 Fragmentation
5.2.1. Zone Transfers . . . . . . . . . . . . . . . . . . . 19 5.1.2. Serving IPv4-Only End-Users
5.2.2. Delays in Yeti-Root Zone Distribution . . . . . . . . 20 5.2. Zone Distribution
5.2.3. Mixed RRSIGs from Different DM ZSKs . . . . . . . . . 21 5.2.1. Zone Transfers
5.3. DNSSEC KSK Rollover . . . . . . . . . . . . . . . . . . . 22 5.2.2. Delays in Yeti-Root Zone Distribution
5.3.1. Failure-Case KSK Rollover . . . . . . . . . . . . . . 22 5.2.3. Mixed RRSIGs from Different DM ZSKs
5.3.2. KSK Rollover vs. BIND9 Views . . . . . . . . . . . . 22 5.3. DNSSEC KSK Rollover
5.3.3. Large Responses during KSK Rollover . . . . . . . . . 23 5.3.1. Failure-Case KSK Rollover
5.4. Capture of Large DNS Response . . . . . . . . . . . . . . 24 5.3.2. KSK Rollover vs. BIND9 Views
5.5. Automated Maintenance of the Hints File . . . . . . . . . 24 5.3.3. Large Responses during KSK Rollover
5.6. Root Label Compression in Knot DNS Server . . . . . . . . 25 5.4. Capture of Large DNS Response
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.5. Automated Maintenance of the Hints File
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 5.6. Root Label Compression in Knot DNS Server
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 6. Conclusions
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations
9.1. Normative References . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations
9.2. Informative References . . . . . . . . . . . . . . . . . 29 9. References
Appendix A. Yeti-Root Hints File . . . . . . . . . . . . . . . . 33 9.1. Normative References
Appendix B. Yeti-Root Server Priming Response . . . . . . . . . 34 9.2. Informative References
Appendix C. Active IPv6 Prefixes in Yeti DNS Testbed . . . . . . 36 Appendix A. Yeti-Root Hints File
Appendix D. Tools Developed for Yeti DNS Testbed . . . . . . . . 36 Appendix B. Yeti-Root Server Priming Response
Appendix E. Controversy . . . . . . . . . . . . . . . . . . . . 37 Appendix C. Active IPv6 Prefixes in Yeti DNS Testbed
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38 Appendix D. Tools Developed for Yeti DNS Testbed
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Appendix E. Controversy
Acknowledgments
Authors' Addresses
1. Introduction 1. Introduction
The Domain Name System (DNS), as originally specified in [RFC1034] The Domain Name System (DNS), as originally specified in [RFC1034]
and [RFC1035], has proved to be an enduring and important platform and [RFC1035], has proved to be an enduring and important platform
upon which almost every end-user of the Internet relies. Despite its upon which almost every end-user of the Internet relies. Despite its
longevity, extensions to the protocol, new implementations, and longevity, extensions to the protocol, new implementations, and
refinements to DNS operations continue to emerge both inside and refinements to DNS operations continue to emerge both inside and
outside the IETF. outside the IETF.
The Root Server system in particular has seen technical innovation The Root Server system in particular has seen technical innovation
and development, for example, in the form of wide-scale anycast and development, for example, in the form of wide-scale anycast
deployment, the mitigation of unwanted traffic on a global scale, the deployment, the mitigation of unwanted traffic on a global scale, the
widespread deployment of Response Rate Limiting [RRL], the widespread deployment of Response Rate Limiting [RRL], the
introduction of IPv6 transport, the deployment of DNSSEC, changes in introduction of IPv6 transport, the deployment of DNSSEC, changes in
DNSSEC key sizes, and preparations to roll the root zone's Key DNSSEC key sizes, and preparations to roll the root zone's Key
Signing Key (KSK) and corresponding trust anchor. These projects Signing Key (KSK) and corresponding trust anchor. These projects
created tremendous qualitative operational change and required created tremendous qualitative operational change and required
impressive caution and study prior to implementation. They took impressive caution and study prior to implementation. They took
place in parallel with the quantitative expansion or delegations for place in parallel with the quantitative expansion or delegations for
new TLDs (see <https://newgtlds.icann.org/>). new TLDs (see https://newgtlds.icann.org/).
Aspects of the operational structure of the Root Server system have Aspects of the operational structure of the Root Server system have
been described in such documents as [TNO2009], [ISC-TN-2003-1], been described in such documents as [TNO2009], [ISC-TN-2003-1],
[RSSAC001], and [RFC7720]. Such references, considered together, [RSSAC001], and [RFC7720]. Such references, considered together,
provide sufficient insight into the operations of the system as a provide sufficient insight into the operations of the system as a
whole that it is straightforward to imagine structural changes to the whole that it is straightforward to imagine structural changes to the
Root Server system's infrastructure and to wonder what the Root Server system's infrastructure and to wonder what the
operational implications of such changes might be. operational implications of such changes might be.
The Yeti DNS Project was conceived in May 2015 with the aim of The Yeti DNS Project was conceived in May 2015 with the aim of
skipping to change at page 5, line 28 skipping to change at line 203
is not affiliated with the IETF, ICANN, IANA, or any Root Server is not affiliated with the IETF, ICANN, IANA, or any Root Server
Operator. Thus, the topics and areas for study were selected by (and Operator. Thus, the topics and areas for study were selected by (and
for) the proponents of the Yeti project to address their own concerns 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 and in the hope that the information and tools provided would be of
wider interest. wider interest.
Each example included below is illustrated with indicative questions. Each example included below is illustrated with indicative questions.
3.1. Implementation of a Testbed like the Root Server System 3.1. Implementation of a Testbed like the Root Server System
o How can a testbed be constructed and deployed on the Internet, * How can a testbed be constructed and deployed on the Internet,
allowing useful public participation without any risk of allowing useful public participation without any risk of
disruption of the Root Server system? disruption of the Root Server system?
o How can representative traffic be introduced into such a testbed * How can representative traffic be introduced into such a testbed
such that insights into the impact of specific differences between such that insights into the impact of specific differences between
the testbed and the Root Server system can be observed? the testbed and the Root Server system can be observed?
3.2. Yeti-Root Zone Distribution 3.2. Yeti-Root Zone Distribution
o What are the scaling properties of Yeti-Root zone distribution as * What are the scaling properties of Yeti-Root zone distribution as
the number of Yeti-Root servers, Yeti-Root server instances, or the number of Yeti-Root servers, Yeti-Root server instances, or
intermediate distribution points increases? intermediate distribution points increases?
3.3. Yeti-Root Server Names and Addressing 3.3. Yeti-Root Server Names and Addressing
o What naming schemes other than those closely analogous to the use * What naming schemes other than those closely analogous to the use
of ROOT-SERVERS.NET in the production root zone are practical, and of ROOT-SERVERS.NET in the production root zone are practical, and
what are their respective advantages and disadvantages? what are their respective advantages and disadvantages?
o What are the risks and benefits of signing the zone that contains * What are the risks and benefits of signing the zone that contains
the names of the Yeti-Root servers? the names of the Yeti-Root servers?
o What automatic mechanisms might be useful to improve the rate at * What automatic mechanisms might be useful to improve the rate at
which clients of Yeti-Root servers are able to react to a Yeti- which clients of Yeti-Root servers are able to react to a Yeti-
Root server renumbering event? Root server renumbering event?
3.4. IPv6-Only Yeti-Root Servers 3.4. IPv6-Only Yeti-Root Servers
o Are there negative operational effects in the use of IPv6-only * Are there negative operational effects in the use of IPv6-only
Yeti-Root servers, compared to the use of servers that are dual- Yeti-Root servers, compared to the use of servers that are dual-
stack? stack?
o What effect does the IPv6 fragmentation model have on the * What effect does the IPv6 fragmentation model have on the
operation of Yeti-Root servers, compared with that of IPv4? operation of Yeti-Root servers, compared with that of IPv4?
3.5. DNSSEC in the Yeti-Root Zone 3.5. DNSSEC in the Yeti-Root Zone
o Is it practical to sign the Yeti-Root zone using multiple, * Is it practical to sign the Yeti-Root zone using multiple,
independently operated DNSSEC signers and multiple corresponding independently operated DNSSEC signers and multiple corresponding
Zone Signing Keys (ZSKs)? Zone Signing Keys (ZSKs)?
o To what extent is [RFC5011] ("Automated Updates of DNS Security * To what extent is [RFC5011] ("Automated Updates of DNS Security
(DNSSEC) Trust Anchors") supported by resolvers? (DNSSEC) Trust Anchors") supported by resolvers?
o Does the KSK Rollover plan designed and in the process of being * Does the KSK Rollover plan designed and in the process of being
implemented by ICANN work as expected on the Yeti testbed? implemented by ICANN work as expected on the Yeti testbed?
o What is the operational impact of using much larger RSA key sizes * What is the operational impact of using much larger RSA key sizes
in the ZSKs used in a root? in the ZSKs used in a root?
o What are the operational consequences of choosing DNSSEC * What are the operational consequences of choosing DNSSEC
algorithms other than RSA to sign a root? algorithms other than RSA to sign a root?
4. Yeti DNS Testbed Infrastructure 4. Yeti DNS Testbed Infrastructure
The purpose of the testbed is to allow DNS queries from stub The purpose of the testbed is to allow DNS queries from stub
resolvers, mediated by recursive resolvers, to be delivered to Yeti- resolvers, mediated by recursive resolvers, to be delivered to Yeti-
Root servers, and for corresponding responses generated on the Yeti- Root servers, and for corresponding responses generated on the Yeti-
Root servers to be returned, as illustrated in Figure 1. Root servers to be returned, as illustrated in Figure 1.
,----------. ,-----------. ,------------. ,----------. ,-----------. ,------------.
skipping to change at page 7, line 28 skipping to change at line 280
`- resolver `- Yeti-Root trust `- with DNSKEY RRset `- resolver `- Yeti-Root trust `- with DNSKEY RRset
configured anchor signed by configured anchor signed by
Yeti-Root KSK Yeti-Root KSK
Figure 1: High-Level Testbed Components Figure 1: High-Level Testbed Components
To use the Yeti DNS testbed, a recursive resolver must be configured To use the Yeti DNS testbed, a recursive resolver must be configured
to use the Yeti-Root servers. That configuration consists of a list to use the Yeti-Root servers. That configuration consists of a list
of names and addresses for the Yeti-Root servers (often referred to of names and addresses for the Yeti-Root servers (often referred to
as a "hints file") that replaces the corresponding hints used for the as a "hints file") that replaces the corresponding hints used for the
production Root Server system (Appendix A). If resolvers are production Root Server system (Section appendix.a). If resolvers are
configured to validate DNSSEC, then they also need to be configured 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 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 DNS Project, in place of the normal trust anchor set used for the
Root Zone. Root Zone.
Since the Yeti root(s) are signed with Yeti keys, rather than those Since the Yeti root(s) are signed with Yeti keys, rather than those
used by the IANA Root, corresponding changes are needed in the used by the IANA Root, corresponding changes are needed in the
resolver trust anchors. Corresponding changes are required in the resolver trust anchors. Corresponding changes are required in the
Yeti-Root hints file Appendix A. Those changes would be properly Yeti-Root hints file Section appendix.a. Those changes would be
rejected as bogus by any validator using the production Root Server properly rejected as bogus by any validator using the production Root
system's root zone trust anchor set. Server system's root zone trust anchor set.
Stub resolvers become part of the Yeti DNS testbed by their use of Stub resolvers become part of the Yeti DNS testbed by their use of
recursive resolvers that are configured as described above. recursive resolvers that are configured as described above.
The data flow from IANA to stub resolvers through the Yeti testbed is 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 illustrated in Figure 2 and is described in more detail in the
sections that follow. sections that follow.
,----------------. ,----------------.
,-- / IANA Root Zone / ---. ,-- / IANA Root Zone / ---.
| `----------------' | | `----------------' |
| | | | | |
| | | Root Zone | | | Root Zone
,--------------. ,---V---. ,---V---. ,---V---. ,--------------. ,---V---. ,---V---. ,---V---.
| Yeti Traffic | | BII | | WIDE | | TISF | | Yeti Traffic | | BII | | WIDE | | TISF |
| Collection | | DM | | DM | | DM | | Collection | | DM | | DM | | DM |
`----+----+----' `---+---' `---+---' `---+---' `----+----+----' `---+---' `---+---' `---+---'
| | ,-----' ,-------' `----. | | ,-----' ,-------' `----.
| | | | | Yeti-Root | | | | | Yeti-Root
^ ^ | | | Zone ^ ^ | | | Zone
| | ,---V---. ,---V---. ,---V---. | | ,---V---. ,---V---. ,---V---.
| `---+ Yeti | | Yeti | . . . . . . . | Yeti | | `---+ Yeti | | Yeti | . . . . . . . | Yeti |
| | Root | | Root | | Root | | | Root | | Root | | Root |
| `---+---' `---+---' `---+---' | `---+---' `---+---' `---+---'
| | | | DNS | | | | DNS
| | | | Response | | | | Response
| ,--V----------V-------------------------V--. | ,--V----------V-------------------------V--.
`---------+ Yeti Resolvers | `---------+ Yeti Resolvers |
`--------------------+---------------------' `--------------------+---------------------'
| DNS | DNS
| Response | Response
,--------------------V---------------------. ,--------------------V---------------------.
| Yeti Stub Resolvers | | Yeti Stub Resolvers |
`------------------------------------------' `------------------------------------------'
The three coordinators of the Yeti DNS testbed: The three coordinators of the Yeti DNS testbed:
BII : Beijing Internet Institute BII : Beijing Internet Institute
WIDE: Widely Integrated Distributed Environment Project WIDE: Widely Integrated Distributed Environment Project
TISF: A collaborative engineering and security project by Paul Vixie TISF: A collaborative engineering and security project by Paul Vixie
Figure 2: Testbed Data Flow Figure 2: Testbed Data Flow
Note that the roots are not bound to Distribution Masters (DMs). DMs 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 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 that updates the latest zone can notify all roots, so the zone
transfer can happen between any DM and any root. transfer can happen between any DM and any root.
4.1. Root Zone Retrieval 4.1. Root Zone Retrieval
skipping to change at page 9, line 23 skipping to change at line 365
At the time of writing, unauthenticated zone transfers of the Root At the time of writing, unauthenticated zone transfers of the Root
Zone are available directly from B-Root, C-Root, F-Root, G-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 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 XFR.LAX.DNS.ICANN.ORG; and via FTP from sites maintained by the Root
Zone Maintainer and the IANA Functions Operator. The Yeti DNS Zone Maintainer and the IANA Functions Operator. The Yeti DNS
testbed retrieves the Root Zone using zone transfers from F-Root. 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: The schedule on which F-Root is polled by each Yeti DM is as follows:
+-------------+-----------------------+ +-------------+-----------------------+
| DM Operator | Time | | DM Operator | Time |
+-------------+-----------------------+ +=============+=======================+
| BII | UTC hour + 00 minutes | | BII | UTC hour + 00 minutes |
+-------------+-----------------------+
| WIDE | UTC hour + 20 minutes | | WIDE | UTC hour + 20 minutes |
+-------------+-----------------------+
| TISF | UTC hour + 40 minutes | | TISF | UTC hour + 40 minutes |
+-------------+-----------------------+ +-------------+-----------------------+
Table 1
The Yeti DNS testbed uses multiple DMs, each of which acts The Yeti DNS testbed uses multiple DMs, each of which acts
autonomously and equivalently to its siblings. Any single DM can act autonomously and equivalently to its siblings. Any single DM can act
to distribute new revisions of the Yeti-Root zone and is also to distribute new revisions of the Yeti-Root zone and is also
responsible for signing the RRsets that are changed as part of the responsible for signing the RRsets that are changed as part of the
transformation of the Root Zone into the Yeti-Root zone described in transformation of the Root Zone into the Yeti-Root zone described in
Section 4.2. This multiple DM model intends to provide a basic Section 4.2. This multiple DM model intends to provide a basic
structure to implement the idea of shared zone control as proposed in structure to implement the idea of shared zone control as proposed in
[ITI2014]. [ITI2014].
4.2. Transformation of Root Zone to Yeti-Root Zone 4.2. Transformation of Root Zone to Yeti-Root Zone
skipping to change at page 12, line 9 skipping to change at line 498
replacement signatures over the apex DNSKEY and NS RRsets. Source replacement signatures over the apex DNSKEY and NS RRsets. Source
data would continue to flow from the Root Server system through the 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 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 required on the DMs, and the source NSEC and most RRSIGs would remain
intact. intact.
This approach has been suggested in order to keep minimal changes This approach has been suggested in order to keep minimal changes
from the IANA Root zone and provide cryptographically verifiable from the IANA Root zone and provide cryptographically verifiable
confidence that no owner name in the root zone had been changed in 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, the process of producing the Yeti-Root zone from the Root Zone,
thereby addressing one of the concerns described in Appendix E in a thereby addressing one of the concerns described in
way that can be verified automatically. Section appendix.e in a way that can be verified automatically.
4.3. Yeti-Root Zone Distribution 4.3. Yeti-Root Zone Distribution
Each Yeti DM is configured with a full list of Yeti-Root server Each Yeti DM is configured with a full list of Yeti-Root server
addresses to send NOTIFY [RFC1996] messages to. This also forms the addresses to send NOTIFY [RFC1996] messages to. This also forms the
basis for an address-based access-control list for zone transfers. basis for an address-based access-control list for zone transfers.
Authentication by address could be replaced with more rigorous Authentication by address could be replaced with more rigorous
mechanisms (e.g., using Transaction Signatures (TSIGs) [RFC2845]). mechanisms (e.g., using Transaction Signatures (TSIGs) [RFC2845]).
This has not been done at the time of writing since the use of 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 address-based controls avoids the need for the distribution of shared
skipping to change at page 13, line 16 skipping to change at line 551
remote servers. For example, at BII we push to all three DMs' remote servers. For example, at BII we push to all three DMs'
repositories as follows: repositories as follows:
$ git remote -v $ git remote -v
origin yeticonf@yeti-conf.dns-lab.net:dm (fetch) origin yeticonf@yeti-conf.dns-lab.net:dm (fetch)
origin yeticonf@yeti-conf.dns-lab.net:dm (push) origin yeticonf@yeti-conf.dns-lab.net:dm (push)
origin yeticonf@yeti-dns.tisf.net:dm (push) origin yeticonf@yeti-dns.tisf.net:dm (push)
origin yeticonf@yeti-repository.wide.ad.jp:dm (push) origin yeticonf@yeti-repository.wide.ad.jp:dm (push)
For more detailed information on DM synchronization, please see this For more detailed information on DM synchronization, please see this
document in Yeti's GitHub repository: <https://github.com/BII-Lab/ document in Yeti's GitHub repository: https://github.com/BII-Lab/
Yeti-Project/blob/master/doc/Yeti-DM-Sync.md>. Yeti-Project/blob/master/doc/Yeti-DM-Sync.md.
4.5. Yeti-Root Server Naming Scheme 4.5. Yeti-Root Server Naming Scheme
The current naming scheme for Root Servers was normalized to use The current naming scheme for Root Servers was normalized to use
single-character host names ("A" through "M") under the domain ROOT- single-character host names ("A" through "M") under the domain ROOT-
SERVERS.NET, as described in [RSSAC023]. The principal benefit of SERVERS.NET, as described in [RSSAC023]. The principal benefit of
this naming scheme was that DNS label compression could be used to this naming scheme was that DNS label compression could be used to
produce a priming response that would fit within 512 bytes at the produce a priming response that would fit within 512 bytes at the
time it was introduced, where 512 bytes is the maximum DNS message time it was introduced, where 512 bytes is the maximum DNS message
size using UDP transport without EDNS(0) [RFC6891]. size using UDP transport without EDNS(0) [RFC6891].
skipping to change at page 13, line 49 skipping to change at line 584
empty additional section if the configuration parameter "minimum- empty additional section if the configuration parameter "minimum-
responses" is set, forcing resolvers to complete the priming process responses" is set, forcing resolvers to complete the priming process
with a set of conventional recursive lookups in order to resolve with a set of conventional recursive lookups in order to resolve
addresses for each Yeti-Root server. The Yeti-Root servers running addresses for each Yeti-Root server. The Yeti-Root servers running
NSD were observed to return a fully populated additional section NSD were observed to return a fully populated additional section
(depending, of course, on the EDNS buffer size in use). (depending, of course, on the EDNS buffer size in use).
Various approaches to normalize the composition of the priming Various approaches to normalize the composition of the priming
response were considered, including: response were considered, including:
o Require use of DNS implementations that exhibit a desired behavior * Require use of DNS implementations that exhibit a desired behavior
in the priming response. in the priming response.
o Modify nameserver software or configuration as used by Yeti-Root * Modify nameserver software or configuration as used by Yeti-Root
servers. servers.
o Isolate the names of Yeti-Root servers in one or more zones that * Isolate the names of Yeti-Root servers in one or more zones that
could be slaved on each Yeti-Root server, renaming servers as could be slaved on each Yeti-Root server, renaming servers as
necessary, giving each a source of authoritative data with which necessary, giving each a source of authoritative data with which
the authority section of a priming response could be fully the authority section of a priming response could be fully
populated. This is the approach used in the Root Server system populated. This is the approach used in the Root Server system
with the ROOT-SERVERS.NET zone. with the ROOT-SERVERS.NET zone.
The potential mitigation of renaming all Yeti-Root servers using a The potential mitigation of renaming all Yeti-Root servers using a
scheme that would allow their names to exist directly in the root scheme that would allow their names to exist directly in the root
zone was not considered because that approach implies the invention zone was not considered because that approach implies the invention
of new top-level labels not present in the Root Zone. of new top-level labels not present in the Root Zone.
skipping to change at page 15, line 7 skipping to change at line 621
4.6. Yeti-Root Servers 4.6. Yeti-Root Servers
Various volunteers have donated authoritative servers to act as Yeti- Various volunteers have donated authoritative servers to act as Yeti-
Root servers. At the time of writing, there are 25 Yeti-Root servers Root servers. At the time of writing, there are 25 Yeti-Root servers
distributed globally, one of which is named using a label as distributed globally, one of which is named using a label as
specified in IDNA2008 [RFC5890] (it is shown in the following list in specified in IDNA2008 [RFC5890] (it is shown in the following list in
punycode). punycode).
+-------------------------------------+---------------+-------------+ +-------------------------------------+---------------+-------------+
| Name | Operator | Location | | Name | Operator | Location |
+-------------------------------------+---------------+-------------+ +=====================================+===============+=============+
| bii.dns-lab.net | BII | CHINA | | bii.dns-lab.net | BII | CHINA |
+-------------------------------------+---------------+-------------+
| yeti-ns.tsif.net | TSIF | USA | | yeti-ns.tsif.net | TSIF | USA |
| yeti-ns.wide.ad.jp | WIDE Project | Japan | +-------------------------------------+---------------+-------------+
| yeti-ns.wide.ad.jp | WIDE | Japan |
| | Project | |
+-------------------------------------+---------------+-------------+
| yeti-ns.as59715.net | as59715 | Italy | | yeti-ns.as59715.net | as59715 | Italy |
+-------------------------------------+---------------+-------------+
| dahu1.yeti.eu.org | Dahu Group | France | | dahu1.yeti.eu.org | Dahu Group | France |
| ns-yeti.bondis.org | Bond Internet | Spain | +-------------------------------------+---------------+-------------+
| ns-yeti.bondis.org | Bond | Spain |
| | Internet | |
| | Systems | | | | Systems | |
+-------------------------------------+---------------+-------------+
| yeti-ns.ix.ru | Russia | MSK-IX | | yeti-ns.ix.ru | Russia | MSK-IX |
| yeti.bofh.priv.at | CERT Austria | Austria | +-------------------------------------+---------------+-------------+
| yeti.bofh.priv.at | CERT | Austria |
| | Austria | |
+-------------------------------------+---------------+-------------+
| yeti.ipv6.ernet.in | ERNET India | India | | yeti.ipv6.ernet.in | ERNET India | India |
+-------------------------------------+---------------+-------------+
| yeti-dns01.dnsworkshop.org | dnsworkshop | Germany | | yeti-dns01.dnsworkshop.org | dnsworkshop | Germany |
| | /informnis | | | | /informnis | |
+-------------------------------------+---------------+-------------+
| dahu2.yeti.eu.org | Dahu Group | France | | dahu2.yeti.eu.org | Dahu Group | France |
| yeti.aquaray.com | Aqua Ray SAS | France | +-------------------------------------+---------------+-------------+
| yeti.aquaray.com | Aqua Ray | France |
| | SAS | |
+-------------------------------------+---------------+-------------+
| yeti-ns.switch.ch | SWITCH | Switzerland | | yeti-ns.switch.ch | SWITCH | Switzerland |
+-------------------------------------+---------------+-------------+
| yeti-ns.lab.nic.cl | NIC Chile | Chile | | yeti-ns.lab.nic.cl | NIC Chile | Chile |
+-------------------------------------+---------------+-------------+
| yeti-ns1.dns-lab.net | BII | China | | yeti-ns1.dns-lab.net | BII | China |
+-------------------------------------+---------------+-------------+
| yeti-ns2.dns-lab.net | BII | China | | yeti-ns2.dns-lab.net | BII | China |
+-------------------------------------+---------------+-------------+
| yeti-ns3.dns-lab.net | BII | China | | yeti-ns3.dns-lab.net | BII | China |
+-------------------------------------+---------------+-------------+
| ca...a23dc.yeti-dns.net | Yeti-ZA | South | | ca...a23dc.yeti-dns.net | Yeti-ZA | South |
| | | Africa | | | | Africa |
+-------------------------------------+---------------+-------------+
| 3f...374cd.yeti-dns.net | Yeti-AU | Australia | | 3f...374cd.yeti-dns.net | Yeti-AU | Australia |
+-------------------------------------+---------------+-------------+
| yeti1.ipv6.ernet.in | ERNET India | India | | yeti1.ipv6.ernet.in | ERNET India | India |
+-------------------------------------+---------------+-------------+
| xn--r2bi1c.xn--h2bv6c0a.xn--h2brj9c | ERNET India | India | | xn--r2bi1c.xn--h2bv6c0a.xn--h2brj9c | ERNET India | India |
+-------------------------------------+---------------+-------------+
| yeti-dns02.dnsworkshop.org | dnsworkshop | USA | | yeti-dns02.dnsworkshop.org | dnsworkshop | USA |
| | /informnis | | | | /informnis | |
+-------------------------------------+---------------+-------------+
| yeti.mind-dns.nl | Monshouwer | Netherlands | | yeti.mind-dns.nl | Monshouwer | Netherlands |
| | Internet | | | | Internet | |
| | Diensten | | | | Diensten | |
+-------------------------------------+---------------+-------------+
| yeti-ns.datev.net | DATEV | Germany | | yeti-ns.datev.net | DATEV | Germany |
+-------------------------------------+---------------+-------------+
| yeti.jhcloos.net. | jhcloos | USA | | yeti.jhcloos.net. | jhcloos | USA |
+-------------------------------------+---------------+-------------+ +-------------------------------------+---------------+-------------+
Table 2
The current list of Yeti-Root servers is made available to a The current list of Yeti-Root servers is made available to a
participating resolver first using a substitute hints file Appendix A participating resolver first using a substitute hints file
and subsequently by the usual resolver priming process [RFC8109]. Section appendix.a and subsequently by the usual resolver priming
All Yeti-Root servers are IPv6-only, because of the IPv6-only process [RFC8109]. All Yeti-Root servers are IPv6-only, because of
Internet of the foreseeable future, and hence the Yeti-Root hints the IPv6-only Internet of the foreseeable future, and hence the Yeti-
file contains no IPv4 addresses and the Yeti-Root zone contains no Root hints file contains no IPv4 addresses and the Yeti-Root zone
IPv4 glue records. Note that the rationale of an IPv6-only testbed contains no IPv4 glue records. Note that the rationale of an
is to test whether an IPv6-only root can survive any problem or IPv6-only testbed is to test whether an IPv6-only root can survive
impact when IPv4 is turned off, much like the context of the IETF any problem or impact when IPv4 is turned off, much like the context
SUNSET4 WG [SUNSET4]. of the IETF SUNSET4 WG [SUNSET4].
At the time of writing, all root servers within the Root Server 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, 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 and all but one also serve the ARPA zone. Yeti-Root servers serve
the Yeti-Root zone only. the Yeti-Root zone only.
Significant software diversity exists across the set of Yeti-Root Significant software diversity exists across the set of Yeti-Root
servers, as reported by their volunteer operators at the time of servers, as reported by their volunteer operators at the time of
writing: writing:
o Platform: 18 of 25 Yeti-Root servers are implemented on a Virtual * Platform: 18 of 25 Yeti-Root servers are implemented on a Virtual
Private Server (VPS) rather than bare metal. Private Server (VPS) rather than bare metal.
o Operating System: 15 Yeti-Root servers run on Linux (Ubuntu, * Operating System: 15 Yeti-Root servers run on Linux (Ubuntu,
Debian, CentOS, Red Hat, and ArchLinux); 4 run on FreeBSD; 1 on Debian, CentOS, Red Hat, and ArchLinux); 4 run on FreeBSD; 1 on
NetBSD; and 1 on Windows Server 2016. NetBSD; and 1 on Windows Server 2016.
o DNS software: 16 of 25 Yeti-Root servers use BIND9 (versions * 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 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 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). (4.1.3); and 1 uses MS DNS (10.0.14300.1000).
4.7. Experimental Traffic 4.7. Experimental Traffic
For the Yeti DNS testbed to be useful as a platform for For the Yeti DNS testbed to be useful as a platform for
experimentation, it needs to carry statistically representative experimentation, it needs to carry statistically representative
traffic. Several approaches have been taken to load the system with traffic. Several approaches have been taken to load the system with
traffic, including both real-world traffic triggered by end-users and traffic, including both real-world traffic triggered by end-users and
synthetic traffic. synthetic traffic.
Resolvers that have been explicitly configured to participate in the Resolvers that have been explicitly configured to participate in the
testbed, as described in Section 4, are a source of real-world, end- testbed, as described in Section 4, are a source of real-world, end-
user traffic. Due to an efficient cache mechanism, the mean query 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 rate is less than 100 qps in the Yeti testbed, but a variety of
sources were observed as active during 2017, as summarized in sources were observed as active during 2017, as summarized in
Appendix C. Section appendix.c.
Synthetic traffic has been introduced to the system from time to time Synthetic traffic has been introduced to the system from time to time
in order to increase traffic loads. Approaches include the use of in order to increase traffic loads. Approaches include the use of
distributed measurement platforms such as RIPE ATLAS to send DNS distributed measurement platforms such as RIPE ATLAS to send DNS
queries to Yeti-Root servers and the capture of traffic (sent from queries to Yeti-Root servers and the capture of traffic (sent from
non-Yeti resolvers to the Root Server system) that was subsequently non-Yeti resolvers to the Root Server system) that was subsequently
modified and replayed towards Yeti-Root servers. modified and replayed towards Yeti-Root servers.
4.8. Traffic Capture and Analysis 4.8. Traffic Capture and Analysis
Traffic capture of queries and responses is available in the testbed Traffic capture of queries and responses is available in the testbed
in both Yeti resolvers and Yeti-Root servers in anticipation of in both Yeti resolvers and Yeti-Root servers in anticipation of
experiments that require packet-level visibility into DNS traffic. experiments that require packet-level visibility into DNS traffic.
Traffic capture is performed on Yeti-Root servers using either Traffic capture is performed on Yeti-Root servers using either
o dnscap <https://www.dns-oarc.net/tools/dnscap> or * dnscap https://www.dns-oarc.net/tools/dnscap or
o pcapdump, part of the pcaputils Debian package * pcapdump, part of the pcaputils Debian package
<https://packages.debian.org/sid/pcaputils>, with a patch to https://packages.debian.org/sid/pcaputils, with a patch to
facilitate triggered file upload (see <https://bugs.debian.org/ facilitate triggered file upload (see https://bugs.debian.org/cgi-
cgi-bin/bugreport.cgi?bug=545985>). bin/bugreport.cgi?bug=545985).
PCAP-format files containing packet captures are uploaded using rsync PCAP-format files containing packet captures are uploaded using rsync
to central storage. to central storage.
5. Operational Experience with the Yeti DNS Testbed 5. Operational Experience with the Yeti DNS Testbed
The following sections provide commentary on the operation and impact The following sections provide commentary on the operation and impact
analyses of the Yeti DNS testbed described in Section 4. More analyses of the Yeti DNS testbed described in Section 4. More
detailed descriptions of observed phenomena are available in the Yeti detailed descriptions of observed phenomena are available in the Yeti
DNS mailing list archives <http://lists.yeti-dns.org/pipermail/ DNS mailing list archives http://lists.yeti-dns.org/pipermail/
discuss/> and on the Yeti DNS blog <https://yeti-dns.org/blog.html>. discuss/ and on the Yeti DNS blog https://yeti-dns.org/blog.html.
5.1. Viability of IPv6-Only Operation 5.1. Viability of IPv6-Only Operation
All Yeti-Root servers were deployed with IPv6 connectivity, and no All Yeti-Root servers were deployed with IPv6 connectivity, and no
IPv4 addresses for any Yeti-Root server were made available (e.g., in IPv4 addresses for any Yeti-Root server were made available (e.g., in
the Yeti hints file or in the DNS itself). This implementation the Yeti hints file or in the DNS itself). This implementation
decision constrained the Yeti-Root system to be v6 only. decision constrained the Yeti-Root system to be v6 only.
DNS implementations are generally adept at using both IPv4 and IPv6 DNS implementations are generally adept at using both IPv4 and IPv6
when both are available. Servers that cannot be reliably reached when both are available. Servers that cannot be reliably reached
skipping to change at page 22, line 38 skipping to change at line 1010
5.3.2. KSK Rollover vs. BIND9 Views 5.3.2. KSK Rollover vs. BIND9 Views
The second Yeti KSK rollover was designed with similar phases to the The second Yeti KSK rollover was designed with similar phases to the
ICANN's KSK rollover, although with modified timings to reduce the ICANN's KSK rollover, although with modified timings to reduce the
time required to complete the process. The "slot" used in this time required to complete the process. The "slot" used in this
rollover was ten days long, as follows: rollover was ten days long, as follows:
+-----------------+----------------+----------+ +-----------------+----------------+----------+
| | Old Key: 19444 | New Key | | | Old Key: 19444 | New Key |
+-----------------+----------------+----------+ +=================+================+==========+
| slot 1 | pub+sign | | | slot 1 | pub+sign | |
+-----------------+----------------+----------+
| slot 2, 3, 4, 5 | pub+sign | pub | | slot 2, 3, 4, 5 | pub+sign | pub |
+-----------------+----------------+----------+
| slot 6, 7 | pub | pub+sign | | slot 6, 7 | pub | pub+sign |
+-----------------+----------------+----------+
| slot 8 | revoke | pub+sign | | slot 8 | revoke | pub+sign |
+-----------------+----------------+----------+
| slot 9 | | pub+sign | | slot 9 | | pub+sign |
+-----------------+----------------+----------+ +-----------------+----------------+----------+
Table 3
During this rollover exercise, a problem was observed on one Yeti During this rollover exercise, a problem was observed on one Yeti
resolver that was running BIND 9.10.4-p2 [KROLL-ISSUE]. That resolver that was running BIND 9.10.4-p2 [KROLL-ISSUE]. That
resolver was configured with multiple views serving clients in resolver was configured with multiple views serving clients in
different subnets at the time that the KSK rollover began. DNSSEC different subnets at the time that the KSK rollover began. DNSSEC
validation failures were observed following the completion of the KSK validation failures were observed following the completion of the KSK
rollover, triggered by the addition of a new view that was intended rollover, triggered by the addition of a new view that was intended
to serve clients from a new subnet. to serve clients from a new subnet.
BIND 9.10 requires "managed-keys" configuration to be specified in BIND 9.10 requires "managed-keys" configuration to be specified in
every view, a detail that was apparently not obvious to the operator every view, a detail that was apparently not obvious to the operator
skipping to change at page 23, line 32 skipping to change at line 1059
As described in Section 4.2.2, in the Yeti DNS testbed each DM can 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 maintain control of its own set of ZSKs, which can undergo rollover
independently. During a KSK rollover where concurrent ZSK rollovers independently. During a KSK rollover where concurrent ZSK rollovers
are executed by each of three DMs, the maximum number of apex DNSKEY are executed by each of three DMs, the maximum number of apex DNSKEY
RRs present is eight (incoming and outgoing KSK, plus incoming and RRs present is eight (incoming and outgoing KSK, plus incoming and
outgoing of each of three ZSKs). In practice, however, such outgoing of each of three ZSKs). In practice, however, such
concurrency did not occur; only the BII ZSK was rolled during the KSK concurrency did not occur; only the BII ZSK was rolled during the KSK
rollover, and hence only three DNSKEY RRset configurations were rollover, and hence only three DNSKEY RRset configurations were
observed: observed:
o 3 ZSKs and 2 KSKs, DNSKEY response of 1975 octets; * 3 ZSKs and 2 KSKs, DNSKEY response of 1975 octets;
o 3 ZSKs and 1 KSK, DNSKEY response of 1414 octets; and * 3 ZSKs and 1 KSK, DNSKEY response of 1414 octets; and
o 2 ZSKs and 1 KSK, DNSKEY response of 1139 octets. * 2 ZSKs and 1 KSK, DNSKEY response of 1139 octets.
RIPE Atlas probes were used as described in Section 5.1.1 to send 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 DNSKEY queries directly to Yeti-Root servers. The numbers of queries
and failures were recorded and categorized according to the response and failures were recorded and categorized according to the response
sizes at the time the queries were sent. A summary of the results sizes at the time the queries were sent. A summary of the results
([YetiLR]) is as follows: ([YetiLR]) is as follows:
+---------------+----------+---------------+--------------+ +---------------+----------+---------------+--------------+
| Response Size | Failures | Total Queries | Failure Rate | | Response Size | Failures | Total Queries | Failure Rate |
+---------------+----------+---------------+--------------+ +===============+==========+===============+==============+
| 1139 | 274 | 64252 | 0.0042 | | 1139 | 274 | 64252 | 0.0042 |
+---------------+----------+---------------+--------------+
| 1414 | 3141 | 126951 | 0.0247 | | 1414 | 3141 | 126951 | 0.0247 |
+---------------+----------+---------------+--------------+
| 1975 | 2920 | 42529 | 0.0687 | | 1975 | 2920 | 42529 | 0.0687 |
+---------------+----------+---------------+--------------+ +---------------+----------+---------------+--------------+
Table 4
The general approach illustrated briefly here provides a useful The general approach illustrated briefly here provides a useful
example of how the design of the Yeti DNS testbed, separate from the 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, Root Server system but constructed as a live testbed on the Internet,
facilitates the use of general-purpose active measurement facilities facilitates the use of general-purpose active measurement facilities
(such as RIPE Atlas probes) as well as internal passive measurement (such as RIPE Atlas probes) as well as internal passive measurement
(such as packet capture). (such as packet capture).
5.4. Capture of Large DNS Response 5.4. Capture of Large DNS Response
Packet capture is a common approach in production DNS systems where Packet capture is a common approach in production DNS systems where
skipping to change at page 24, line 27 skipping to change at line 1105
inbound query traffic is often sufficient, since responses can be inbound query traffic is often sufficient, since responses can be
synthesized with knowledge of the zones being served at the time the synthesized with knowledge of the zones being served at the time the
query was received. Queries are generally small enough not to be query was received. Queries are generally small enough not to be
fragmented, and even with TCP transport are generally packed within a fragmented, and even with TCP transport are generally packed within a
single segment. single segment.
The Yeti DNS testbed has different requirements; in particular, there The Yeti DNS testbed has different requirements; in particular, there
is a desire to compare responses obtained from the Yeti is a desire to compare responses obtained from the Yeti
infrastructure with those received from the Root Server system in infrastructure with those received from the Root Server system in
response to a single query stream (e.g., using the "Yeti Many Mirror response to a single query stream (e.g., using the "Yeti Many Mirror
Verifier" (YmmV) as described in Appendix D). Some Yeti-Root servers Verifier" (YmmV) as described in Section appendix.d). Some Yeti-Root
were capable of recovering complete DNS messages from within servers were capable of recovering complete DNS messages from within
nameservers, e.g., using dnstap; however, not all servers provided nameservers, e.g., using dnstap; however, not all servers provided
that functionality, and a consistent approach was desirable. that functionality, and a consistent approach was desirable.
The requirement to perform passive capture of responses from the wire The requirement to perform passive capture of responses from the wire
together with experiments that were expected (and in some cases together with experiments that were expected (and in some cases
designed) to trigger fragmentation and use of TCP transport led to designed) to trigger fragmentation and use of TCP transport led to
the development of a new tool, PcapParser, to perform fragment and the development of a new tool, PcapParser, to perform fragment and
TCP stream reassembly from raw packet capture data. A brief TCP stream reassembly from raw packet capture data. A brief
description of PcapParser is included in Appendix D. description of PcapParser is included in Section appendix.d.
5.5. Automated Maintenance of the Hints File 5.5. Automated Maintenance of the Hints File
Renumbering events in the Root Server system are relatively rare. Renumbering events in the Root Server system are relatively rare.
Although each such event is accompanied by the publication of an Although each such event is accompanied by the publication of an
updated hints file in standard locations, the task of updating local updated hints file in standard locations, the task of updating local
copies of that file used by DNS resolvers is manual, and the process 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 has an observably long tail. For example, in 2015 J-Root was still
receiving traffic at its old address some thirteen years after receiving traffic at its old address some thirteen years after
renumbering [Wessels2015]. renumbering [Wessels2015].
skipping to change at page 25, line 14 skipping to change at line 1141
By contrast, due to the experimental nature of the system and the By contrast, due to the experimental nature of the system and the
fact that it is operated mainly by volunteers, Yeti-Root servers are fact that it is operated mainly by volunteers, Yeti-Root servers are
added, removed, and renumbered with much greater frequency. A tool added, removed, and renumbered with much greater frequency. A tool
to facilitate automatic maintenance of hints files was therefore to facilitate automatic maintenance of hints files was therefore
created: [hintUpdate]. created: [hintUpdate].
The automated procedure followed by the hintUpdate tool is as The automated procedure followed by the hintUpdate tool is as
follows. follows.
1. Use the local resolver to obtain a response to the query 1. Use the local resolver to obtain a response to the query "./IN/
"./IN/NS". NS".
2. Use the local resolver to obtain a set of IPv4 and IPv6 addresses 2. Use the local resolver to obtain a set of IPv4 and IPv6 addresses
for each name server. for each name server.
3. Validate all signatures obtained from the local resolvers and 3. Validate all signatures obtained from the local resolvers and
confirm that all data is signed. confirm that all data is signed.
4. Compare the data obtained to that contained within the currently 4. Compare the data obtained to that contained within the currently
active hints file; if there are differences, rotate the old one active hints file; if there are differences, rotate the old one
away and replace it with a new one. away and replace it with a new one.
skipping to change at page 26, line 22 skipping to change at line 1197
derived from the root zone published by the IANA with only those derived from the root zone published by the IANA with only those
structural modifications necessary to ensure its function in the structural modifications necessary to ensure its function in the
testbed system. The Yeti DNS testbed has proven to be a useful testbed system. The Yeti DNS testbed has proven to be a useful
platform to address many questions that would be challenging to platform to address many questions that would be challenging to
answer using the production Root Server system, such as those answer using the production Root Server system, such as those
included in Section 3. included in Section 3.
Indicative findings following from the construction and operation of Indicative findings following from the construction and operation of
the Yeti DNS testbed include: the Yeti DNS testbed include:
o Operation in a pure IPv6-only environment; confirmation of a * Operation in a pure IPv6-only environment; confirmation of a
significant failure rate in the transmission of large responses significant failure rate in the transmission of large responses
(~7%), but no other persistent failures observed. Two cases in (~7%), but no other persistent failures observed. Two cases in
which Yeti-Root servers failed to retrieve the Yeti-Root zone due which Yeti-Root servers failed to retrieve the Yeti-Root zone due
to fragmentation of TCP segments; mitigated by setting a TCP MSS to fragmentation of TCP segments; mitigated by setting a TCP MSS
of 1220 octets (see Section 5.1.1). of 1220 octets (see Section 5.1.1).
o Successful operation with three autonomous Yeti-Root zone signers * Successful operation with three autonomous Yeti-Root zone signers
and 25 Yeti-Root servers, and confirmation that IXFR is not an and 25 Yeti-Root servers, and confirmation that IXFR is not an
appropriate transfer mechanism of zones that are structurally appropriate transfer mechanism of zones that are structurally
incongruent across different transfer paths (see Section 5.2). incongruent across different transfer paths (see Section 5.2).
o ZSK size increased to 2048 bits and multiple KSK rollovers * ZSK size increased to 2048 bits and multiple KSK rollovers
executed to exercise support of RFC 5011 in validating resolvers; executed to exercise support of RFC 5011 in validating resolvers;
identification of pitfalls relating to views in BIND9 when identification of pitfalls relating to views in BIND9 when
configured with "managed-keys" (see Section 5.3). configured with "managed-keys" (see Section 5.3).
o Use of natural (non-normalized) names for Yeti-Root servers * Use of natural (non-normalized) names for Yeti-Root servers
exposed some differences between implementations in the inclusion exposed some differences between implementations in the inclusion
of additional-section glue in responses to priming queries; of additional-section glue in responses to priming queries;
however, despite this inefficiency, Yeti resolvers were observed however, despite this inefficiency, Yeti resolvers were observed
to function adequately (see Section 4.5). to function adequately (see Section 4.5).
o It was observed that Knot 2.0 performed label compression on the * It was observed that Knot 2.0 performed label compression on the
root (empty) label. This resulted in an increased encoding size root (empty) label. This resulted in an increased encoding size
for references to the root label, since a pointer is encoded as for references to the root label, since a pointer is encoded as
two octets whilst the root label itself only requires one (see two octets whilst the root label itself only requires one (see
Section 5.6). Section 5.6).
o Some tools were developed in response to the operational * Some tools were developed in response to the operational
experience of running and using the Yeti DNS testbed: DNS fragment experience of running and using the Yeti DNS testbed: DNS fragment
and DNS Additional Truncated Response (ATR) for large DNS and DNS Additional Truncated Response (ATR) for large DNS
responses, a BIND9 patch for additional-section glue, YmmV, and responses, a BIND9 patch for additional-section glue, YmmV, and
IPv6 defrag for capturing and mirroring traffic. In addition, a IPv6 defrag for capturing and mirroring traffic. In addition, a
tool to facilitate automatic maintenance of hints files was tool to facilitate automatic maintenance of hints files was
created (see Appendix D). created (see Section appendix.d).
The Yeti DNS testbed was used only by end-users whose local The Yeti DNS testbed was used only by end-users whose local
infrastructure providers had made the conscious decision to do so, as infrastructure providers had made the conscious decision to do so, as
is appropriate for an experimental, non-production system. So far, is appropriate for an experimental, non-production system. So far,
no serious user complaints have reached Yeti's mailing list during no serious user complaints have reached Yeti's mailing list during
Yeti normal operation. Adding more instances into the Yeti root Yeti normal operation. Adding more instances into the Yeti root
system may help to enhance the quality of service, but it is system may help to enhance the quality of service, but it is
generally accepted that Yeti DNS performance is good enough to serve generally accepted that Yeti DNS performance is good enough to serve
the purpose of DNS Root testbed. the purpose of DNS Root testbed.
The experience gained during the operation of the Yeti DNS testbed The experience gained during the operation of the Yeti DNS testbed
suggested several topics worthy of further study: suggested several topics worthy of further study:
o Priming truncation and TCP-only Yeti-Root servers: observe and * Priming truncation and TCP-only Yeti-Root servers: observe and
measure the worst-possible case for priming truncation by measure the worst-possible case for priming truncation by
responding with TC=1 to all priming queries received over UDP responding with TC=1 to all priming queries received over UDP
transport, forcing clients to retry using TCP. This should also transport, forcing clients to retry using TCP. This should also
give some insight into the usefulness of TCP-only DNS in general. give some insight into the usefulness of TCP-only DNS in general.
o KSK ECDSA Rollover: one possible way to reduce DNSKEY response * KSK ECDSA Rollover: one possible way to reduce DNSKEY response
sizes is to change to an elliptic curve signing algorithm. While sizes is to change to an elliptic curve signing algorithm. While
in principle this can be done separately for the KSK and the ZSK, in principle this can be done separately for the KSK and the ZSK,
the RIPE NCC has done research recently and discovered that some the RIPE NCC has done research recently and discovered that some
resolvers require that both KSK and ZSK use the same algorithm. resolvers require that both KSK and ZSK use the same algorithm.
This means that an algorithm roll also involves a KSK roll. This means that an algorithm roll also involves a KSK roll.
Performing an algorithm roll at the root would be an interesting Performing an algorithm roll at the root would be an interesting
challenge. challenge.
o Sticky Notify for zone transfer: the non-applicability of IXFR as * Sticky Notify for zone transfer: the non-applicability of IXFR as
a zone transfer mechanism in the Yeti DNS testbed could be a zone transfer mechanism in the Yeti DNS testbed could be
mitigated by the implementation of a sticky preference for master mitigated by the implementation of a sticky preference for master
server for each slave. This would be so that an initial AXFR server for each slave. This would be so that an initial AXFR
response could be followed up with IXFR requests without response could be followed up with IXFR requests without
compromising zone integrity in the case (as with Yeti) that compromising zone integrity in the case (as with Yeti) that
equivalent but incongruent versions of a zone are served by equivalent but incongruent versions of a zone are served by
different masters. different masters.
o Key distribution for zone transfer credentials: the use of a * Key distribution for zone transfer credentials: the use of a
shared secret between slave and master requires key distribution shared secret between slave and master requires key distribution
and management whose scaling properties are not ideally suited to and management whose scaling properties are not ideally suited to
systems with large numbers of transfer clients. Other approaches systems with large numbers of transfer clients. Other approaches
for key distribution and authentication could be considered. for key distribution and authentication could be considered.
o DNS is a tree-based hierarchical database. Mathematically, it has * DNS is a tree-based hierarchical database. Mathematically, it has
a root node and dependency between parent and child nodes. So, a root node and dependency between parent and child nodes. So,
any failures and instability of parent nodes (Root in Yeti's case) any failures and instability of parent nodes (Root in Yeti's case)
may impact their child nodes if there is a human mistake, a may impact their child nodes if there is a human mistake, a
malicious attack, or even an earthquake. It is proposed to define malicious attack, or even an earthquake. It is proposed to define
technology and practices to allow any organization, from the technology and practices to allow any organization, from the
smallest company to nations, to be self-sufficient in their DNS. smallest company to nations, to be self-sufficient in their DNS.
o In Section 3.12 of [RFC8324], a "Centrally Controlled Root" is * In Section 3.12 of [RFC8324], a "Centrally Controlled Root" is
viewed as an issue of DNS. In future work, it would be viewed as an issue of DNS. In future work, it would be
interesting to test some technical tools like blockchain [BC] to interesting to test some technical tools like blockchain [BC] to
either remove the technical requirement for a central authority either remove the technical requirement for a central authority
over the root or enhance the security and stability of the over the root or enhance the security and stability of the
existing Root. existing Root.
7. Security Considerations 7. Security Considerations
As introduced in Section 4.4, service metadata is synchronized among As introduced in Section 4.4, service metadata is synchronized among
3 DMs using Git tool. Any security issue around Git may affect Yeti 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 DM operation. For example, a hacker may compromise one DM's Git
repository and push unwanted changes to the Yeti DM system; this may 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. introduce a bad root server or bad key for a period of time.
The Yeti resolver needs the bootstrapping files to join the testbed, The Yeti resolver needs the bootstrapping files to join the testbed,
like the hints file and trust anchor of Yeti. All required like the hints file and trust anchor of Yeti. All required
information is published on <yeti-dns.org> and <github.com>. If a information is published on yeti-dns.org and github.com. If a hacker
hacker tampers with those websites by creating a fake page, a new tampers with those websites by creating a fake page, a new resolver
resolver may lose its way and be configured with a bad root. may lose its way and be configured with a bad root.
DNSSEC is an important research goal in the Yeti DNS testbed. To DNSSEC is an important research goal in the Yeti DNS testbed. To
reduce the central function of DNSSEC for Root zone, we sign the reduce the central function of DNSSEC for Root zone, we sign the
Yeti-Root zone using multiple, independently operated DNSSEC signers Yeti-Root zone using multiple, independently operated DNSSEC signers
and multiple corresponding ZSKs (see Section 4.2). To verify ICANN's and multiple corresponding ZSKs (see Section 4.2). To verify ICANN's
KSK rollover, we rolled the Yeti KSK three times according to RFC KSK rollover, we rolled the Yeti KSK three times according to RFC
5011, and we do have some observations (see Section 5.3). In 5011, and we do have some observations (see Section 5.3). In
addition, larger RSA key sizes were used in the testbed before 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 2048-bit keys were used in the ZSK signing process of the IANA Root
zone. zone.
8. IANA Considerations 8. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P.V., "Domain names - concepts and
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034,
<https://www.rfc-editor.org/info/rfc1034>. November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P.V., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996, DOI 10.17487/RFC1995, August 1996,
<https://www.rfc-editor.org/info/rfc1995>. <https://www.rfc-editor.org/info/rfc1995>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <https://www.rfc-editor.org/info/rfc1996>. August 1996, <https://www.rfc-editor.org/info/rfc1996>.
skipping to change at page 29, line 38 skipping to change at line 1352
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
9.2. Informative References 9.2. Informative References
[ATR] Song, L., "ATR: Additional Truncation Response for Large [ATR] Song, L., "ATR: Additional Truncation Response for Large
DNS Response", Work in Progress, draft-song-atr-large- DNS Response", Work in Progress, draft-song-atr-large-
resp-02, August 2018. resp-02, 2 August 2018.
[BC] Wikipedia, "Blockchain", September 2018, [BC] Wikipedia, "Blockchain", September 2018,
<https://en.wikipedia.org/w/ <https://en.wikipedia.org/w/
index.php?title=Blockchain&oldid=861681529>. index.php?title=Blockchain&oldid=861681529>.
[FRAGDROP] Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, [FRAGDROP] Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
M., and T. Taylor, "Why Operators Filter Fragments and M., and T. Taylor, "Why Operators Filter Fragments and
What It Implies", Work in Progress, draft-taylor-v6ops- What It Implies", Work in Progress, draft-taylor-v6ops-
fragdrop-02, December 2013. fragdrop-02, 3 December 2013.
[FRAGMENTS] [FRAGMENTS]Sivaraman, M., Kerr, S., and D. Song, "DNS message
Sivaraman, M., Kerr, S., and D. Song, "DNS message
fragments", Work in Progress, draft-muks-dns-message- fragments", Work in Progress, draft-muks-dns-message-
fragments-00, July 2015. fragments-00, 20 July 2015.
[hintUpdate] [hintUpdate]
"Hintfile Auto Update", commit de428c0, October 2015, "Hintfile Auto Update", commit de428c0, October 2015,
<https://github.com/BII-Lab/Hintfile-Auto-Update>. <https://github.com/BII-Lab/Hintfile-Auto-Update>.
[HOW_ATR_WORKS] [HOW_ATR_WORKS]
Huston, G., "How well does ATR actually work?", Huston, G., "How well does ATR actually work?",
APNIC blog, April 2018, APNIC blog, 16 April 2018,
<https://blog.apnic.net/2018/04/16/ <https://blog.apnic.net/2018/04/16/how-well-does-atr-
how-well-does-atr-actually-work/>. actually-work/>.
[ICANN2010] [ICANN2010]Schlyter, J., Lamb, R., and R. Balasubramanian, "DNSSEC
Schlyter, J., Lamb, R., and R. Balasubramanian, "DNSSEC
Key Management Implementation for the Root Zone (DRAFT)", Key Management Implementation for the Root Zone (DRAFT)",
May 2010, <http://www.root-dnssec.org/wp-content/ 11 May 2010,
uploads/2010/05/draft-icann-dnssec-keymgmt-01.txt>. <http://www.root-dnssec.org/wp-content/uploads/2010/05/
draft-icann-dnssec-keymgmt-01.txt>.
[ICANN2016] [ICANN2016]Design Team, "Root Zone KSK Rollover Plan", March 2016,
Design Team, "Root Zone KSK Rollover Plan", March 2016, <https://www.iana.org/reports/2016/root-ksk-rollover-
<https://www.iana.org/reports/2016/ design-20160307.pdf>.
root-ksk-rollover-design-20160307.pdf>.
[ICANN2017] [ICANN2017]ICANN, "2017 KSK Rollover External Test Plan", 22 July
ICANN, "2017 KSK Rollover External Test Plan", July 2016, 2016,
<https://www.icann.org/en/system/files/files/ <https://www.icann.org/en/system/files/files/ksk-rollover-
ksk-rollover-external-test-plan-22jul16-en.pdf>. external-test-plan-22jul16-en.pdf>.
[IPv6-frag-DNS] [IPv6-frag-DNS]
Huston, G., "Dealing with IPv6 fragmentation in the DNS", Huston, G., "Dealing with IPv6 fragmentation in the DNS",
APNIC blog, August 2017, APNIC blog, 22 August 2017,
<https://blog.apnic.net/2017/08/22/ <https://blog.apnic.net/2017/08/22/dealing-ipv6-
dealing-ipv6-fragmentation-dns>. fragmentation-dns>.
[ISC-BIND] Risk, V., "2017 Root Key Rollover - What Does it Mean for [ISC-BIND] Risk, V., "2017 Root Key Rollover - What Does it Mean for
BIND Users?", Internet Systems Consortium, December 2016, BIND Users?", Internet Systems Consortium, December 2016,
<https://www.isc.org/blogs/2017-root-key-rollover-what- <https://www.isc.org/blogs/2017-root-key-rollover-what-
does-it-mean-for-bind-users/>. does-it-mean-for-bind-users/>.
[ISC-TN-2003-1] [ISC-TN-2003-1]
Abley, J., "Hierarchical Anycast for Global Service Abley, J., "Hierarchical Anycast for Global Service
Distribution", March 2003, Distribution", March 2003,
<http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt>. <http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt>.
[ITI2014] ICANN, "Identifier Technology Innovation Report", May [ITI2014] ICANN, "Identifier Technology Innovation Report", 15 May
2014, <https://www.icann.org/en/system/files/files/ 2014,
iti-report-15may14-en.pdf>. <https://www.icann.org/en/system/files/files/iti-report-
15may14-en.pdf>.
[KROLL-ISSUE] [KROLL-ISSUE]
Song, D., "A DNSSEC issue during Yeti KSK rollover", Yeti Song, D., "A DNSSEC issue during Yeti KSK rollover", Yeti
DNS blog, October 2016, <http://yeti-dns.org/yeti/blog/ DNS blog, October 2016,
2016/10/26/A-DNSSEC-issue-during-Yeti-KSK-rollover.html>. <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, [PINZ] Song, D., "Yeti experiment plan for PINZ", Yeti DNS blog,
May 2018, <http://yeti-dns.org/yeti/blog/2018/05/01/ May 2018,
Experiment-plan-for-PINZ.html>. <http://yeti-dns.org/yeti/blog/2018/05/01/Experiment-plan-
for-PINZ.html>.
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the [RFC2826] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May
2000, <https://www.rfc-editor.org/info/rfc2826>. 2000, <https://www.rfc-editor.org/info/rfc2826>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<https://www.rfc-editor.org/info/rfc2845>. <https://www.rfc-editor.org/info/rfc2845>.
skipping to change at page 32, line 11 skipping to change at line 1467
Resolver with Priming Queries", BCP 209, RFC 8109, Resolver with Priming Queries", BCP 209, RFC 8109,
DOI 10.17487/RFC8109, March 2017, DOI 10.17487/RFC8109, March 2017,
<https://www.rfc-editor.org/info/rfc8109>. <https://www.rfc-editor.org/info/rfc8109>.
[RFC8324] Klensin, J., "DNS Privacy, Authorization, Special Uses, [RFC8324] Klensin, J., "DNS Privacy, Authorization, Special Uses,
Encoding, Characters, Matching, and Root Structure: Time Encoding, Characters, Matching, and Root Structure: Time
for Another Look?", RFC 8324, DOI 10.17487/RFC8324, for Another Look?", RFC 8324, DOI 10.17487/RFC8324,
February 2018, <https://www.rfc-editor.org/info/rfc8324>. February 2018, <https://www.rfc-editor.org/info/rfc8324>.
[RRL] Vixie, P. and V. Schryver, "Response Rate Limiting in the [RRL] Vixie, P. and V. Schryver, "Response Rate Limiting in the
Domain Name System (DNS RRL)", June 2012, Domain Name System (DNS RRL)", 10 June 2012,
<http://www.redbarn.org/dns/ratelimits>. <http://www.redbarn.org/dns/ratelimits>.
[RSSAC001] Root Server System Advisory Committee (RSSAC), "Service [RSSAC001] Root Server System Advisory Committee (RSSAC), "Service
Expectations of Root Servers", RSSAC001 Version 1, Expectations of Root Servers", RSSAC001 Version 1, 4
December 2015, December 2015,
<https://www.icann.org/en/system/files/files/ <https://www.icann.org/en/system/files/files/rssac-001-
rssac-001-root-service-expectations-04dec15-en.pdf>. root-service-expectations-04dec15-en.pdf>.
[RSSAC023] Root Server System Advisory Committee (RSSAC), "History of [RSSAC023] Root Server System Advisory Committee (RSSAC), "History of
the Root Server System", November 2016, the Root Server System", 4 November 2016,
<https://www.icann.org/en/system/files/files/ <https://www.icann.org/en/system/files/files/rssac-
rssac-023-04nov16-en.pdf>. 023-04nov16-en.pdf>.
[SUNSET4] IETF, "Sunsetting IPv4 (sunset4) Concluded WG", [SUNSET4] IETF, "Sunsetting IPv4 (sunset4) Concluded WG", January
<https://datatracker.ietf.org/wg/sunset4/about/>. 2019, <https://datatracker.ietf.org/wg/sunset4/about/>.
[TNO2009] Gijsen, B., Jamakovic, A., and F. Roijers, "Root Scaling [TNO2009] Gijsen, B., Jamakovic, A., and F. Roijers, "Root Scaling
Study: Description of the DNS Root Scaling Model", Study: Description of the DNS Root Scaling Model",
TNO report, September 2009, TNO report, 29 September 2009,
<https://www.icann.org/en/system/files/files/ <https://www.icann.org/en/system/files/files/root-scaling-
root-scaling-model-description-29sep09-en.pdf>. model-description-29sep09-en.pdf>.
[USE_MIN_MTU] [USE_MIN_MTU]
Andrews, M., "TCP Fails To Respect IPV6_USE_MIN_MTU", Work Andrews, M., "TCP Fails To Respect IPV6_USE_MIN_MTU", Work
in Progress, draft-andrews-tcp-and-ipv6-use-minmtu-04, in Progress, draft-andrews-tcp-and-ipv6-use-minmtu-04, 18
October 2015. October 2015.
[Wessels2015] [Wessels2015]
Wessels, D., Castonguay, J., and P. Barber, "Thirteen Wessels, D., Castonguay, J., and P. Barber, "Thirteen
Years of 'Old J-Root'", DNS-OARC Fall 2015 Workshop, Years of 'Old J-Root'", DNS-OARC Fall 2015 Workshop,
October 2015, <https://indico.dns-oarc.net/event/24/ October 2015, <https://indico.dns-
session/10/contribution/10/material/slides/0.pdf>. oarc.net/event/24/session/10/contribution/10/material/
slides/0.pdf>.
[YetiLR] "Observation on Large response issue during Yeti KSK [YetiLR] "Observation on Large response issue during Yeti KSK
rollover", Yeti DNS blog, August 2017, rollover", Yeti DNS blog, 2 August 2017,
<https://yeti-dns.org/yeti/blog/2017/08/02/ <https://yeti-dns.org/yeti/blog/2017/08/02/large-packet-
large-packet-impact-during-yeti-ksk-rollover.html>. impact-during-yeti-ksk-rollover.html>.
Appendix A. Yeti-Root Hints File Appendix A. Yeti-Root Hints File
The following hints file (complete and accurate at the time of The following hints file (complete and accurate at the time of
writing) causes a DNS resolver to use the Yeti DNS testbed in place writing) causes a DNS resolver to use the Yeti DNS testbed in place
of the production Root Server system and hence participate in of the production Root Server system and hence participate in
experiments running on the testbed. experiments running on the testbed.
Note that some lines have been wrapped in the text that follows in Note that some lines have been wrapped in the text that follows in
order to fit within the production constraints of this document. order to fit within the production constraints of this document.
skipping to change at page 36, line 9 skipping to change at line 1653
;; Query time: 163 msec ;; Query time: 163 msec
;; SERVER: 2001:4b98:dc2:45:216:3eff:fe4b:8c5b#53 ;; SERVER: 2001:4b98:dc2:45:216:3eff:fe4b:8c5b#53
;; WHEN: Tue Nov 14 16:45:37 +08 2017 ;; WHEN: Tue Nov 14 16:45:37 +08 2017
;; MSG SIZE rcvd: 1222 ;; MSG SIZE rcvd: 1222
Appendix C. Active IPv6 Prefixes in Yeti DNS Testbed Appendix C. Active IPv6 Prefixes in Yeti DNS Testbed
The following table shows the prefixes that were active during 2017. The following table shows the prefixes that were active during 2017.
+----------------------+---------------------------------+----------+ +----------------------+--------------------------+----------+
| Prefix | Originator | Location | | Prefix | Originator | Location |
+----------------------+---------------------------------+----------+ +======================+==========================+==========+
| 240c::/28 | BII | CN | | 240c::/28 | BII | CN |
| 2001:6d0:6d06::/48 | MSK-IX | RU | +----------------------+--------------------------+----------+
| 2001:1488::/32 | CZ.NIC | CZ | | 2001:6d0:6d06::/48 | MSK-IX | RU |
| 2001:620::/32 | SWITCH | CH | +----------------------+--------------------------+----------+
| 2001:470::/32 | Hurricane Electric, Inc. | US | | 2001:1488::/32 | CZ.NIC | CZ |
| 2001:0DA8:0202::/48 | BUPT6-CERNET2 | CN | +----------------------+--------------------------+----------+
| 2001:19f0:6c00::/38 | Choopa, LLC | US | | 2001:620::/32 | SWITCH | CH |
| 2001:da8:205::/48 | BJTU6-CERNET2 | CN | +----------------------+--------------------------+----------+
| 2001:62a::/31 | Vienna University Computer | AT | | 2001:470::/32 | Hurricane Electric, Inc. | US |
| | Center | | +----------------------+--------------------------+----------+
| 2001:67c:217c::/48 | AFNIC | FR | | 2001:0DA8:0202::/48 | BUPT6-CERNET2 | CN |
| 2a02:2478::/32 | Profitbricks GmbH | DE | +----------------------+--------------------------+----------+
| 2001:1398:1::/48 | NIC Chile | CL | | 2001:19f0:6c00::/38 | Choopa, LLC | US |
| 2001:4490:dc4c::/46 | NIB (National Internet | IN | +----------------------+--------------------------+----------+
| | Backbone) | | | 2001:da8:205::/48 | BJTU6-CERNET2 | CN |
| 2001:4b98::/32 | Gandi | FR | +----------------------+--------------------------+----------+
| 2a02:aa8:0:2000::/52 | T-Systems-Eltec | ES | | 2001:62a::/31 | Vienna University | AT |
| 2a03:b240::/32 | Netskin GmbH | CH | | | Computer Center | |
| 2801:1a0::/42 | Universidad de Ibague | CO | +----------------------+--------------------------+----------+
| 2a00:1cc8::/40 | ICT Valle Umbra s.r.l. | IT | | 2001:67c:217c::/48 | AFNIC | FR |
| 2a02:cdc0::/29 | ORG-CdSB1-RIPE | IT | +----------------------+--------------------------+----------+
+----------------------+---------------------------------+----------+ | 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 |
+----------------------+--------------------------+----------+
Table 5
Appendix D. Tools Developed for Yeti DNS Testbed Appendix D. Tools Developed for Yeti DNS Testbed
Various tools were developed to support the Yeti DNS testbed, a Various tools were developed to support the Yeti DNS testbed, a
selection of which are described briefly below. selection of which are described briefly below.
YmmV ("Yeti Many Mirror Verifier") is designed to make it easy and YmmV ("Yeti Many Mirror Verifier") is designed to make it easy and
safe for a DNS administrator to capture traffic sent from a resolver 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. to the Root Server system and to replay it towards Yeti-Root servers.
Responses from both systems are recorded and compared, and Responses from both systems are recorded and compared, and
differences are logged. See <https://github.com/BII-Lab/ymmv>. differences are logged. See https://github.com/BII-Lab/ymmv.
PcapParser is a module used by YmmV which reassembles fragmented IPv6 PcapParser is a module used by YmmV which reassembles fragmented IPv6
datagrams and TCP segments from a PCAP archive and extracts DNS datagrams and TCP segments from a PCAP archive and extracts DNS
messages contained within them. See <https://github.com/RunxiaWan/ messages contained within them. See https://github.com/RunxiaWan/
PcapParser>. PcapParser.
DNS-layer-fragmentation implements DNS proxies that perform DNS-layer-fragmentation implements DNS proxies that perform
application-level fragmentation of DNS messages, based on application-level fragmentation of DNS messages, based on
[FRAGMENTS]. The idea with these proxies is to explore splitting DNS [FRAGMENTS]. The idea with these proxies is to explore splitting DNS
messages in the protocol itself, so they will not by fragmented by messages in the protocol itself, so they will not by fragmented by
the IP layer. See <https://github.com/BII-Lab/DNS-layer- the IP layer. See https://github.com/BII-Lab/DNS-layer-
Fragmentation>. Fragmentation.
DNS_ATR is an implementation of DNS Additional Truncated Response DNS_ATR is an implementation of DNS Additional Truncated Response
(ATR), as described in [ATR] and [HOW_ATR_WORKS]. DNS_ATR acts as a (ATR), as described in [ATR] and [HOW_ATR_WORKS]. DNS_ATR acts as a
proxy between resolver and authoritative servers, forwarding queries proxy between resolver and authoritative servers, forwarding queries
and responses as a silent and transparent listener. Responses that and responses as a silent and transparent listener. Responses that
are larger than a nominated threshold (1280 octets by default) are larger than a nominated threshold (1280 octets by default)
trigger additional truncated responses to be sent immediately trigger additional truncated responses to be sent immediately
following the large response. See <https://github.com/songlinjian/ following the large response. See https://github.com/songlinjian/
DNS_ATR>. DNS_ATR.
Appendix E. Controversy Appendix E. Controversy
The Yeti DNS Project, its infrastructure and the various experiments The Yeti DNS Project, its infrastructure and the various experiments
that have been carried out using that infrastructure, have been that have been carried out using that infrastructure, have been
described by people involved in the project in many public meetings described by people involved in the project in many public meetings
at technical venues since its inception. The mailing lists using at technical venues since its inception. The mailing lists using
which the operation of the infrastructure has been coordinated are which the operation of the infrastructure has been coordinated are
open to join, and their archives are public. The project as a whole open to join, and their archives are public. The project as a whole
has been the subject of robust public discussion. has been the subject of robust public discussion.
skipping to change at page 39, line 7 skipping to change at line 1798
Chonm. Chonm.
The authors also acknowledge the assistance of the Independent The authors also acknowledge the assistance of the Independent
Submissions Editorial Board, and of the following reviewers whose Submissions Editorial Board, and of the following reviewers whose
opinions helped improve the clarity of this document: opinions helped improve the clarity of this document:
Joe Abley, Paul Mockapetris, and Subramanian Moonesamy. Joe Abley, Paul Mockapetris, and Subramanian Moonesamy.
Authors' Addresses Authors' Addresses
Linjian Song (editor)
Beijing Internet Institute
2nd Floor, Building 5, No.58 Jing Hai Wu Lu, BDA
Beijing 100176
China China
100176
Beijing
2nd Floor, Building 5, No.58 Jing Hai Wu Lu, BDA
Beijing Internet Institute
Linjian Song (editor)
Email: songlinjian@gmail.com Email: songlinjian@gmail.com
URI: http://www.biigroup.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 China
100176
Beijing
2nd Floor, Building 5, No.58 Jing Hai Wu Lu, BDA
Beijing Internet Institute
Dong Liu
Email: dliu@biigroup.com Email: dliu@biigroup.com
URI: http://www.biigroup.com/ URI: http://www.biigroup.com/
Paul Vixie Paul Vixie
TISF TISF
11400 La Honda Road 11400 La Honda Road
Woodside, California 94062 Woodside, California 94062
United States of America United States of America
Email: vixie@tisf.net Email: vixie@tisf.net
URI: http://www.redbarn.org/ 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 Japan
〒223-8526
Graduate School of Media Design, 4-1-1 Hiyoshi, Kohoku
Keio University/WIDE Project
Akira Kato
Email: kato@wide.ad.jp Email: kato@wide.ad.jp
URI: http://www.kmd.keio.ac.jp/ URI: http://www.kmd.keio.ac.jp/
Shane Kerr Shane Kerr
Antoon Coolenlaan 41 Antoon Coolenlaan 41
Uithoorn 1422 GN Uithoorn
The Netherlands
Email: shane@time-travellers.org Email: shane@time-travellers.org
 End of changes. 128 change blocks. 
255 lines changed or deleted 329 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/