RFC 9199

Considerations for Large Authoritative DNS Server Operators

📅 published March 2022, from ietf

RFC 9199: Considerations for Large Authoritative DNS Server Operators 🎀

okay bestie, this is an Informational doc from the Independent Submission stream, so it's a helpful guide and not a standard you have to follow 🫶

  • Authors: G. Moura (SIDN Labs/TU Delft), W. Hardaker, J. Heidemann (USC/Information Sciences Institute), M. Davids (SIDN Labs)
  • Category: Informational
  • Stream: Independent Submission
  • ISSN: 2070-1721
  • Date: March 2022
  • Obsoletes / Updates: none listed

Abstract ✨

okay so this doc is about recent research on how the Domain Name System (DNS) gets deployed and configured 🌸 It sums up what those research papers found and turns it into specific, tangible considerations and advice for people who run authoritative DNS servers. if you run one, these considerations might help you make your DNS service better 💅

it's also possible the results here apply to more than just DNS, because some of them could generally apply to any stateless or short-duration anycasted service 🦋

heads up: this doc is not an IETF consensus document. it's published just for informational purposes 🙈

Status of This Memo ✨

this doc is not an Internet Standards Track specification. it's published for informational purposes 💜

this is a contribution to the RFC Series, and it's independent of any other RFC stream. the RFC Editor picked to publish it at their discretion, and they don't say anything about how useful it is for implementing or deploying stuff 🎀 Documents the RFC Editor approves for publication are not candidates for any level of Internet Standard, see Section 2 of RFC 7841 💅

for info on the current status of this doc, any errata, and how to give feedback, check out https://www.rfc-editor.org/info/rfc9199 🌈

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

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date this doc was published. please read these carefully, because they explain your rights and restrictions for this doc 📜

Table of Contents ✨

1.  Introduction
2.  Background
3.  Considerations
  3.1.  C1: Deploy Anycast in Every Authoritative Server to Enhance
        Distribution and Latency
    3.1.1.  Research Background
    3.1.2.  Resulting Considerations
  3.2.  C2: Optimizing Routing is More Important than Location
        Count and Diversity
    3.2.1.  Research Background
    3.2.2.  Resulting Considerations
  3.3.  C3: Collect Anycast Catchment Maps to Improve Design
    3.3.1.  Research Background
    3.3.2.  Resulting Considerations
  3.4.  C4: Employ Two Strategies When under Stress
    3.4.1.  Research Background
    3.4.2.  Resulting Considerations
  3.5.  C5: Consider Longer Time-to-Live Values Whenever Possible
    3.5.1.  Research Background
    3.5.2.  Resulting Considerations
  3.6.  C6: Consider the Difference in Parent and Children's TTL
        Values
    3.6.1.  Research Background
    3.6.2.  Resulting Considerations
4.  Security Considerations
5.  Privacy Considerations
6.  IANA Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction 🦋

