Improving DNS Service Availability by Using Long TTL Values
draft-pappas-dnsop-long-ttl-04.txt

Abstract

Due to the hierarchical tree structure of the Domain Name System [RFC1034][RFC1035], losing all of the authoritative servers that serve a zone can disrupt services to not only that zone but all of its descendants. This problem is particularly severe if all the authoritative servers of the root zone, or of a top level domain's zone, fail. Although proper placement of secondary servers, as discussed in [RFC2182], can be an effective means against isolated failures, it is insufficient to protect the DNS service against a Distributed Denial of Service (DDoS) attack. This document proposes to reduce the impact of DDoS attacks against top level DNS servers by setting long TTL values for NS records and their associated A and AAAA records. Our proposed changes are purely operational and can be deployed incrementally.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 http://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 August 02, 2012.

Copyright Notice

Copyright (c) 2012 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 (http://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
• 1.1. Terminology
• 1.2. Conventions
• 2. Recommendations
• 2.1. Examples
• 3. Operational Issues
• 3.1. Cache Coherency
• 3.2. Routine Cache Maintenance Issues
• 3.3. Implementation Issues
• 4. Security Considerations
• 5. Contributing Authors
• 6. Acknowledgments
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Appendix A. Measurements
• Appendix A.1. Frequency of Infra-RR Changes
• Appendix A.2. Effectiveness of Long TTL Values
• Authors' Addresses

1. Introduction

[RFC2182] provides operational guidelines for selecting and operating authoritative servers to maximize a zone's availability. Proper placement of authoritative servers can be an effective means to guard DNS service against unintentional failures or errors, but it is not well suited to protect DNS services against intentional attacks (like Distributed Denial of Service attacks). A Distributed Denial of Service (DDoS) attack could target all of the authoritative servers for a zone, regardless of where they are placed. By disabling all of a zone's authoritative servers, an attacker can disrupt service for that zone and all the zones below it. In particular, attacks against domains such as the root, generic Top Level Domains (gTLDs), country code Top Level Domains (ccTLDs), and other zones serving popular DNS domains (such as .co.uk or .co.jp) could have a severe global impact. For example, knocking out all of the root zone servers may effectively render the entire Internet unreachable. Successful attacks against all authoritative servers for a large generic top level domain (gTLD) such as ".com" can also impact availability for over one hundred million DNS zones.

Currently, some of the root and gTLD and ccTLDs servers use shared unicast addresses [RFC3258] to improve availability during denial of service attacks. This approach can be effective only when the number of replicated servers is large and when they are placed in diverse geographic locations. However the interactions between shared unicast addresses and BGP routing dynamics are still not fully understood. Furthermore, the use of shared unicast introduces one entry in the global BGP routing for every shared unicast enabled server. Therefore, using a shared unicast address is a solution that can not be applied easily for every DNS zone. In this document we propose an alternative and simpler approach for improving availability in the face of denial of service attacks, by recommending longer TTL values for certain DNS resource records (RRs). However, in contrast to shared unicast our recommendation does not protect the attacked zone, but rather all the child zones under the attacked zone.

This document proposes a recommendation based on the observation that DNS caching can effectively help mitigate the impact of denial of service attacks. A caching resolver only consults an authoritative server if the requested data is not already present in the cache. The cache contains both specific records such as www.example.com and infrastructure records such as the name servers for example.com. In this document, we focus primarily on the caching of infrastructure records (defined formally in the next section) and show how setting long TTL values on these records can help mitigate the impact of DDoS attacks. For example, consider the case of a successful attack against all of the DNS root servers and suppose all root servers are unavailable for some time period P. Despite the attack, resolvers can still access commonly used gTLDs and ccTLDs as long as the root's NS records and their corresponding A/AAAA resource record sets (RRsets) remain in a locally available cache during the period P. Generally speaking, access to the root servers is only used for looking up top level domain entries that are not presently available in the cache. Similar arguments apply to attacks against servers of other top level domains, or any DNS domain for that matter. If the NS and associated A/AAAA RRsets for a domain are cached, an attack against higher level domains will have little or no impact on descendant domains. When DNSSEC is used, additional RRsets must also be cached in order to weather the attack.

1.1. Terminology

We use the DNS terminology introduced in [RFC1034], [RFC1035], [SIG88DNS], [RFC2181] and [RFC4034]. Furthermore, this section introduces some additional terminology used in this draft:

Application Layer Resource Records (AL-RRs): The set of RRs that can potentially be queried by a stub-resolver. In other words RRs that are used by end-host applications. These records include almost all types of RRs, such as A, AAAA, MX, CNAME, SRV, etc.

Infrastructure Resource Records (Infra-RRs): The set of RRs that are used only in order to (securely) resolve a zone. NS and DS RRs are by definition Infra-RRs. The A and AAAA RRs are Infra-RRs if and only if the name associated with the A or AAAA RR exactly matches a name in the data portion of some NS RR. An NSEC RR is an Infra-RR if and only if its owner name is a delegation. A DNSKEY RR is an Infra-RR if and only if it matches a DS RR or is configured as a trust anchor in some resolver. An RRSIG RR is an Infra-RR if and only if it signs an infrastructure RRset. All other resource records defined at the time of this draft are Application Layer resource records.

Parent Zone (PZ): The zone defined right above the referenced zone.

Child Zone (CZ): A zone defined right below the referenced zone.

Authoritative Copy (AC): Some RRs (or RRsets) are defined in more than one zone. For example the NS RRset for a zone is defined both at the zone and at its parent zone. [RFC2181] describes how caches determine which copy of an RRset is most trustworthy and authoritative.

1.2. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Recommendations

Based on the measured TTL values of RRs [IMW01CACHE], data and infrastructure RRs are treated almost equally when setting their TTL values. Measurements show that the TTL values of infrastructure RRs (Infra-RRs), NS RRsets specifically, range from as short as 0 seconds (!) to as long as one week, with most TTLs set to 12 or less hours. Similarly, TTL values for Application Layer RRs (AL-RRs) exhibit similar value variations, with a smaller mean value though. These measurement results suggest that many DNS operators do not distinguish the semantic difference between Infra-RRs and AL-RRs when setting their TTL values.

In this draft we argue that Infra-RRs and AL-RRs SHOULD be treated differently when setting their TTL values. The main rationale is the following: Infra-RRs are mainly used by the DNS system itself and as such tend to be relatively stable records, while AL-RRs are primarily used by applications and thus tend to be more dynamic. As such, Infra-RRs can afford to have longer TTL values. More specifically we propose that Infra-RRs SHOULD have longer TTL values than those observed (12 or less hours), and we recommend that their TTL value SHOULD be in the order of days. This specific value recommendation is based on a measurement study (Appendix Appendix A.2), which shows that TTL values of 3 to 7 days can considerably improve the overall availability of the DNS system when faced with denial of service attacks.

We recommend this range of TTL values both for the authoritative copy of the Infra-RRs, as well as for the copy of the Infra-RRs stored at the parent zone. These TTL values SHOULD be applied for both copies of Infra-RRs for the following reasons: A) If they are applied only at the parent's copy, then a resolver will always replace the parent's copy with the authoritative copy (lower TTL values), whenever it receives a reply that contains or attaches the authoritative copy. B) If they are applied only at the authoritative copy, then it is possible that a resolver will only use the parent's copy. For example most resolvers cache the NS RRs of most TLDs from replies that usually come from the root zone. These RRs are rarely replaced by their authoritative copy, given that TLDs usually reply with referrals for their child zones (and thus they do not attach their own NS records in these replies). In addition, some name server implementations offer a configuration option called "minimal responses." When this option is enabled, name servers will omit the ADDITIONAL section of DNS responses, and thus not include glue records.

