DNSOP Working Group                                         G.C.M.

Independent Submission                                          G. Moura
Internet-Draft
Request for Comments: 9199                            SIDN Labs/TU Delft
Intended status:
Category: Informational                                      W. Hardaker
Expires: 8 July 2022
ISSN: 2070-1721                                             J. Heidemann
                                      USC/Information Sciences Institute
                                                               M. Davids
                                                               SIDN Labs
                                                          4 January
                                                              March 2022

      Considerations for Large Authoritative DNS Servers Server Operators
           draft-moura-dnsop-authoritative-recommendations-11

Abstract

   Recent research work has explored the deployment characteristics and
   configuration of the Domain Name System (DNS).  This document
   summarizes the conclusions from these research efforts and offers
   specific, tangible considerations or advice to authoritative DNS
   server operators.  Authoritative server operators may wish to follow
   these considerations to improve their DNS services.

   It is possible that the results presented in this document could be
   applicable in a wider context than just the DNS protocol, as some of
   the results may generically apply to any stateless/short-duration, stateless/short-duration
   anycasted service.

   This document is not an IETF consensus document: it is published for
   informational purposes.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the
   provisions RFC Series, independently of BCP 78 any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and BCP 79.

   Internet-Drafts makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are working documents not candidates for any level of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list Standard;
   see Section 2 of RFC 7841.

   Information about the current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 8 July 2022.
   https://www.rfc-editor.org/info/rfc9199.