okay so this doc sums up recent research that looked at how DNS setups are actually deployed. then it gives you derived, specific, tangible advice for DNS authoritative server operators (we'll call them "DNS operators" from here on) 💖 The considerations (C1-C6) in here are backed by peer-reviewed research that used wide-scale Internet measurements to reach its conclusions. This doc summarizes those results and describes the key engineering options that come out of them. Each section points you to the relevant publications, so you can dig into the details 🔥

these considerations are made for operators of "large" authoritative DNS servers. in this context, that means servers with a huge global user base, like top-level domain (TLD) operators, whether they're run by one operator or several 👑 These networks are typically deployed on wide anycast networks [RFC1546] [AnyBest]. The considerations might not fit smaller domains, like the ones used by an organization whose users are all on one unicast network or in a single city or region. Those setups don't really need goals like uniform, global low latency 🍓

again, it's possible the results here could apply to a wider context than just DNS, since some of them could generally apply to any stateless or short-duration anycasted service. But because the studies they're based on don't measure smaller networks, this doc only talks about large-scale DNS authoritative services 🌈

this doc is not an IETF consensus document, it's published for informational purposes 🙈

2. Background 💅

okay so DNS has two main kinds of servers: authoritative servers and recursive resolvers. Figure 1 shows a representative deployment model. An authoritative server (shown as AT1-AT4 in Figure 1) knows the content of a DNS zone and is responsible for answering queries about that zone 🧚 It runs off local copies of the zone, which might get updated automatically, and it doesn't need to query other servers [RFC2181] to answer requests. A recursive resolver (Re1-Re3) is a server that iteratively queries authoritative and other servers to answer queries from client requests [RFC1034]. A client usually uses a software library called a "stub resolver" ("stub" in Figure 1) to send its query to the upstream recursive resolvers [RFC1034] 🎀

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

     Figure 1: Relationship between Recursive Resolvers (Re) and
                   Authoritative Name Servers (ATn)

DNS queries from a client add to a user's perceived latency and affect their experience [Singla2014], depending on how long it takes for the responses to come back ⏱️ The DNS system has also been hit by repeated Denial-of-Service (DoS) attacks (for example, in November 2015 [Moura16b]) that were specifically meant to wreck the user experience 😭

to cut down on latency and make things tougher against DoS attacks, DNS uses several kinds of service replication. Replication at the authoritative server level can be done with the following:

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 lets the same IP address be announced from multiple locations (each of which is called an "anycast instance" [RFC8499]); and

iii. the use of load balancers to support multiple servers inside a single (potentially anycasted) instance. So yeah, there are lots of possible ways an authoritative DNS provider can build its production authoritative server network with multiple viable choices, and there isn't necessarily one single optimal design 🧩

3. Considerations 🌸

okay now for the good stuff ✨ The next sections cover the specific considerations (C1-C6) for conclusions drawn in academic papers about large authoritative DNS server operators. These considerations come from academic work that authoritative server operators might want to think about in order to improve their DNS service 💜 Each one offers different improvements that can affect things like service latency, routing, anycast deployment, and defensive strategies, for example 🦋

3.1. C1: Deploy Anycast in Every Authoritative Server to Enhance Distribution and Latency 💖

3.1.1. Research Background ✨

okay so authoritative DNS server operators announce their service using NS records [RFC1034]. every authoritative server for a zone is supposed to return the same content, and they usually stay in sync with DNS zone transfers (authoritative transfer (AXFR) [RFC5936] and incremental zone transfer (IXFR) [RFC1995]) so they're all giving clients the same zone data 🫶

as we said above, the DNS really relies on replication for high reliability, capacity, and low latency [Moura16b] 💖 there are two complementary replication mechanisms: name server replication (multiple NS records) and anycast (multiple physical locations). name server replication is strongly recommended for all zones (multiple NS records), and IP anycast is used by many bigger zones like the DNS root [AnyFRoot], most top-level domains [Moura16b], and a bunch of large commercial enterprises, governments, and other organizations 🌸

most DNS operators are obsessed with cutting service latency for users, and both of these replication techniques hugely affect that 😭 but here's the thing: operators only control their own authoritative servers, not the client's recursive resolvers. so it's hard to make sure recursives get served by the closest authoritative server 🙈 server selection is up to the recursive resolver's software, and different vendors (and even different releases!) use different criteria to pick which authoritative servers to talk to.

understanding how recursive resolvers choose authoritative servers is a key step toward better authoritative deployments 🧚 to measure this, [Mueller17b] describes deploying seven unicast authoritative name servers in different global locations, then querying them from more than 9000 Reseaux IP Europeens (RIPE) authoritative server operators and their respective recursive resolvers.

[Mueller17b] found that recursive resolvers in the wild query all available authoritative servers, regardless of observed latency. but the queries are lowkey skewed toward the authoritatives with lower latency: the lower the latency between a recursive resolver and an authoritative server, the more often the recursive sends queries to that server 👑 these results came from aggregating all of the vantage points, and they weren't specific to any vendor or version.

the authors think this behavior comes from combining the two main criteria resolvers use when picking authoritative servers: resolvers regularly check all listed authoritative servers in an NS set to see which is closer (the least latent), and when one isn't available, they pick one of the alternatives. it's giving strategy 🧠

3.1.2. Resulting Considerations

okay so for an authoritative DNS operator, this means the latency of all authoritative servers (NS records) matters, so they all must be similarly capable, because most recursive resolvers will query all available authoritatives 💅 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, just because of 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 its usage of unicast and deploy a 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 🦋

the contribution of [Mueller17b] to DNS service engineering shows that because unicast can't deliver good latency worldwide, anycast needs to be used to provide a low-latency service worldwide. main character energy for anycast, honestly 👑

3.2. C2: Optimizing Routing is More Important than Location Count and Diversity 🗺️

3.2.1. Research Background

when you're picking an anycast DNS provider or setting up an anycast service, choosing the best number of anycast instances [RFC4786] [RFC7094] to deploy is a tough problem 😩 picking the right quantity and set of global locations to send BGP announcements from is tricky too. you'd naively think more instances are better and that simply "more" will always mean shorter response times.

this is not necessarily true, though! 🙅‍♀️ proper route engineering can matter more than the total number of locations, as found in [Schmidt17a]. to study how the number of anycast instances relates to service performance, the authors measured the round-trip time (RTT) latency of four DNS root servers. the root DNS servers are run by 12 separate organizations serving the DNS root zone at 13 different IPv4/IPv6 address pairs.

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

in [Schmidt17a], the authors found that the C server, a smaller anycast deployment of only 8 instances, gave very similar overall performance compared to the much larger deployments of K and L, which have 33 and 144 instances, respectively. the median RTTs for the C, K, and L root servers were all between 30-32 ms. not even close to the instance count gap, lol 🤷‍♀️

because RIPE Atlas has better coverage in Europe than other regions, the authors specifically analyzed the results per region and per country (Figure 5 in [Schmidt17a]). they show that the known Atlas bias toward Europe doesn't change the conclusion that properly selected anycast locations matter more to latency than the number of sites 💜

3.2.2. Resulting Considerations

the big takeaway from [Schmidt17a] is that when you're 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 ✨ the authors showed that 12 instances can provide reasonable latency, assuming they're globally distributed and have good local interconnectivity.

that said, additional instances can still be useful for other reasons, such as handling DoS attacks [Moura16b]. so more instances aren't useless, just not the magic fix people think 🛡️

3.3. C3: Collect Anycast Catchment Maps to Improve Design 🗺️

3.3.1. Research Background

an anycast DNS service can be deployed from anywhere, from a few locations up to hundreds (for example, l.root-servers.net has over 150 anycast instances at the time this was written). anycast leans on Internet routing to send incoming queries to a service's nearest distributed anycast locations, measured by the number of routing hops. but queries are usually not evenly distributed across all the anycast locations, as found in the case of L-Root when analyzed using Hedgehog [IcannHedgehog] 😬

adding or removing locations from a deployed anycast network changes the load distribution across all of its locations. when a new location gets announced by BGP, locations may get more or less traffic than they were engineered for. that can lead to suboptimal performance, or even stressing some locations while leaving others underutilized 💀 operators deal with this every time they expand an anycast service, and they can't easily estimate future query distributions based on proposed anycast network engineering decisions.

to address this and estimate the query loads of an anycast service that's undergoing changes (especially expansion), [Vries17b] describes a new technique that lets operators run active 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 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 time of writing, Verfploeter still doesn't support IPv6, because the IPv4 hit lists used are generated via frequent large-scale ICMP echo scans, which isn't possible with IPv6 🙃

as proof of concept, [Vries17b] documents how 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 address to each IPv4 /24 network routing block on the Internet 🌐

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

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

3.3.2. Resulting Considerations

an important operational takeaway from [Vries17b] is how DNS operators can make informed engineering choices when changing DNS anycast network deployments, by using Verfploeter in advance 🧠 operators can identify suboptimal routing situations ahead of time, with significantly better coverage than other active measurement platforms such as RIPE Atlas.

to date, Verfploeter has been deployed on an operational testbed (anycast testbed) [AnyTest] at a large unnamed operator, and it's run daily at b.root-servers.net [Vries17b] 🫶

operators should use active measurement techniques like Verfploeter in advance of potential anycast network changes, so they can accurately measure the benefits and potential issues ahead of time. measure first, slay later 💅

3.4. C4: Employ Two Strategies When under Stress 🧯

3.4.1. Research Background ✨

okay so DDoS attacks are getting bigger, cheaper, and more frequent 😭 [Moura16b] has the receipts. The biggest one recorded against DNS servers so far hit 1.2 Tbps using Internet of Things (IoT) devices [Perlroth16]. So the big question is: how should a DNS operator set up an anycast authoritative DNS server so it can actually survive an attack like that? 🛡️ [Moura16b] digs into this with real-world observations plus theory-based option evaluations 🧠

An authoritative DNS server deployed with anycast has lots of server instances spread across lots of networks 🌐 Ultimately, the relationship between the DNS provider's network and a client's ISP decides which anycast instance answers a given client's queries, since BGP maps clients to specific anycast instances using routing information 🗺️ So when an anycast authoritative server is under attack, the load on each instance is probably uneven (it depends on where the attacks are coming from), which means some instances end up more overloaded than others. That's exactly what [Moura16b] saw when it looked at the root DNS events of November 2015 👀 And since instances can have different capacities (bandwidth, CPU, etc.), deciding how to react to stress gets even harder 😩

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 tricks (such as reducing route announcement propagation using BGP communities [RFC1997]), or communicate with its upstream network providers to apply filtering (potentially using FlowSpec [RFC8955] or the DDoS Open Threat Signaling (DOTS) protocol [RFC8811] [RFC9132] [RFC8783]). These techniques shift both legitimate and attack traffic to other anycast instances (with hopefully greater capacity) or block traffic entirely 🔀
  • Alternatively, operators can become degraded absorbers by continuing to operate, knowing that dropping incoming legitimate requests due to queue overflow is part of the deal. However, this approach will also absorb attack traffic directed toward its catchment, hopefully protecting the other anycast instances 🥊

[Moura16b] describes seeing both of these behaviors in practice when studying instance reachability and RTTs in the DNS root events. When withdraw strategies were deployed, the stress of increased query loads got displaced from one instance to multiple other sites 🌪️ In other observed events, one site was left to absorb the brunt of the attack, leaving the other sites relatively less affected 💅

3.4.2. Resulting Considerations ✨

Operators should consider having both an anycast site withdraw strategy and an absorption strategy ready to go before a network overload occurs. Operators should be able to deploy one or both of these strategies rapidly. Ideally, these get 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 common filtering approaches and other routing load-balancing techniques (such as withdrawing routes, prepending Autonomous Systems (ASes), adding communities, or isolating instances), where the best choice depends on the specifics of the attack. It's giving strategy 🎯

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 one authoritative service point to another when attempting to resolve a name [Mueller17b] 🔁

3.5. C5: Consider Longer Time-to-Live Values Whenever Possible 🕰️

3.5.1. Research 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 to a cached entry is far faster ⚡ 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 records directly control cache durations and affect latency, resilience, and the role of DNS in Content Delivery Network (CDN) server selection. Some early work modeled caches as a function of their TTLs [Jung03a], and recent work has examined cache interactions with DNS [Moura18b]. But until [Moura19b], no research had provided considerations about the benefits of various TTL value choices 🙈 To study this, Moura 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 may want to choose longer or shorter TTLs:

  • Longer TTLs, as discussed, lead to a longer cache life, resulting in faster responses. In [Moura19b], this was measured in the wild, and it showed that by increasing the TTL for the .uy TLD from 5 minutes (300 s) to 1 day (86,400 s), the latency measured from 15,000 Atlas vantage points changed significantly: the median RTT decreased from 28.7 ms to 8 ms, and the 75th percentile decreased from 183 ms to 21 ms 📈
  • Longer caching times also result in lower DNS traffic: authoritative servers will experience less traffic with extended TTLs, as repeated queries are answered by resolver caches 😴
  • Longer caching consequently results in a lower overall cost if the DNS is metered: some providers that offer DNS as a Service charge a per-query (metered) cost (often in addition to a fixed monthly cost) 💸
  • Longer caching is more robust to DDoS attacks on DNS infrastructure. DNS caching was also measured in [Moura18b], and it showed that the effects of a DDoS on DNS can be greatly reduced, provided that the caches last longer than the attack 🏰
  • Shorter caching, however, supports deployments that may require rapid operational changes: 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 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 ✨

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 and ideally 4, 8, or 24 hours. Assuming planned maintenance can be scheduled at least a day in advance, long TTLs have little cost and may even literally provide cost savings 🤑
  • For TLD and other public registration operators (for example, most ccTLDs and .com, .net, and .org) that host many delegations (NS records, DS records, and "glue" records), [Moura19b] demonstrates that most resolvers will use the TTL values provided by the child delegations, while 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 that provide more agility and using longer TTLs that include all the benefits listed above 🥊
  • Regarding the use of A/AAAA and NS records, the TTLs for A/AAAA records should be shorter 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 when glue is required to be sent by the parents. For out-of-bailiwick servers, A, 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 services are required 💜

3.6. C6: Consider the Difference in Parent and Children's TTL Values 🧚

3.6.1. Research Background

okay so this one is about the TTL drama between parents and kids in DNS 💅🌸 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 honestly they often are not 🙈), and the same goes for the IP addresses in "glue" A/AAAA records that must exist for in-bailiwick authoritative servers. Plus, if DNSSEC [RFC4033] [RFC4034] [RFC4035] [RFC4509] is deployed for a zone, the parent's DS record MUST cryptographically refer to a child's DNSKEY record. ✨

