Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8483

Informational
Pages: 39
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: ~dns

Yeti DNS Testbed

Part 1 of 3, p. 1 to 17
None       Next Section

 


Top       ToC       Page 1 
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

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).

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the RFC Series, independently of any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not candidates for any level of Internet Standard;
   see Section 2 of RFC 7841.

   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.

Top      ToC       Page 2 
Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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.

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

Top      ToC       Page 3 
     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

1.  Introduction

   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.

   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/>).

   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.

   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

Top      ToC       Page 4 
   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.

   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.

   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.

   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.

   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.

Top      ToC       Page 5 
2.  Requirements Notation and Conventions

   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.

3.  Areas of Study

   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.

   Each example included below is illustrated with indicative questions.

3.1.  Implementation of a Testbed like the Root Server System

   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  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?

3.2.  Yeti-Root Zone Distribution

   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?

3.3.  Yeti-Root Server Names and Addressing

   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  What are the risks and benefits of signing the zone that contains
      the names of the Yeti-Root servers?

Top      ToC       Page 6 
   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?

3.4.  IPv6-Only Yeti-Root Servers

   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  What effect does the IPv6 fragmentation model have on the
      operation of Yeti-Root servers, compared with that of IPv4?

3.5.  DNSSEC in the Yeti-Root Zone

   o  Is it practical to sign the Yeti-Root zone using multiple,
      independently operated DNSSEC signers and multiple corresponding
      Zone Signing Keys (ZSKs)?

   o  To what extent is [RFC5011] ("Automated Updates of DNS Security
      (DNSSEC) Trust Anchors") supported by resolvers?

   o  Does the KSK Rollover plan designed and in the process of being
      implemented by ICANN work as expected on the Yeti testbed?

   o  What is the operational impact of using much larger RSA key sizes
      in the ZSKs used in a root?

   o  What are the operational consequences of choosing DNSSEC
      algorithms other than RSA to sign a root?

Top      ToC       Page 7 
4.  Yeti DNS Testbed Infrastructure

   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.

       ,----------.        ,-----------.        ,------------.
       |   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

   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.

   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.

   Stub resolvers become part of the Yeti DNS testbed by their use of
   recursive resolvers that are configured as described above.

   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.

Top      ToC       Page 8 
                              ,----------------.
                         ,-- / 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

                        Figure 2: Testbed Data Flow

   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.

4.1.  Root Zone Retrieval

   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.

Top      ToC       Page 9 
   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.

   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:

                  +-------------+-----------------------+
                  | 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].

4.2.  Transformation of Root Zone to Yeti-Root Zone

   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.

   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.

Top      ToC       Page 10 
4.2.1.  ZSK and KSK Key Sets Shared between DMs

   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.

   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).

   1.  SOA.MNAME is set to 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".

   3.  All DNSKEY, RRSIG, and NSEC records are removed.

   4.  The apex Name Server (NS) RRset is removed, with the
       corresponding root server glue (A and AAAA) RRsets.

   5.  A Yeti DNSKEY RRset is added to the apex, comprising the public
       parts of all Yeti KSK and ZSKs.

   6.  A Yeti NS RRset is added to the apex that includes all Yeti-Root
       servers.

   7.  Glue records (AAAA only, since Yeti-Root servers are v6-only) for
       all Yeti-Root servers are added.

   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.

   Note that the SOA.SERIAL value published in the Yeti-Root zone is
   identical to that found in the root zone.

4.2.2.  Unique ZSK per DM; No Shared KSK

   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

Top      ToC       Page 11 
   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.

                            ,----------.         ,-----------.
                   .--------> 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

   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].

   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.

   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.

4.2.3.  Preserving Root Zone NSEC Chain and ZSK RRSIGs

   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.

Top      ToC       Page 12 
   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.

4.3.  Yeti-Root Zone Distribution

   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.

   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.

4.4.  Synchronization of Service Metadata

   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.

   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.

Top      ToC       Page 13 
   The three Git repositories are synchronized by configuring them as
   remote servers.  For example, at BII we push to all three DMs'
   repositories as follows:

             $ git 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>.

4.5.  Yeti-Root Server Naming Scheme

   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].

   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.

   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).

   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.

Top      ToC       Page 14 
   o  Modify nameserver software or configuration as used by Yeti-Root
      servers.

   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.

   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.

   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.

4.6.  Yeti-Root Servers

   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).

Top      ToC       Page 15 
   +-------------------------------------+---------------+-------------+
   | 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].

Top      ToC       Page 16 
   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.

   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  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  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).

4.7.  Experimental Traffic

   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.

   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.

   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.

4.8.  Traffic Capture and Analysis

   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.

Top      ToC       Page 17 
   Traffic capture is performed on Yeti-Root servers using either

   o  dnscap <https://www.dns-oarc.net/tools/dnscap> or

   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>).

   PCAP-format files containing packet captures are uploaded using rsync
   to central storage.



(page 17 continued on part 2)

Next Section