2.1. Examples

     $example.
     zone1.example.        432000  NS  a.zone1.example.
     zone1.example.        432000  NS  b.zone1.example.
     a.zone1.example.      432000  A  10.1.0.1
     b.zone1.example.      432000  A  10.1.0.2

     $zone1.example.
     zone1.example.        432000  NS  a.zone1.example.
     zone1.example.        432000  NS  b.zone1.example.
     a.zone1.example.      432000  A  10.1.0.1
     b.zone1.example.      432000  A  10.1.0.2
     

In this section we provide, some example configurations for setting the TTL value of Infra-RRs. The first example shows the configuration of a zone (zone1.example.) when all its NS records have names that belong to the same branch of the DNS tree:

     $zone1.example.
     sub1.zone1.example.  432000  NS  a.sub1.zone1.example.
     sub1.zone1.example.  432000  NS  b.sub2.zone2.example.
     a.sub1.zone1.example.  432000  A  10.1.1.1

     $sub1.zone1.example.
     sub1.zone1.example.  432000  NS  a.sub1.zone1.example.
     sub1.zone1.example.  432000  NS  b.sub2.zone2.example.
     a.sub1.zone1.example.  432000  A  10.1.1.1

     $sub2.zone2.example.
     b.sub2.zone2.example.  432000  A  10.2.2.2
     