Wait, I need to be precise about that last one, because it's a spec requirement and I'm not going to flatten it. In the original, the DS requirement is phrased in plain prose, not as a BCP 14 key word, so I'm keeping it as a plain statement and not inventing capitals. The sentence reads: the parent's DS record must cryptographically refer to a child's DNSKEY record.

Now here's the vibe. Because some information lives in both the parent and the child, the TTL values can be different between the parent's copy and the child's copy. [Moura19b] looked at how resolvers behave when these values differed in the wild, and they frequently do 😭 Often, parent zones have 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 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 name server. RIPE Atlas nodes were used to determine what resolvers in the wild do with different information, and whether the parent's TTL is used for cache lifetimes ("parent-centric") or the child's ("child-centric"). 🦋

Here's the tea ☕ [Moura19b] found that roughly 90% of resolvers follow the child's view of the TTL, while 10% appear parent-centric. It also found that resolvers behave differently for cache lifetimes for in-bailiwick vs. out-of-bailiwick NS/A/AAAA TTL combinations. Specifically, when NS TTLs are shorter than the corresponding address records, most resolvers will 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 the NS record expires first, resolvers will honor the original cache time of the name server's address. 💜

3.6.2. Resulting 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, so it's not just your own numbers that matter. 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. Bestie, that's a big deal for migrations 🧚

