DNSOP Working Group G. Moura Internet-Draft SIDN Labs/TU Delft Intended status: Informational W. Hardaker Expires: January 27, 2020 J. Heidemann USC/Information Sciences Institute M. Davids SIDN Labs July 26, 2019 Considerations for Large Authoritative DNS Servers Operators draft-moura-dnsop-authoritative-recommendations-05 Abstract This document summarizes recent research work exploring DNS configurations and offers specific, tangible considerations to operators for configuring authoritative servers. This document is not an Internet Standards Track specification; it is published for informational purposes. Ed note This draft will be renamed to draft-moura-dnsop-large-authoritative- considerations in case adpoted by the WG, to reflect the new title. Text inside square brackets ([RF:ABC]) refers to: o individual comments we have received about the draft, and enumerated under . o Issues listed on our Github repository Both types will be removed before publication. This draft is being hosted on GitHub - , where the most recent version of the document and open issues can be found. The authors gratefully accept pull requests. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Moura, et al. Expires January 27, 2020 [Page 1] Internet-Draft Considerations-Large-Auth-DNS-Ops July 2019 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents 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 January 27, 2020. Copyright Notice Copyright (c) 2019 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. C1: Use equally strong IP anycast in every authoritative server (NS) for better load distribution . . . . . . . . . . 5 4. C2: Routing Can Matter More Than Locations . . . . . . . . . 6 5. C3: Collecting Detailed Anycast Catchment Maps Ahead of Actual Deployment Can Improve Engineering Designs . . . . . . 7 6. C4: When under stress, employ two strategies . . . . . . . . 9 7. C5: Consider longer time-to-live values whenever possible . . 10 8. Security considerations . . . . . . . . . . . . . . . . . . . 12 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Moura, et al. Expires January 27, 2020 [Page 2] Internet-Draft Considerations-Large-Auth-DNS-Ops July 2019 1. Introduction This document summarizes recent research work exploring DNS configurations and offers specific tangible considerations to DNS authoritative servers operators (DNS operators hereafter). [RF:JAb2]], [RF:MSJ1], [RF:DW2]. The considerations (C1-C5) presented in this document are backed by previous research work, which used wide-scale Internet measurements upon which to draw their conclusions. This document describes the key engineering options, and points readers to the pertinent papers for details and [RF:Issue15] other research works related to each consideration here presented. [RF:JAb1, Issue#2, SJa-02]. These considerations are designed for operators of "large" authoritative servers. In this context, "large" authoritative servers refers to those with a significant global user population, like TLDs, run by a single or multiple operators. These considerations may not be appropriate for smaller domains, such as those used by an organization with users in one city or region, where goals such as uniform low latency are less strict. It is likely that these considerations might be useful in a wider context, such as for any stateless/short-duration, anycasted service. Because the conclusions of the studies don't verify this fact, the wording in this document discusses DNS authoritative services only ([RF:Issue13]). 2. Background The domain name system (DNS) has main two types of DNS servers: authoritative servers and recursive resolvers. Figure 1 shows their relationship. An authoritative server (ATn in Figure 1) knows the content of a DNS zone from local knowledge, and thus can answer queries about that zone without needing to query other servers [RFC2181]. A recursive resolver (Re_n) is a program that extracts information from name servers in response to client requests [RFC1034]. A client (stub in Figure 1) refers to stub resolver [RFC1034] that is typically located within the client software. Moura, et al. Expires January 27, 2020 [Page 3] Internet-Draft Considerations-Large-Auth-DNS-Ops July 2019 +-----+ +-----+ +-----+ +-----+ | AT1 | | AT2 | | AT3 | | AT4 | +-----+ +-----+ +-----+ +-----+ ^ ^ ^ ^ | | | | | +-----+ | | +------|Re_1 |------+ | | +-----+ | | ^ | | | | | +-----+ +-----+ | +------|Re_2 | |Re_3 |-----+ +-----+ +-----+ ^ ^ | | | +------+ | +-| stub |--+ +------+ Figure 1: Relationship between recursive resolvers (Re_n) and authoritative name servers (ATn) DNS queries/responses contribute to user's perceived latency and affect user experience [Sigla2014], and the DNS system has been subject to repeated Denial of Service (DoS) attacks (for example, in November 2015 [Moura16b]) in order to degrade user experience. To reduce latency and improve resiliency against DoS attacks, DNS uses several types of server replication. Replication at the authoritative server level can be achieved with (i) the deployment of multiple servers for the same zone [RFC1035] (AT1--AT4 in Figure 1), (ii) the use of IP anycast [RFC1546][RFC4786][RFC7094] that allows the same IP address to be announced from multiple locations (each of them referred to as anycast instance [RFC8499]) and (iii) by using 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, with multiple viable choices and no single optimal design. In the next sections we cover specific considerations (C1-C5) for large authoritative DNS servers operators. Moura, et al. Expires January 27, 2020 [Page 4] Internet-Draft Considerations-Large-Auth-DNS-Ops July 2019 3. C1: Use equally strong IP anycast in every authoritative server (NS) for better load distribution Authoritative DNS servers operators announce their authoritative servers as NS records[RFC1034]. Different authoritatives for a given zone should return the same content, typically by staying synchronized using DNS zone transfers (AXFR[RFC5936] and IXFR[RFC1995]) to coordinate the authoritative zone data to return to their clients. DNS heavily relies upon replication to support high reliability, capacity and to reduce latency [Moura16b]. DNS has two complementary mechanisms to replicate the service. First, the protocol itself supports nameserver replication of DNS service for a DNS zone through the use of multiple nameservers that each operate on different IP addresses, listed by a zone's NS records. Second, each of these network addresses can run from multiple physical locations through the use of IP anycast[RFC1546][RFC4786][RFC7094], by announcing the same IP address from each instance and allowing Internet routing (BGP[RFC4271]) to associate clients with their topologically nearest anycast instance. Outside the DNS protocol, replication can be achieved by deploying load balancers at each physical location. Nameserver replication is recommended for all zones (multiple NS records), and IP anycast is used by most large zones such as the DNS Root, most top-level domains[Moura16b] and large commercial enterprises, governments and other organizations. Most DNS operators strive to reduce latency for users of their service. However, because they control only their authoritative servers, and not the recursive resolvers communicating with those servers, it is difficult to ensure that recursives will be served by the closest authoritative server. Server selection is up to the recursive resolver's software implementation, and different software vendors and releases employ different criteria to chose which authoritative servers with which to communicate. Knowing how recursives choose authoritative servers is a key step to better engineer the deployment of authoritative servers. [Mueller17b] evaluates this with a measurement study in which they deployed seven unicast authoritative name servers in different global locations and queried these authoritative servers from more than 9k RIPE Atlas probes and their respective recursive resolvers. In the wild, [Mueller17b] found that recursives query all available authoritative servers, regardless of the observed latency. But the distribution of queries tend 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 Moura, et al. Expires January 27, 2020 [Page 5] Internet-Draft Considerations-Large-Auth-DNS-Ops July 2019 queries to that authoritative. These results were obtained by aggregating results from all vantage points and not specific to any vendor/version. The hypothesis is that this behavior is a consequence of two main criteria employed by resolvers when choosing authoritatives: performance (lower latency) and diversity of authoritatives, where a resolver checks all authoritative servers to determine which is closer and to provide alternatives if one is unavailable. For a DNS operator, this policy means that latency of all authoritatives (NS records [RF:SJa-01]) matter, so all must be similarly capable, since all available authoritatives will be queried by most recursive resolvers. Since unicast cannot deliver good latency worldwide (a unicast authoritative server in Europe will always have high latency to resolvers in California, for example, given its geographical distance), [Mueller17b] recommends to DNS operators that they deploy equally strong IP anycast in every authoritative server (i.e., on each NS record [RF:SJa-01]), in terms of number of instances and peering, and, consequently, to phase out unicast, so they can deliver good latency values to global clients. However, [Mueller17b] also notes that DNS operators should also take architectural considerations into account when planning for deploying anycast [RFC1546]. This consideration was deployed at the ".nl" TLD zone, which originally had seven authoritative severs (mixed unicast/anycast setup). .nl has moved in early 2018 to a setup with 4 anycast authoritative name servers. This is not to say that .nl was the first - other zones, have been running anycast only authoritatives (e.g., .be since 2013). [Mueller17b] contribution is to show that unicast cannot deliver good latency worldwide, and that anycast has to be deployed to deliver good latency worldwide. 4. C2: Routing Can Matter More Than Locations A common metric when choosing an anycast DNS provider or setting up an anycast service is the number of anycast instances[RFC4786], i.e., the number of global locations from which the same address is announced with BGP. Intuitively, one could think that more instances will lead to shorter response times. However, this is not necessarily true. In fact, [Schmidt17a] found that routing can matter more than the total number of locations. They analyzed the relationship between the number of anycast instances and the performance of a service (latency-wise, RTT) and measured the overall performance of four DNS Root servers, namely C, F, K and L, from more than 7.9k RIPE Atlas probes. Moura, et al. Expires January 27, 2020 [Page 6] Internet-Draft Considerations-Large-Auth-DNS-Ops July 2019 [Schmidt17a] found that C-Root, a smaller anycast deployment consisting of only 8 instances (they refer to anycast instance as anycast site), provided a very similar overall performance than that of the much larger deployments of K and L, with 33 and 144 instances respectively. The median RTT for C, K and L Root was between 30-32ms. Given that Atlas has better coverage in Europe than other regions, the authors specifically analyzed results per region and per country (Figure 5 in [Schmidt17a]), and show that Atlas bias to Europe does not change the conclusion that location of anycast instances dominates latency. [RF:Issue12] [Schmidt17a] consideration for DNS operators when engineering anycast services is consider factors other than just the number of instances (such as local routing connectivity) when designing for performance. They showed that 12 instances can provide reasonable latency, given they are globally distributed and have good local interconnectivity. However, more instances can be useful for other reasons, such as when handling DDoS attacks [Moura16b]. 5. C3: Collecting Detailed Anycast Catchment Maps Ahead of Actual Deployment Can Improve Engineering Designs An anycast DNS service may have several dozens or even more than one hundred instances (such as L-Root does). Anycast leverages Internet routing to distribute the incoming queries to a service's distributed anycast instances; in theory, BGP (the Internet's defacto routing protocol) forwards incoming queries to a nearby anycast instance (in terms of BGP distance). However, usually queries are not evenly distributed across all anycast instances, as found in the case of L-Root [IcannHedge18]. Adding new instances to an anycast service may change the load distribution across all instances, leading to suboptimal usage of the service or even stressing some instances while others remain underutilized. This is a scenario that operators constantly face when expanding an anycast service. Besides, when setting up a new anycast service instance, operators cannot directly estimate the query distribution among the instances in advance of enabling the new instance. To estimate the query loads across instances of an expanding service or a when setting up an entirely new service, operators need detailed anycast maps and catchment estimates (i.e., operators need to know which prefixes will be matched to which anycast instance). To do that, [Vries17b] developed a new technique enabling operators to carry out active measurements, using an open-source tool called Moura, et al. Expires January 27, 2020 [Page 7] Internet-Draft Considerations-Large-Auth-DNS-Ops July 2019 Verfploeter (available at [VerfSrc]). Verfploeter maps a large portion of the IPv4 address space, allowing DNS operators to predict both query distribution and clients catchment before deploying new anycast instances. [Vries17b] shows how this technique was used to predict both the catchment and query load distribution for the new anycast service of B-Root. Using two anycast instances in Miami (MIA) and Los Angeles (LAX) from the operational B-Root server, they sent ICMP echo packets to IP addresses to each IPv4 /24 on the Internet using a source address within the anycast prefix. Then, they recorded which instance the ICMP echo replies arrived at based on the Internet's BGP routing. This analysis resulted in an Internet wide catchment map. Weighting was then applied to the incoming traffic prefixes based on of 1 day of B-Root traffic (2017-04-12, DITL datasets [Ditl17]). The combination of the created catchment mapping and the load per prefix created an estimate predicting that 81.6% of the traffic would go to the LAX instance. The actual value was 81.4% of traffic going to LAX, showing that the estimation was pretty close and the Verfploeter technique was a excellent method of predicting traffic loads in advance of a new anycast instance deployment ([Vries17b] also uses the term anycast site to refer to anycast instance). Besides that, Verfploeter can also be used to estimate how traffic shifts among instances when BGP manipulations are executed, such as AS Path prepending that is frequently used by production networks during DDoS attacks. A new catchment mapping for each prepending configuration configuration: no prepending, and prepending with 1, 2 or 3 hops at each instance. Then, [Vries17b] shows that this mapping can accurately estimate the load distribution for each configuration. An important operational takeaway from [Vries17b] is that DNS operators can make informed choices when engineering new anycast instances or when expending new ones by carrying out active measurements using Verfploeter in advance of operationally enabling the fully anycast service. Operators can spot sub-optimal routing situations early, with a fine granularity, and with significantly better coverage than using traditional measurement platforms such as RIPE Atlas. To date, Verfploeter has been deployed on B-Root[Vries17b], on a operational testbed (Anycast testbed) [AnyTest], and on a large unnamed operator. The consideration is therefore to deploy a small test Verfploeter- enabled platform in advance at a potential anycast instance may reveal the realizable benefits of using that instance as an anycast interest, potentially saving significant financial and labor costs of Moura, et al. Expires January 27, 2020 [Page 8] Internet-Draft Considerations-Large-Auth-DNS-Ops July 2019 deploying hardware to a new instance that was less effective than as had been hoped. 6. C4: When under stress, employ two strategies DDoS attacks are becoming bigger, cheaper, and more frequent [Moura16b]. The most powerful recorded DDoS attack to DNS servers to date reached 1.2 Tbps, by using IoT devices [Perlroth16]. Such attacks call for an answer for the following question: how should a DNS operator engineer its anycast authoritative DNS server react to the stress of a DDoS attack? This question is investigated in study [Moura16b] in which empirical observations are grounded with the following theoretical evaluation of options. 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 protocol that maps clients to specific anycast instances by using routing information [RF:KDar02]. 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 some instances may be more overloaded than others which is what was observed analyzing the Root DNS events of Nov. 2015 [Moura16b]. Given the fact that different instances may have different capacity (bandwidth, CPU, etc.), making a decision about how to react to stress becomes even more difficult. In practice, an anycast instance under stress, overloaded with incoming traffic, has two options: o It can withdraw or pre-prepend its route to some or to all of its neighbors, ([RF:Issue3]) perform other traffic shifting tricks (such as reducing the propagation of its announcements using BGP communities[RFC1997]) which shrinks portions of its catchment), use FlowSpec [RFC5575] or other upstream communication mechanisms to deploy upstream filtering. The goals of these techniques is to perform some combination of shifting of both legitimate and attack traffic to other anycast instances (with hopefully greater capacity) or to block the traffic entirely. o Alternatively, it can be become a degraded absorber, continuing to operate, but with overloaded ingress routers, dropping some incoming legitimate requests due to queue overflow. However, continued operation will also absorb traffic from attackers in its catchment, protecting the other anycast instances. Moura, et al. Expires January 27, 2020 [Page 9] Internet-Draft Considerations-Large-Auth-DNS-Ops July 2019 [Moura16b] saw both of these behaviors in practice in the Root DNS events, observed through instance reachability and route-trip time (RTTs). These options represent different uses of an anycast deployment. The withdrawal strategy causes anycast to respond as a waterbed, with stress displacing queries from one instance to others. The absorption strategy behaves as a conventional mattress, compressing under load, with some queries getting delayed or dropped. Although described as strategies and policies, these outcomes are the result of several factors: the combination of operator and host ISP routing policies, routing implementations withdrawing under load, the nature of the attack, and the locations of the instances and the attackers. Some policies are explicit, such as the choice of local- only anycast instances, or operators removing an instance for maintenance or modifying routing to manage load. However, under stress, the choices of withdrawal and absorption can also be results that emerge from a mix of explicit choices and implementation details, such as BGP timeout values. [Moura16b] speculates that more careful, explicit, and automated management of policies may provide stronger defenses to overload, an area currently under study. For DNS operators, that means that besides traditional filtering, two other options are available (withdraw/prepend/communities or isolate instances), and the best choice depends on the specifics of the attack. Note that this consideration refers to the operation of one anycast service, i.e., one anycast NS record. However, DNS zones with multiple NS anycast services may expect load to spill from one anycast server to another,as resolvers switch from authoritative to authoritative when attempting to resolve a name [Mueller17b]. 7. C5: Consider longer time-to-live values whenever possible [RF:Issue7]: this section has been completely rewritten. Caching is the cornerstone of good DNS performance and reliability. A 15 ms response to a new DNS query is fast, but a 1 ms cache hit to a repeat query is far faster. Caching also protects users from short outages and can mute even significant DDoS attacks [Moura18b]. DNS record TTLs (time-to-live values) directly control cache durations [RFC1034][RFC1035] and, therefore, affect latency, resilience, and the role of DNS in CDN server selection. Some early work modeled caches as a function of their TTLs [Jung03a], and recent work examined their interaction with DNS[Moura18b], but no research provides considerations about what TTL values are good. With this Moura, et al. Expires January 27, 2020 [Page 10] Internet-Draft Considerations-Large-Auth-DNS-Ops July 2019 goal Moura et. al. [Moura19a] carried out a measurement study investigating TTL choices and its impact on user experience. First, they identified several reasons why operators/zone owners may want to choose longer or shorter TTLs: o Longer TTL leads to longer caching, which results in faster responses, given that cache hits are faster than cache misses in resolvers. [Moura19a] shows that the increase in the TTL for .uy TLD from 5 minutes (300s) to 1 day (86400s) reduced the latency from 15k Atlas vantage points significantly: the median RTT went from 28.7ms to 8ms, while the 75%ile decreased from 183ms to 21ms. o Longer caching results in lower DNS traffic: authoritative servers will experience less traffic if TTLs are extended, given that repeated queries will be answered by resolver caches. o Longer caching results in lower cost if DNS is metered: some DNS- As-A-Service providers charges are metered, with a per query cost (often added to a fixed monthly cost). o Longer caching is more robust to DDoS attacks on DNS: DDoS attacks on a DNS service provider harmed several prominent websites [Perlroth16]. Recent work has shown that DNS caching can greatly reduce the effects of DDoS on DNS, provided caches last longer than the attack [Moura18b]. o Shorter caching supports operational changes: An easy way to transition from an old server to a new one is to change the DNS records. Since there is no method to remove cached DNS records, the TTL duration represents a necessary transition delay to fully shift to a new server, so low TTLs allow more rapid transition. However, when deployments are planned in advance (that is, longer than the TTL), then TTLs can be lowered ''just-before'' a major operational change, and raised again once accomplished. o Shorter caching can with DNS-based load balancing: Some DDoS- scrubbing services use DNS to redirect traffic during an attack. Since DDoS attacks arrive unannounced, DNS-based traffic redirection requires the TTL be kept quite low at all times to be ready to respond to a potential attack. As such, choice of TTL depends in part on external factors so no single recommendation is appropriate for all. Organizations must weigh these trade-offs to find a good balance. Still, some guidelines can be used when choosing TTLs: Moura, et al. Expires January 27, 2020 [Page 11] Internet-Draft Considerations-Large-Auth-DNS-Ops July 2019 o For general users, [Moura19a] recommends longer TTLs, of at least one 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. o For TLD operators: TLD operators that allow public registration of domains (such as most ccTLDs and .com, .net, .org) host, in their zone files, NS records (and glues if in-bailiwick) of their respective domains. [Moura19a] shows that most resolvers will use TTL values provided by the child delegations, but some will choose the TTL provided by the parents. As such, similarly to general users, [Moura19a] recommends longer TTLs for NS records of their delegations (at least one hour, preferably more). o Users of DNS-based load balancing or DDoS-prevention may require short TTLs: TTLs may be as short as 5 minutes, although 15 minutes may provide sufficient agility for many operators. Shorter TTLs here help agility; they are are an exception to the consideration for longer TTLs. o Use A/AAAA and NS records: TTLs of A/AAAA records should be shorter or equal to the TTL for NS records for in-bailiwick authoritative DNS servers, given that the authors [Moura19a] found that, for such scenarios, once NS record expires, their associated A/AAAA will also be updated (glue is sent by the parents). For out-of-bailiwick servers, A and NS records are usually cached independently, so different TTLs, if desired, will be effective. In either case, short A and AAAA records may be desired if DDoS- mitigation services are an option. 8. Security considerations This document suggests the use of [I-D.ietf-dnsop-serve-stale]. It be noted that usage of such methods may affect data integrity of DNS information. This document describes methods of mitigating changes of a denial of service threat within a DNS service. As this document discusses research, there are no further security considerations, other than the ones mentioned in the normative references. 9. Privacy Considerations This document does not add any practical new privacy issues. Moura, et al. Expires January 27, 2020 [Page 12] Internet-Draft Considerations-Large-Auth-DNS-Ops July 2019 10. IANA considerations This document has no IANA actions. 11. Acknowledgements This document is a summary of the main considerations of six research works referred in this document. As such, they were only possible thanks to the hard work of the authors of these research works. o Ricardo de O. Schmidt o Wouter B de Vries o Moritz Mueller o Lan Wei o Cristian Hesselman o Jan Harm Kuipers o Pieter-Tjerk de Boer o Aiko Pras We would like also to thank the various reviewers of different versions of this draft: Duane Wessels, Joe Abley, Toema Gavrichenkov, John Levine, Michael StJohns, Kristof Tuyteleers, Stefan Ubbink, Klaus Darilion and Samir Jafferali, and comments provided at the IETF DNSOP session (IETF104). Besides those, we would like thank those who have been individually thanked in each research work, RIPE NCC and DNS OARC for their tools and datasets used in this research, as well as the funding agencies sponsoring the individual research works. 12. References 12.1. Normative References [I-D.ietf-dnsop-serve-stale] Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data to Improve DNS Resiliency", draft-ietf-dnsop-serve- stale-05 (work in progress), April 2019. Moura, et al. Expires January 27, 2020 [Page 13] Internet-Draft Considerations-Large-Auth-DNS-Ops July 2019 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, DOI 10.17487/RFC1546, November 1993, . [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, DOI 10.17487/RFC1995, August 1996, . [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, . [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, . [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, . [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, DOI 10.17487/RFC7094, January 2014, . Moura, et al. Expires January 27, 2020 [Page 14] Internet-Draft Considerations-Large-Auth-DNS-Ops July 2019 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . 12.2. Informative References [AnyTest] Schmidt, R., "Anycast Testbed", December 2018, . [Ditl17] OARC, D., "2017 DITL data", October 2018, . [IcannHedge18] ICANN, ., "DNS-STATS - Hedgehog 2.4.1", October 2018, . [Jung03a] Jung, J., Berger, A., and H. Balakrishnan, "Modeling TTL- based Internet caches", ACM 2003 IEEE INFOCOM, DOI 10.1109/INFCOM.2003.1208693, July 2003, . [Moura16b] Moura, G., Schmidt, R., Heidemann, J., Mueller, M., Wei, L., and C. Hesselman, "Anycast vs DDoS Evaluating the November 2015 Root DNS Events.", ACM 2016 Internet Measurement Conference, DOI /10.1145/2987443.2987446, October 2016, . [Moura18b] Moura, G., Heidemann, J., Mueller, M., Schmidt, R., and M. Davids, "When the Dike Breaks: Dissecting DNS Defenses During DDos", ACM 2018 Internet Measurement Conference, DOI 10.1145/3278532.3278534, October 2018, . [Moura19a] Moura, G., Heidemann, J., Schmidt, R., and W. Hardaker, "Cache Me If You Can: Effects of DNS Time-to-Live", ACM 2019 Internet Measurement Conference, DOI Note: ``This paper has been accepted at IMC2019 and will appear in its program. The current version referred here is the version submitted for review, and not the final version to be published at IMC2019. We are working on the final version (camera ready) and will later update this reference to include it``, October 2019, . Moura, et al. Expires January 27, 2020 [Page 15] Internet-Draft Considerations-Large-Auth-DNS-Ops July 2019 [Mueller17b] Mueller, M., Moura, G., Schmidt, R., and J. Heidemann, "Recursives in the Wild- Engineering Authoritative DNS Servers.", ACM 2017 Internet Measurement Conference, DOI 10.1145/3131365.3131366, October 2017, . [Perlroth16] Perlroth, N., "Hackers Used New Weapons to Disrupt Major Websites Across U.S.", October 2016, . [Schmidt17a] Schmidt, R., Heidemann, J., and J. Kuipers, "Anycast Latency - How Many Sites Are Enough. In Proceedings of the Passive and Active Measurement Workshop", PAM Passive and Active Measurement Conference, March 2017, . [Sigla2014] Singla, A., Chandrasekaran, B., Godfrey, P., and B. Maggs, "The Internet at the speed of light. In Proceedings of the 13th ACM Workshop on Hot Topics in Networks (Oct 2014)", ACM Workshop on Hot Topics in Networks, October 2014, . [VerfSrc] Vries, W., "Verfploeter source code", November 2018, . [Vries17b] Vries, W., Schmidt, R., Hardaker, W., Heidemann, J., Boer, P., and A. Pras, "Verfploeter - Broad and Load-Aware Anycast Mapping", ACM 2017 Internet Measurement Conference, DOI 10.1145/3131365.3131371, October 2017, . Authors' Addresses Giovane C. M. Moura SIDN Labs/TU Delft Meander 501 Arnhem 6825 MD The Netherlands Phone: +31 26 352 5500 Email: giovane.moura@sidn.nl Moura, et al. Expires January 27, 2020 [Page 16] Internet-Draft Considerations-Large-Auth-DNS-Ops July 2019 Wes Hardaker USC/Information Sciences Institute PO Box 382 Davis 95617-0382 U.S.A. Phone: +1 (530) 404-0099 Email: ietf@hardakers.net John Heidemann USC/Information Sciences Institute 4676 Admiralty Way Marina Del Rey 90292-6695 U.S.A. Phone: +1 (310) 448-8708 Email: johnh@isi.edu Marco Davids SIDN Labs Meander 501 Arnhem 6825 MD The Netherlands Phone: +31 26 352 5500 Email: marco.davids@sidn.nl Moura, et al. Expires January 27, 2020 [Page 17]