The following example shows the configuration of a zone (sub1.zone1.example.), when one of its servers has a name that belongs to a different branch of the DNS tree:

     $example.
     zone2.example.    432000  NS  a.zone2.example.
     zone2.example.    432000  NS  b.zone2.example.
     zone2.example.    432000  DS  ...
     zone2.example.    432000  RRSIG  ...
     zone2.example.    432000  NSEC  ...

     $zone2.example.
     zone2.example.    432000  NS  a.zone2.example.
     zone2.example.    432000  NS  b.zone2.example.
     zone2.example.    432000  RRSIG  ...
     zone2.example.    432000  DNSKEY  ...
     zone2.example.    432000  RRSIG  ...
     zone2.example.    432000  NSEC  ...  
     

Finally the following example shows the configuration for a DNSSEC enabled zone (zone2.example.):

3. Operational Issues

3.1. Cache Coherency

Increasing the TTL value of Infra-RRs can cause some cached Infra-RRs to be inconsistent with the Infra-RRs provided by the authoritative servers for longer periods of time, when these Infra-RRs change. We believe this cache coherency problem is not an issue for most cases, for the following reasons: First, Infra-RRs tend to be relatively stable records (Appendix Appendix A.1, [HOT05DNS]), and thus this inconsistency issue is expected to be a rare event. Second, Infra-RRs inconsistencies for all records except NS and the associated A/AAAA RRs can be easily identified and corrected by a resolver (by querying the authoritative zone for these RRs).

Perhaps the most worrisome case occurs when there are inconsistencies between NS Infra-RRs and their corresponding A/AAAA Infra-RRs. In such a case, resolvers are still able to correct inconsistencies as long as the NS and A/AAAA RRs have not changed for at least one name server. That is, as long as there is at least one of the former NS+A/AAAA mappings that corresponds to a reachable name server, the resolver will eventually contact this server and will be able to replace the new NS and A/AAAA Infra-RRs (assuming that these records are attached in the reply). In the case that all NS and A/AAAA Infra-RRs have changed then the resolver may or may not be able to overcome Infra-RR inconsistency. This depends on the resolvers implementation. Some resolvers tend to contact the parent zone in such a case (and thus correct the inconsistency), while others return an error code (and thus stay inconsistent until the RRs expire).

Given that different implementations behave differently in the case where all NS and A/AAAA Infra-RRs change at the same time, we recommend the following for zones that implement longer TTL values for Infra-RRs. The zone administrator SHOULD gradually move to the new Infra-RRs, by incrementally changing the NS and A/AAAA RRs (not all of them at once), or she/he SHOULD maintain that availability of the old set of servers (which have been removed from the zone) until all the old Infra-RRs have expired from the caches of any possible resolver. This can be ensured by keeping servers available for at least an interval equal to the former Infra-RRs TTL (plus some jitter).

Another approach that an operator MAY follow is to gradually reduce the TTL value of Infra-RRs before the change, and restore the longer TTL values after the change. Clearly a zone administrator MAY follow any of the above strategies when changing the NS and A/AAAA records to a completely different set.

3.2. Routine Cache Maintenance Issues

A subtle issue may arise in cases where DNS operators manually (or periodically) manage their caches' state. For example, some operators may (as a matter of operational prudence) periodically flush their resolvers' caches. If, for example, an operator flushes his/her caches every day, then the long TTLs on Infra-RRs would not benefit them for any period longer than his/her own inter-flush period. That is, if caches get flushed every 24 hours, then any TTL longer than 24 hours would effectively be truncated. Thus, the operational tradeoffs that prompt this sort of practice may need to be reconsidered in the face of DDoS threats.

3.3. Implementation Issues

This document does not require or recommend any implementation changes of either the authoritative server software or the resolver software. On the other hand, we should point out that some changes may be beneficial when zones implement longer TTL values for Infra-RRs.

4. Security Considerations