4. Security 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 impacts. Security is serious business, so let's get into it 🔥

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 TTL values. 👑

5. Privacy Considerations

This document does not add any new, practical 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 client-to-resolver and resolver-to-authoritative cases. Honestly, that's a glow-up for privacy too 🌈

6. IANA Considerations

This document has no IANA actions. Nothing to register here, bestie 🎀

7. References

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

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

[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 ✨

Okay bestie, now for the bibliography 📚 These are the extra reads that back up all the research in this doc. None of them are required to implement anything, but they're absolutely worth a look if you want the receipts 💅

Acknowledgements 🫶

Huge thank-you to the reviewers 🌸 who gave super valuable suggestions and comments at the IETF DNSOP session (IETF 104): Duane Wessels, Joe Abley, Toema Gavrichenkov, John Levine, Michael StJohns, Kristof Tuyteleers, Stefan Ubbink, Klaus Darilion, and Samir Jafferali. You're all iconic 👑

We also want to thank everyone acknowledged in the papers this doc summarizes for helping produce the results 🙌 That includes RIPE NCC and DNS OARC for their tools and datasets used in this research, plus the funding agencies that sponsored the individual research. Literally couldn't have done it without y'all 💜

Contributors 💖

This document is a summary of the main considerations of six research papers written by the authors, plus the following people who contributed substantially to the content and should be considered coauthors. It 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 🧚

Here's where to find the people behind the research 💌 Contact details are copied exactly as they appear in the document.

Giovane C. M. Moura

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

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

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

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