Copyright Notice

   Copyright (c) 2022 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)
   (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.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Considerations  . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  C1: Deploy anycast Anycast in every authoritative server Every Authoritative Server to enhance
           distribution Enhance
           Distribution and latency  . . . . . . . . . . . . . . . .   5 Latency
       3.1.1.  Research background . . . . . . . . . . . . . . . . .   5 Background
       3.1.2.  Resulting considerations  . . . . . . . . . . . . . .   6 Considerations
     3.2.  C2: Optimizing routing Routing is more important More Important than location
           count Location
           Count and diversity . . . . . . . . . . . . . . . . . . .   7 Diversity
       3.2.1.  Research background . . . . . . . . . . . . . . . . .   7 Background
       3.2.2.  Resulting considerations  . . . . . . . . . . . . . .   8 Considerations
     3.3.  C3: Collecting anycast catchment maps Collect Anycast Catchment Maps to improve
           design  . . . . . . . . . . . . . . . . . . . . . . . . .   8 Improve Design
       3.3.1.  Research background . . . . . . . . . . . . . . . . .   8 Background
       3.3.2.  Resulting considerations  . . . . . . . . . . . . . .   9 Considerations
     3.4.  C4: Employ Two Strategies When under stress, employ two strategies  . . . . . .   9 Stress
       3.4.1.  Research background . . . . . . . . . . . . . . . . .  10 Background
       3.4.2.  Resulting considerations  . . . . . . . . . . . . . .  11 Considerations
     3.5.  C5: Consider longer time-to-live values whenever
           possible  . . . . . . . . . . . . . . . . . . . . . . . .  11 Longer Time-to-Live Values Whenever Possible
       3.5.1.  Research background . . . . . . . . . . . . . . . . .  11 Background
       3.5.2.  Resulting considerations  . . . . . . . . . . . . . .  13 Considerations
     3.6.  C6: Consider the TTL differences between parents Difference in Parent and
           children  . . . . . . . . . . . . . . . . . . . . . . . .  14 Children's TTL
           Values
       3.6.1.  Research background . . . . . . . . . . . . . . . . .  14 Background
       3.6.2.  Resulting considerations  . . . . . . . . . . . . . .  15 Considerations
   4.  Security considerations . . . . . . . . . . . . . . . . . . .  15 Considerations
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  15
   6.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  15
   8. Considerations
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     8.1.
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     8.2.
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  17
     7.
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   Contributors
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   This document summarizes recent research work that explored the deployed
   DNS configurations and offers derived, specific specific, tangible advice to
   DNS authoritative server operators (DNS operators (referred to as "DNS operators"
   hereafter).  The considerations (C1--C5) (C1-C6) presented in this document
   are backed by peer-reviewed research works, research, which used wide-scale Internet
   measurements to draw their conclusions.  This document summarizes the
   research results and describes the resulting key engineering options.
   In each section, it points readers are pointed to the pertinent publications
   where additional details are presented.

   These considerations are designed for operators of "large"
   authoritative DNS servers.  In servers, which, in this context, "large" authoritative are servers refers to those with a
   significant global user population, like top-level domain (TLD)
   operators, run by either a single operator or multiple operators.  Typically
   Typically, these networks are deployed on wide anycast networks [RFC1546][AnyBest].
   [RFC1546] [AnyBest].  These considerations may not be appropriate for
   smaller domains, such as those used by an organization with users in
   one unicast network, network or in one a single city or region, where operational
   goals such as uniform, global low latency are less required.

   It is possible that the results presented in this document could be
   applicable in a wider context than just the DNS protocol, as some of
   the results may generically apply to any stateless/short-duration, stateless/short-duration
   anycasted service.  Because the conclusions of the reviewed studies
   don't measure smaller networks, the wording in this document
   concentrates solely on disusing discussing large-scale DNS authoritative
   services only.
   services.

   This document is not an IETF consensus document: it is published for
   informational purposes.

2.  Background

   The DNS has main two main types of DNS servers: authoritative servers and
   recursive resolvers, shown by a representational deployment model in
   Figure 1.  An authoritative server (shown as AT1--AT4 AT1-AT4 in Figure 1)
   knows the content of a DNS zone, zone and is responsible for answering
   queries about that zone.  It runs using local (possibly automatically
   updated) copies of the zone and does not need to query other servers
   [RFC2181] in order to answer requests.  A recursive resolver (Re1--
   Re3)
   (Re1-Re3) is a server that iteratively queries authoritative and
   other servers to answer queries received from client requests
   [RFC1034].  A client typically employs a software library called a stub resolver
   (stub
   "stub resolver" ("stub" in Figure 1) to issue its query to the
   upstream recursive resolvers [RFC1034].

           +-----+  +-----+  +-----+  +-----+
           | AT1 |  | AT2 |  | AT3 |  | AT4 |
           +-----+  +-----+  +-----+  +-----+
             ^         ^        ^        ^
             |         |        |        |
             |      +-----+     |        |
             +------| Re1 |----+|        |
             |      +-----+              |
             |         ^                 |
             |         |                 |
             |      +----+   +----+      |
             +------|Re2 |   |Re3 |------+
                    +----+   +----+
                      ^          ^
                      |          |
                      | +------+ |
                      +-| stub |-+
                        +------+

        Figure 1: Relationship between recursive resolvers Recursive Resolvers (Re) and
                      authoritative name servers
                      Authoritative Name Servers (ATn)

   DNS queries issued by a client contribute to a user's perceived
   perceived
   latency and affect the user experience [Singla2014] depending on how
   long it takes for responses to be returned.  The DNS system has been
   subject to repeated Denial of Service Denial-of-Service (DoS) attacks (for example, in
   November 2015 [Moura16b]) in order to specifically degrade the user
   experience.

   To reduce latency and improve resiliency against DoS attacks, the DNS
   uses several types of service replication.  Replication at the
   authoritative server level can be achieved with (i) the following:

   i.    the deployment of multiple servers for the same zone [RFC1035] (AT1---AT4
         (AT1-AT4 in Figure 1),
   (ii) 1);

   ii.   the use of IP anycast [RFC1546][RFC4786][RFC7094] [RFC1546] [RFC4786] [RFC7094] that allows
         the same IP address to be announced from multiple locations
         (each of referred to as an "anycast instance" [RFC8499]) [RFC8499]); and (iii)

   iii.  the use of load balancers to support multiple servers inside a
         single (potentially anycasted) instance.  As a consequence,
         there are many possible ways an authoritative DNS provider can
         engineer its production authoritative server network, network with
         multiple viable choices choices, and no there is not necessarily a single
         optimal design.

3.  Considerations

   In the next sections sections, we cover the specific consideration (C1--C6) considerations (C1-C6)
   for conclusions drawn within the academic papers about large
   authoritative DNS server operators.  These considerations are
   conclusions reached from academic works work that authoritative server
   operators may wish to consider in order to improve their DNS service.
   Each consideration offers different improvements that may impact
   service latency, routing, anycast deployment, and defensive
   strategies
   strategies, for example.

3.1.  C1: Deploy anycast Anycast in every authoritative server Every Authoritative Server to enhance
      distribution Enhance
      Distribution and latency Latency

3.1.1.  Research background Background

   Authoritative DNS server operators announce their service using NS
   records[RFC1034].
   records [RFC1034].  Different authoritative servers for a given zone
   should return the same content; typically typically, they stay synchronized
   using DNS zone transfers (AXFR[RFC5936] (authoritative transfer (AXFR) [RFC5936] and IXFR[RFC1995]),
   incremental zone transfer (IXFR) [RFC1995]), coordinating the zone
   data they all return to their clients.

   As discussed above, the DNS heavily relies upon replication to
   support high reliability, ensure capacity capacity, and to reduce latency
   [Moura16b].  The DNS has two complementary mechanisms for service
   replication: nameserver name server replication (multiple NS records) and
   anycast (multiple physical locations).  Nameserver  Name server replication is
   strongly recommended for all zones (multiple NS records), and IP
   anycast is used by many larger zones such as the DNS Root[AnyFRoot], root [AnyFRoot],
   most top-
   level domains[Moura16b] top-level domains [Moura16b], and many large commercial
   enterprises,
   governments governments, and other organizations.

   Most DNS operators strive to reduce service latency for users, which
   is greatly affected by both of these replication techniques.
   However, because operators only have control over their authoritative
   servers,
   servers and not over the client's recursive resolvers, it is
   difficult to ensure that recursives will be served by the closest
   authoritative server.  Server selection is ultimately up to the
   recursive resolver's software implementation, and different vendors
   and even different releases employ different criteria to chose choose the
   authoritative servers with which to communicate.

   Understanding how recursive resolvers choose authoritative servers is
   a key step in improving the effectiveness of authoritative server
   deployments.  To measure and evaluate server deployments,
   [Mueller17b] deployed describes the deployment of seven unicast authoritative
   name servers in different global locations and then queried them from
   more than 9000
   RIPE Reseaux IP Europeens (RIPE) authoritative server
   operators and their respective recursive resolvers.

   [Mueller17b]

   It was found in [Mueller17b] that recursive resolvers in the wild
   query all available authoritative servers, regardless of the observed
   latency.  But the distribution of queries tends to be skewed towards
   authoritatives with lower latency: the lower the latency between a
   recursive resolver and an authoritative server, the more often the
   recursive will send queries to that server.  These results were
   obtained by aggregating results from all of the vantage points points, and
   they were not specific to any specific vendor or version.

   The authors believe this behavior is a consequence of combining the
   two main criteria employed by resolvers when selecting authoritative
   servers: resolvers regularly check all listed authoritative servers
   in an NS set to determine which is closer (the least latent) latent), and
   when one isn't available available, it selects one of the alternatives.

3.1.2.  Resulting considerations Considerations

   For an authoritative DNS operator, this result means that the latency
   of all authoritative servers (NS records) matter, so they all must be
   similarly capable -- all available authoritatives will be queried by
   most recursive resolvers.  Unicasted services, unfortunately, cannot
   deliver good latency worldwide (a unicast authoritative server in
   Europe will always have high latency to resolvers in California and
   Australia, for example, given its geographical distance).

   [Mueller17b] recommends that DNS operators deploy equally strong IP
   anycast instances for every authoritative server (i.e., for each NS
   record).  Each large authoritative DNS server provider should phase
   out their its usage of unicast and deploy a well engineered number of well-engineered
   anycast instances with good peering strategies so they can provide
   good latency to their global clients.

   As a case study, the ".nl" TLD zone was originally served on seven
   authoritative servers with a mixed unicast/anycast setup.  In early
   2018, .nl moved to a setup with 4 anycast authoritative servers.

   [Mueller17b]'s

   The contribution of [Mueller17b] to DNS service engineering shows
   that because unicast cannot deliver good latency worldwide, anycast
   needs to be used to provide a low latency low-latency service worldwide.

3.2.  C2: Optimizing routing Routing is more important More Important than location count Location Count and
      diversity
      Diversity

3.2.1.  Research background Background

   When selecting an anycast DNS provider or setting up an anycast
   service, choosing the best number of anycast
   instances[RFC4786][RFC7094] instances [RFC4786]
   [RFC7094] to deploy is a challenging problem.  Selecting where the right
   quantity and how many set of global locations to announce from using that should send BGP
   announcements is tricky.  Intuitively, one could naively think that the
   more instances the are better and that simply "more" will always lead to
   shorter response times.

   This is not necessarily true, however.  In fact, [Schmidt17a] found
   that proper route
   engineering can matter more than the total number of locations.  They analyzed locations, as
   found in [Schmidt17a].  To study the relationship between the number
   of anycast instances and the associated service performance (measuring latency of performance, the
   authors measured the round-trip time (RTT)), measuring the overall performance (RTT) latency of four DNS
   Root root
   servers.  The Root root DNS servers are implemented by 12 separate
   organizations serving the DNS root zone at 13 different IPv4/IPv6
   address pairs.

   The results documented in [Schmidt17a] measured the performance of
   the {c,f,k,l}.root-servers.net (hereafter, (referred to as "C", "F", "K" "K", and "L") "L"
   hereafter) servers from more than 7.9k 7,900 RIPE Atlas probes.  RIPE
   Atlas is a an Internet measurement platform with more than 12000 12,000
   global vantage points called "Atlas Probes" -- probes", and it is used regularly
   by both researchers and operators [RipeAtlas15a] [RipeAtlas19a].

   [Schmidt17a]

   In [Schmidt17a], the authors found that the C server, a smaller
   anycast deployment consisting of only 8 instances, provided very
   similar overall performance in comparison to the much larger
   deployments of K and L, with 33 and 144 instances instances, respectively.  The
   median RTT RTTs for the C, K K, and L root server servers were all between 30-32ms. 30-32
   ms.

   Because RIPE Atlas is known to have better coverage in Europe than
   other regions, the authors specifically analyzed the results per
   region and per country (Figure 5 in [Schmidt17a]), [Schmidt17a]) and show that known
   Atlas bias toward Europe does not change the conclusion that properly
   selected anycast locations is are more important to latency than the
   number of sites.