This document prescribes an operational practice that facilitates DNS queries during prolonged outages. Such outages may result from extended DDoS attacks against key servers in the DNS. The use of long TTL values does not reduce the attack surface of targeted servers to DDoS attacks. However, the use of long TTL values extends the amount of time a DDoS attack must be waged before it impacts an entire DNS subtree, and directly affects the effectiveness of a DDoS to the global DNS. While a DDoS may disrupt the availability of some critical authoritative servers, the NS records for the zones that are delegated by them will be available in remote caches for much longer. The extended buffer between the start of a DDoS and related outages from its effects provides a greater window for operators (DNS, routing, etc.) to collaborate and mitigate it before its effects become crippling. Therefore, while a DDoS is no less likely, the operational window for remediating its effects can be dramatically enhanced.

5. Contributing Authors

The editors wish to express that the thoughts, opinions, text, and work of this document are due to the following set of authors:

Vasileios Pappas
IBM Research, Watson Research Center
vpappas@us.ibm.com

Eric Osterweil
Verisign, Inc.
eosterweil@verisign.com

Danny McPherson
Verisign, Inc.
dmcpherson@tcb.net

Duane Wessels
Verisign, Inc.
dwessels@verisign.com

Matt Larson
Verisign, Inc.
mlarson@verisign.com

Dan Massey
Colorado State University,
massey@cs.colostate.edu

Lixia Zhang
University of California, Los Angeles
lixia@cs.ucla.edu

6. Acknowledgments

We would like to express our thanks to Greg Minshall for an early discussion on the feasibility of using long TTLs to improve DNS availability, to Pete Resnick for his support and the suggestion of using one week or even longer TTL values, and to Rob Austin and Patrik Faltstrom who also provided constructive comments to our proposal.

7. References

7.1. Normative References

7.2. Informative References

Appendix A. Measurements

Appendix A.1. Frequency of Infra-RR Changes

To assess the stability of deployed DNS servers, we conducted a measurement study. From a crawl over 15 million DNS zones (the crawl was initiated at DMOZ.ORG), we randomly selected 100,000 zones and measured their infrastructure RRsets over a 4-month period.

During this 4-month period we queried each of the 100,000 zones twice a day to obtain its infrastructure RRset. Our data shows that 75% of the measured zones did not change either the NS or corresponding A RRsets during the entire study period. 11% of the zones showed changes to their NS RRset during this 4-month period, and 5% of the zones made the changes in less than 2 months. The A records of all the measured zone servers had more changes than the NS RRsets: 22% of the zones had their servers' A records changed within 4 months, and 10% of the zones made servers' A record changes in less than 2 months. All in all, our measurement results show that the DNS servers, in the majority of the zones, are very stable. Even those servers that made changes during our measurement period show that their DNS server changes are rather infrequent.

Appendix A.2. Effectiveness of Long TTL Values

---------------------------------------------------------------------
|     ||                 Attack Duration (Hours)                    |
---------------------------------------------------------------------
|     ||      3       |       6      |      12      |       24      |
| TTL ||-------------------------------------------------------------
|(day)|| 7776 Queries | 13799 Queries| 23586 Queries| 53636 Queries |
|--------------------------------------------------------------------
|  -  || 2227 - 28.6% | 3829 - 27.7% | 6807 - 28.8% | 17099 - 31.8% |
|  3  || 1132 - 14.5% | 1884 - 13.6% | 3154 - 13.3% |  7218 - 13.4% |
|  5  ||  917 - 11.7% | 1530 - 11.0% | 2562 - 10.8% |  5947 - 11.0% |
|  7  ||  767 -  9.8% | 1256 -  9.1% | 2092 -  8.8% |  4766 -  8.8% |
|  9  ||  711 -  9.1% | 1165 -  8.4% | 1898 -  8.0% |  4157 -  7.7% |
---------------------------------------------------------------------
      

In order to gauge the effectiveness of a longer TTL value for the DNS infrastructure records, we used a real DNS trace that was captured by a UCLA caching server for 2 weeks. Based on this trace, we simulated a DoS attack on all root and TLD servers and we measured the percentage of queries that weren't resolved (excluding negative answers from the root and TLD zones), in the case of measured TTL values, and in the case of a hypothetical TTL value of 3, 5, 7, and 9 days for all zones. The attack duration was 3, 6, 12 and 24 hours, and started at the eighth day (in simulation time). The following table shows the absolute number as well as the percentage of the queries that did not resolve for each case of attack duration and TTL value:

Authors' Addresses