3.2.2.  Resulting considerations Considerations

   The important conclusion of from [Schmidt17a] is that when engineering
   anycast services for performance, factors other than just the number
   of instances (such as local routing connectivity) must be considered.
   Specifically, optimizing routing policies is more important than
   simply adding new instances.  They  The authors showed that 12 instances
   can provide reasonable latency, assuming they are globally
   distributed and have good local interconnectivity.  However,
   additional instances can still be useful for other reasons, such as
   when handling Denial-
   of-service (DoS) DoS attacks [Moura16b].

3.3.  C3: Collecting anycast catchment maps Collect Anycast Catchment Maps to improve design Improve Design

3.3.1.  Research background Background

   An anycast DNS service may be deployed from anywhere and from several
   locations to hundreds of locations (for example, l.root-servers.net
   has over 150 anycast instances at the time this was written).
   Anycast leverages Internet routing to distribute incoming queries to
   a service's hop-nearest nearest distributed anycast locations. locations measured by the
   number of routing hops.  However,
   usually queries are usually not evenly
   distributed across all anycast locations, as found in the case of
   L-Root [IcannHedge18]. when analyzed using Hedgehog [IcannHedgehog].

   Adding locations to or removing locations from a deployed anycast
   network changes the load distribution across all of its locations.
   When a new location is announced by BGP, locations may receive more
   or less traffic than it was engineered for, leading to suboptimal
   service performance or even stressing some locations while leaving
   others underutilized.  Operators constantly face this scenario that when
   expanding an anycast service.  Operators cannot easily directly
   estimate future query distributions based on proposed anycast network
   engineering decisions.

   To address this need and estimate the query loads based on changing,
   in particular expanding, of an anycast
   service undergoing changes (in particular expanding), [Vries17b] developed
   describes the development of a new technique enabling operators to
   carry out active measurements, measurements using an open-source tool called
   Verfploeter (available at [VerfSrc]).  The results allow the creation
   of detailed anycast maps and catchment estimates.  By running verfploeter
   Verfploeter combined with a published IPv4 "hit list", the DNS can
   precisely calculate which remote prefixes will be matched to each
   anycast instance in a network.  At the moment time of this writing,
   Verfploeter still does not support IPv6 as the IPv4 hit lists used
   are generated via frequent large scale large-scale ICMP echo scans, which is not
   possible using IPv6.

   As proof of concept, [Vries17b] documents how it verfploeter Verfploeter was used to
   predict both the catchment and query load distribution for a new
   anycast instance deployed for b.root-servers.net.  Using two anycast
   test instances in Miami (MIA) and Los Angeles (LAX), an ICMP echo
   query was sent from an IP anycast addresses address to each IPv4 /24 network
   routing block on the Internet.

   The ICMP echo responses were recorded at both sites and analyzed and
   overlayed
   overlaid onto a graphical world map, resulting in an Internet scale Internet-scale
   catchment map.  To calculate expected load once the production
   network was enabled, the quantity of traffic received by b.root-
   servers.net's single site at LAX was recorded based on a single day's
   traffic (2017-04-12, DITL "day in the life" (DITL) datasets [Ditl17]).  [Vries17b]  In
   [Vries17b], it was predicted that 81.6% of the traffic load would
   remain at the LAX site.  This Verfploeter estimate by verfploeter turned out to be
   very accurate; the actual measured traffic volume when production
   service at MIA was enabled was 81.4%.

   Verfploeter can also be used to estimate traffic shifts based on
   other BGP route engineering techniques (for example, AS Autonomous
   System (AS) path prepending or BGP community use) in advance of
   operational deployment.  [Vries17b]  This was studied this in [Vries17b] using
   prepending with 1-3 hops at each instance instance, and compared the results were
   compared against real operational changes to validate the techniques accuracy. accuracy of
   the techniques.

3.3.2.  Resulting considerations Considerations

   An important operational takeaway [Vries17b] provides is how DNS
   operators can make informed engineering choices when changing DNS
   anycast network deployments by using Verfploeter in advance.
   Operators can identify sub-optimal suboptimal routing situations in advance with
   significantly better coverage rather than using other active
   measurement platforms such as RIPE Atlas.  To date, Verfploeter has
   been deployed on a an operational testbed (Anycast (anycast testbed) [AnyTest], [AnyTest]
   on a large unnamed operator and is run daily at b.root-servers.net[Vries17b]. b.root-servers.net
   [Vries17b].

   Operators should use active measurement techniques like Verfploeter
   in advance of potential anycast network changes to accurately measure
   the benefits and potential issues ahead of time.

3.4.  C4: Employ Two Strategies When under stress, employ two strategies Stress

3.4.1.  Research background Background

   DDoS attacks are becoming bigger, cheaper, and more frequent
   [Moura16b].  The most powerful recorded DDoS attack against DNS
   servers to date reached 1.2 Tbps by using IoT Internet of Things (IoT)
   devices [Perlroth16].  How should a DNS operator engineer its anycast
   authoritative DNS server to react to such a DDoS attack?  [Moura16b]
   investigates this question using empirical observations grounded with
   theoretical option evaluations.

   An authoritative DNS server deployed using anycast will have many
   server instances distributed over many networks.  Ultimately, the
   relationship between the DNS provider's network and a client's ISP
   will determine which anycast instance will answer queries for a given
   client, given that BGP is the BGP protocol that maps clients to specific anycast
   instances by using routing information [RF:KDar02]. information.  As a consequence, when an
   anycast authoritative server is under attack, the load that each
   anycast instance receives is likely to be unevenly distributed (a
   function of the source of the attacks), thus attacks); thus, some instances may be
   more overloaded than others others, which is what was observed when
   analyzing the Root root DNS events of Nov. November 2015 [Moura16b].  Given the
   fact that different instances may have different capacity capacities
   (bandwidth, CPU, etc.), making a decision about how to react to
   stress becomes even more difficult.

   In practice, when an anycast instance is overloaded with incoming
   traffic, operators have two options:

   *  They can withdraw its routes, pre-prepend its AS route to some or
      all of its neighbors, perform other traffic shifting traffic-shifting tricks (such
      as reducing route announcement propagation using BGP
      communities[RFC1997]), communities
      [RFC1997]), or by communicating communicate with its upstream network providers to
      apply filtering (potentially using FlowSpec [RFC8955] or DOTS the DDoS
      Open Threat Signaling (DOTS) protocol ([RFC8811], [RFC8782], [RFC8811] [RFC9132]
      [RFC8783]).  These techniques shift both legitimate and attack
      traffic to other anycast instances (with hopefully greater
      capacity) or to block traffic entirely.

   *  Alternatively, operators can be become a degraded absorber absorbers by
      continuing to operate, knowing dropping incoming legitimate
      requests due to queue overflow.  However, this approach will also
      absorb attack traffic directed toward its catchment, hopefully
      protecting the other anycast instances.

   [Moura16b] saw describes seeing both of these behaviors deployed in
   practice by when studying instance reachability and route-trip time (RTTs) RTTs in the DNS root
   events.  When withdraw strategies were deployed, the stress of
   increased query loads were displaced from one instance to multiple
   other sites.  In other observed events, one site was left to absorb
   the brunt of an attack attack, leaving the other sites to remain relatively
   less affected.

3.4.2.  Resulting considerations Considerations

   Operators should consider having both a an anycast site withdraw
   strategy and a an absorption strategy ready to be used before a network
   overload occurs.  Operators should be able to deploy one or both of
   these strategies rapidly.  Ideally, these should be encoded into
   operating playbooks with defined site measurement guidelines for
   which strategy to employ based on measured data from past events.

   [Moura16b] speculates that careful, explicit, and automated
   management policies may provide stronger defenses to overload events.
   DNS operators should be ready to employ both traditional common filtering
   approaches and other routing load balancing load-balancing techniques
   (withdraw/prepend/communities (such as
   withdrawing routes, prepending Autonomous Systems (ASes), adding
   communities, or isolate isolating instances), where the best choice depends
   on the specifics of the attack.

   Note that this consideration refers to the operation of just one
   anycast service point, i.e., just one anycasted IP address block
   covering one NS record.  However, DNS zones with multiple
   authoritative anycast servers may also expect loads to shift from one
   anycasted server to another, as resolvers switch from on one
   authoritative service point to another when attempting to resolve a
   name [Mueller17b].

3.5.  C5: Consider longer time-to-live values whenever possible Longer Time-to-Live Values Whenever Possible

3.5.1.  Research background Background

   Caching is the cornerstone of good DNS performance and reliability.
   A 50 ms response to a new DNS query may be considered fast, but a
   response of less than 1 ms response to a cached entry is far faster.  [Moura18b]
   showed  In
   [Moura18b], it was shown that caching also protects users from short
   outages and even significant DDoS attacks.

   Time-to-live (TTL) values [RFC1034] [RFC1035] for DNS record TTLs (time-to-live values) [RFC1034][RFC1035] records
   directly control cache durations and affect latency, resilience, and
   the role of DNS in CDN Content Delivery Network (CDN) server selection.
   Some early work modeled caches as a function of their TTLs [Jung03a],
   and recent work has examined their
   interaction cache interactions with DNS[Moura18b], DNS [Moura18b],
   but until [Moura19b] [Moura19b], no research had provided considerations about
   the benefits of various TTL value choices.  To study this, Moura et. et
   al. [Moura19b] carried out a measurement study investigating TTL
   choices and their impact on user experiences in the wild.  They
   performed this study independent of specific resolvers (and their
   caching architectures), vendors, or setups.

   First, they identified several reasons why operators and zone-owners zone owners
   may want to choose longer or shorter TTLs:

   *  As  Longer TTLs, as discussed, longer TTLs lead to a longer cache life, resulting
      in faster responses.  [Moura19b]  In [Moura19b], this was measured this in the wild
      wild, and it showed that by increasing the TTL for the .uy TLD
      from 5 minutes
      (300s) (300 s) to 1 day (86400s) (86,400 s), the latency measured
      from 15k 15,000 Atlas vantage points changed significantly: the median
      RTT decreased from 28.7ms 28.7 ms to 8ms, 8 ms, and the 75%ile 75th percentile
      decreased from 183ms 183 ms to 21ms. 21 ms.

   *  Longer caching times also results result in lower DNS traffic:
      authoritative servers will experience less traffic with extended
      TTLs, as repeated queries are answered by resolver caches.

   *  Consequently, longer  Longer caching consequently results in a lower overall cost if the
      DNS is metered: some DNS-As-A-Service providers that offer DNS as a Service charge
      a per query per-query (metered) cost (often in addition to a fixed monthly
      cost).

   *  Longer caching is more robust to DDoS attacks on DNS
      infrastructure.  [Moura18b]  DNS caching was also measured in [Moura18b], and show
      it showed that DNS
      caching can greatly reduce the effects of a DDoS on DNS, DNS can be greatly
      reduced, provided that the caches last longer than the attack.

   *  However, shorter caching  Shorter caching, however, supports deployments that may require
      rapid operational changes: An an easy way to transition from an old
      server to a new one is to simply change the DNS records.  Since
      there is no method to remotely remove cached DNS records, the TTL
      duration represents a necessary transition delay to fully shift
      from one server to another.  Thus, low TTLs allow for more rapid
      transitions.  However, when deployments are planned in advance
      (that is, longer than the TTL), it is possible to lower the TTLs
      just-before
      just before a major operational change and raise them again
      afterward.

   *  Shorter caching can also help with a DNS-based response to DDoS
      attacks.  Specifically, some DDoS-scrubbing services use the DNS
      to redirect traffic during an attack.  Since DDoS attacks arrive
      unannounced, DNS-based traffic redirection requires that the TTL
      be kept quite low at all times to allow operators to suddenly have
      their zone served by a DDoS-scrubbing service.

   *  Shorter caching helps DNS-based load balancing.  Many large
      services are known to rotate traffic among their servers using
      DNS-based load balancing.  Each arriving DNS request provides an
      opportunity to adjust the service load by rotating IP address
      records (A and AAAA) to the lowest unused server.  Shorter TTLs
      may be desired in these architectures to react more quickly to
      traffic dynamics.  Many recursive resolvers, however, have minimum
      caching times of tens of seconds, placing a limit on this form of
      agility.

3.5.2.  Resulting considerations Considerations

   Given these considerations, the proper choice for a TTL depends in
   part on multiple external factors -- no single recommendation is
   appropriate for all scenarios.  Organizations must weigh these trade-
   offs and find a good balance for their situation.  Still, some
   guidelines can be reached when choosing TTLs:

   *  For general DNS zone owners, [Moura19b] recommends a longer TTL of
      at least one hour, hour and ideally 4, 8, 12, or 24 hours.  Assuming planned
      maintenance can be scheduled at least a day in advance, long TTLs
      have little cost and may, even, may even literally provide a cost savings.

   *  For registry operators: TLD and other public registration operators (for example example, most
      ccTLDs and .com, .net, and .org) that host many delegations (NS
      records, DS records records, and "glue" records), [Moura19b] demonstrates
      that most resolvers will use the TTL values provided by the child
      delegations while the others some others will choose the TTL provided by the
      parent's copy of the record.  As such, [Moura19b] recommends
      longer TTLs (at least an hour or more) for registry operators as
      well for child NS and other records.

   *  Users of DNS-based load balancing or DDoS-prevention services may
      require shorter TTLs: TTLs may even need to be as short as 5
      minutes, although 15 minutes may provide sufficient agility for
      many operators.  There is always a tussle between using shorter
      TTLs
      providing that provide more agility against and using longer TTLs that include
      all the benefits listed above for
      using longer TTLs. above.

   *  Use  Regarding the use of A/AAAA and NS records: The records, the TTLs for A/AAAA
      records should be shorter to than or equal to the TTL for the
      corresponding NS records for in-bailiwick authoritative DNS
      servers, since [Moura19b] finds that once an NS record expires,
      their associated A/AAAA will also be re-queried requeried when glue is
      required to be sent by the parents.  For out-of-bailiwick servers,
      A, AAAA AAAA, and NS records are usually all cached independently, so
      different TTLs can be used effectively if desired.  In either
      case, short A and AAAA records may still be desired if DDoS-mitigation DDoS
      mitigation services are required.

3.6.  C6: Consider the TTL differences between parents Difference in Parent and children Children's TTL Values

3.6.1.  Research background Background

   Multiple record types exist or are related between the parent of a
   zone and the child.  At a minimum, NS records are supposed to be
   identical in the parent (but often are not) not), as or are corresponding IP
   address
   addresses in "glue" A/AAAA records that must exist for in-bailiwick
   authoritative servers.  Additionally, if DNSSEC ([RFC4033] [RFC4033] [RFC4034]
   [RFC4035] [RFC4509]) [RFC4509] is deployed for a zone zone, the parent's DS record
   must cryptographically refer to a child's DNSKEY record.

   Because some information exists in both the parent and a child, it is
   possible for the TTL values to differ between the parent's copy and
   the child's.  [Moura19b] examines resolver behaviors when these
   values differ differed in the wild, as they frequently do -- often often, parent
   zones have defacto de facto TTL values that a child has no control over.  For
   example, NS records for TLDs in the root zone are all set to 2 days
   (48 hours), but some TLD's TLDs have lower values within their published
   records (the TTLs for .cl's NS records from their authoritative
   servers is 1 hour).  [Moura19b] also examines the differences in the
   TTLs between the NS records and the corresponding A/AAAA records for
   the addresses of a nameserver. name server.  RIPE Atlas nodes are used to
   determine what resolvers in the wild do with different information, information
   and whether the parent's TTL is used for cache life-times lifetimes ("parent-
   centric") or the child's is used ("child-centric").

   [Moura19b] finds found that roughly 90% of resolvers follow the child's
   view of the TTL, while 10% appear parent-centric.  It additionally
   finds  Additionally, it
   found that resolvers behave differently for cache lifetimes for in-
   bailiwick vs vs. out-of-bailiwick NS/A/AAAA TTL combinations.
   Specifically, when NS TTLs are shorter than the corresponding address
   records, most resolvers will re-query requery for A/AAAA records for the in-
   bailiwick resolvers and switch to new address records even if the
   cache indicates the original A/AAAA records could be kept longer.  On
   the other hand, the inverse is true for out-of-bailiwick resolvers:
   If
   if the NS record expires first first, resolvers will honor the original
   cache time of the nameserver's name server's address.

3.6.2.  Resulting considerations Considerations

   The important conclusion from this study is that operators cannot
   depend on their published TTL values alone -- the parent's values are
   also used for timing cache entries in the wild.  Operators that are
   planning on infrastructure changes should assume that an older
   infrastructure must be left on and operational for at least the
   maximum of both the parent and child's TTLs.

4.  Security considerations Considerations

   This document discusses applying measured research results to
   operational deployments.  Most of the considerations affect mostly
   operational practice, though a few do have security related security-related impacts.

   Specifically, C4 discusses a couple of strategies to employ when a
   service is under stress from DDoS attacks and offers operators
   additional guidance when handling excess traffic.

   Similarly, C5 identifies the trade-offs with respect to the
   operational and security benefits of using longer time-to-live TTL values.

5.  Privacy Considerations

   This document does not add any new, practical new privacy issues, aside
   from possible benefits in deploying longer TTLs as suggested in C5.
   Longer TTLs may help preserve a user's privacy by reducing the number
   of requests that get transmitted in both the client-to-resolver and
   resolver-to-authoritative cases.

6.  IANA considerations Considerations

   This document has no IANA actions.

8.

7.  References

8.1.

7.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC1546]  Partridge, C., Mendez, T., and W. Milliken, "Host
              Anycasting Service", RFC 1546, DOI 10.17487/RFC1546,
              November 1993, <https://www.rfc-editor.org/info/rfc1546>.

   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
              DOI 10.17487/RFC1995, August 1996,
              <https://www.rfc-editor.org/info/rfc1995>.

   [RFC1997]  Chandra, R., Traina, P., and T. Li, "BGP Communities
              Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
              <https://www.rfc-editor.org/info/rfc1997>.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
              <https://www.rfc-editor.org/info/rfc2181>.

   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
              Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
              December 2006, <https://www.rfc-editor.org/info/rfc4786>.

   [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
              (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
              <https://www.rfc-editor.org/info/rfc5936>.

   [RFC7094]  McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
              "Architectural Considerations of IP Anycast", RFC 7094,
              DOI 10.17487/RFC7094, January 2014,
              <https://www.rfc-editor.org/info/rfc7094>.

   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
              January 2019, <https://www.rfc-editor.org/info/rfc8499>.

   [RFC8782]  Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P.,
              Mortensen, A., and N. Teague, "Distributed Denial-of-
              Service Open Threat Signaling (DOTS) Signal Channel
              Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,
              <https://www.rfc-editor.org/info/rfc8782>.

   [RFC8783]  Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed
              Denial-of-Service Open Threat Signaling (DOTS) Data
              Channel Specification", RFC 8783, DOI 10.17487/RFC8783,
              May 2020, <https://www.rfc-editor.org/info/rfc8783>.

   [RFC8955]  Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
              Bacher, "Dissemination of Flow Specification Rules",
              RFC 8955, DOI 10.17487/RFC8955, December 2020,
              <https://www.rfc-editor.org/info/rfc8955>.

8.2.

   [RFC9132]  Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
              "Distributed Denial-of-Service Open Threat Signaling
              (DOTS) Signal Channel Specification", RFC 9132,
              DOI 10.17487/RFC9132, September 2021,
              <https://www.rfc-editor.org/info/rfc9132>.

7.2.  Informative References

   [AnyBest]  Woodcock, B., "Best Practices in DNS Service-Provision
              Architecture", Version 1.2, March 2016,
              <https://meetings.icann.org/en/marrakech55/schedule/mon-
              tech/presentation-dns-service-provision-07mar16-en.pdf>.

   [AnyFRoot] Woolf, S., "Anycasting f.root-serers.net", f.root-servers.net", January 2003,
              <https://archive.nanog.org/meetings/nanog27/presentations/
              suzanne.pdf>.

   [AnyTest]  Schmidt, R.d.O., "Anycast  Tangled, "Tangled Anycast Testbed", December 2018,
              <http://www.anycast-testbed.com/>.

   [Ditl17]   OARC, D.,   DNS-OARC, "2017 DITL data", October 2018, Data", April 2017,
              <https://www.dns-oarc.net/oarc/data/ditl/2017>.

   [IcannHedge18]
              ICANN, ., "DNS-STATS - Hedgehog 2.4.1", October 2018,
              <http://stats.dns.icann.org/hedgehog/>.

   [IcannHedgehog]
              "hedgehog", commit b136eb0, May 2021,
              <https://github.com/dns-stats/hedgehog>.

   [Jung03a]  Jung, J., Berger, A.W., A., and H. Balakrishnan, "Modeling
              TTL-based TTL-
              based Internet caches", Caches", ACM 2003 IEEE INFOCOM,
              DOI 10.1109/INFCOM.2003.1208693, July 2003,
              <http://www.ieee-infocom.org/2003/papers/11_01.PDF>.

   [Moura16b] Moura, G.C.M., Schmidt, R.d.O., R. de O., Heidemann, J., Mueller, de Vries,
              W., Müller, M., Wei, L., and C. Hesselman, "Anycast vs DDoS vs.
              DDoS: Evaluating the November 2015 Root DNS Events.", Event", ACM
              2016 Internet Measurement Conference,
              DOI /10.1145/2987443.2987446, 14
              October 10.1145/2987443.2987446, November 2016,
              <https://www.isi.edu/~johnh/PAPERS/Moura16b.pdf>.

   [Moura18b] Moura, G.C.M., Heidemann, J., Mueller, Müller, M., Schmidt,
              R.d.O., R. de
              O., and M. Davids, "When the Dike Breaks: Dissecting DNS
              Defenses During DDos", DDoS", ACM 2018 Internet Measurement
              Conference, DOI 10.1145/3278532.3278534, 31 October 2018,
              <https://www.isi.edu/~johnh/PAPERS/Moura18b.pdf>.

   [Moura19b] Moura, G., G.C.M., Hardaker, W., Heidemann, J., and R.d.O. R. de O.
              Schmidt, "Cache Me If You Can: Effects of DNS Time-to-
              Live", ACM 2019 Internet Measurement Conference,
              DOI 10.1145/3355369.3355568, n.d., October 2019,
              <https://www.isi.edu/~hardaker/papers/2019-10-cache-me-
              ttls.pdf>.

   [Mueller17b]
              Mueller,
              Müller, M., Moura, G.C.M., Schmidt, R.d.O., R. de O., and J.
              Heidemann, "Recursives in the Wild- Wild: Engineering
              Authoritative DNS Servers.", Servers", ACM 2017 Internet Measurement
              Conference, DOI 10.1145/3131365.3131366, October November 2017,
              <https://www.isi.edu/%7ejohnh/PAPERS/Mueller17b.pdf>.

   [Perlroth16]
              Perlroth, N., "Hackers Used New Weapons to Disrupt Major
              Websites Across U.S.", October 2016,
              <https://www.nytimes.com/2016/10/22/business/internet-
              problems-attack.html>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/info/rfc4033>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/info/rfc4034>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <https://www.rfc-editor.org/info/rfc4035>.

   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
              (DS) Resource Records (RRs)", RFC 4509,
              DOI 10.17487/RFC4509, May 2006,
              <https://www.rfc-editor.org/info/rfc4509>.

   [RFC8811]  Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F.,
              Teague, N., and R. Compton, "DDoS Open Threat Signaling
              (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811,
              August 2020, <https://www.rfc-editor.org/info/rfc8811>.

   [RipeAtlas15a]
              Staff, R.N.,
              RIPE Network Coordination Centre (RIPE NCC), "RIPE Atlas Atlas:
              A Global Internet Measurement Network", September October 2015,
              <http://ipj.dreamhosters.com/wp-
              content/uploads/issues/2015/ipj18-3.pdf>.

   [RipeAtlas19a]
              NCC, R., "Ripe Atlas -
              RIPE Network Coordination Centre",
              September 2019, <https://atlas.ripe.net/>. Centre (RIPE NCC), "RIPE Atlas",
              <https://atlas.ripe.net>.

   [Schmidt17a]
              Schmidt, R.d.O., R. de O., Heidemann, J., and J.H. J. Kuipers, "Anycast
              Latency -
              Latency: How Many Sites Are Enough. In Proceedings of the
              Passive and Active Measurement Workshop", Enough?", PAM 2017 Passive and
              Active Measurement Conference,
              DOI 10.1007/978-3-319-54328-4_14, March 2017,
              <https://www.isi.edu/%7ejohnh/PAPERS/Schmidt17a.pdf>.

   [Singla2014]
              Singla, A., Chandrasekaran, B., Godfrey, P.B., P., and B. Maggs,
              "The Internet at the speed of light. In Proceedings Speed of the Light", 13th ACM Workshop on
              Hot Topics in Networks (Oct
              2014)", ACM Workshop on Hot Topics in Networks, DOI 10.1145/2670518.2673876,
              October 2014,
              <http://speedierweb.web.engr.illinois.edu/cspeed/papers/
              hotnets14.pdf>.

   [VerfSrc]  Vries, W.d.,  "Verfploeter source code", November 2018, Source Code", commit f4792dc, May 2019,
              <https://github.com/Woutifier/verfploeter>.

   [Vries17b] de Vries, W.d., W., Schmidt, R.d.O., R. de O., Hardaker, W., Heidemann,
              J., de Boer, P.d., P-T., and A. Pras, "Verfploeter - Broad "Broad and Load-
              Aware Load-Aware
              Anycast Mapping", Mapping with Verfploeter", ACM 2017 Internet
              Measurement Conference, DOI 10.1145/3131365.3131371, October
              November 2017,
              <https://www.isi.edu/%7ejohnh/PAPERS/Vries17b.pdf>.

Acknowledgements

   This document is a summary of the main considerations of six research
   works performed by the authors and others.  This document would not
   have been possible without the hard work of these authors and co-
   authors:

   *  Ricardo de O.  Schmidt

   *  Wouter B de Vries

   *  Moritz Mueller

   *  Lan Wei

   *  Cristian Hesselman

   *  Jan Harm Kuipers

   *  Pieter-Tjerk de Boer

   *  Aiko Pras

   We would like also to thank the reviewers of this draft that document who offered
   valuable suggestions: suggestions as well as comments at the IETF DNSOP session
   (IETF 104): Duane Wessels, Joe Abley, Toema Gavrichenkov, John
   Levine, Michael StJohns, Kristof Tuyteleers, Stefan Ubbink, Klaus Darilion
   Darilion, and Samir Jafferali, and comments provided at the IETF
   DNSOP session (IETF104).

   Besides those, Jafferali.

   Additionally, we would like thank those acknowledged in the papers
   this document summarizes for helping produce the results: RIPE NCC
   and DNS OARC for their tools and datasets used in this research, as
   well as the funding agencies sponsoring the individual research.

Contributors

   This document is a summary of the main considerations of six research
   works.
   papers written by the authors and the following people who
   contributed substantially to the content and should be considered
   coauthors; this document would not have been possible without their
   hard work:

   *  Ricardo de O. Schmidt

   *  Wouter B. de Vries

   *  Moritz Mueller

   *  Lan Wei

   *  Cristian Hesselman

   *  Jan Harm Kuipers

   *  Pieter-Tjerk de Boer

   *  Aiko Pras

Authors' Addresses

   Giovane C. M. Moura
   SIDN Labs/TU Delft
   Meander 501
   6825 MD Arnhem
   Netherlands
   Phone: +31 26 352 5500
   Email: giovane.moura@sidn.nl

   Wes Hardaker
   USC/Information Sciences Institute
   PO Box 382
   Davis, CA 95617-0382
   United States of America
   Phone: +1 (530) 404-0099
   Email: ietf@hardakers.net

   John Heidemann
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina Del Rey, CA 90292-6695
   United States of America
   Phone: +1 (310) 448-8708
   Email: johnh@isi.edu

   Marco Davids
   SIDN Labs
   Meander 501
   6825 MD Arnhem
   Netherlands
   Phone: +31 26 352 5500
   Email: marco.davids@sidn.nl