Network Working Group V. Pappas, Ed.
Internet-Draft IBM
Intended status: Standards Track E. Osterweil, Ed.
Expires: August 26, 2012 Verisign
February 23, 2012
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 26, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Pappas & Osterweil Expires August 26, 2012 [Page 1]
Internet-Draft Improving DNS Service Availability February 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Operational Issues . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Cache Coherency . . . . . . . . . . . . . . . . . . . . . 9
3.2. Routine Cache Maintenance Issues . . . . . . . . . . . . . 10
3.3. Implementation Issues . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Measurements . . . . . . . . . . . . . . . . . . . . 15
A.1. Frequency of Infra-RR Changes . . . . . . . . . . . . . . 15
A.2. Effectiveness of Long TTL Values . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Pappas & Osterweil Expires August 26, 2012 [Page 2]
Internet-Draft Improving DNS Service Availability February 2012
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
Pappas & Osterweil Expires August 26, 2012 [Page 3]
Internet-Draft Improving DNS Service Availability February 2012
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.
Pappas & Osterweil Expires August 26, 2012 [Page 4]
Internet-Draft Improving DNS Service Availability February 2012
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].
Pappas & Osterweil Expires August 26, 2012 [Page 5]
Internet-Draft Improving DNS Service Availability February 2012
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 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.
Pappas & Osterweil Expires August 26, 2012 [Page 6]
Internet-Draft Improving DNS Service Availability February 2012
2.1. Examples
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:
$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
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:
$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
Finally the following example shows the configuration for a DNSSEC
enabled zone (zone2.example.):
Pappas & Osterweil Expires August 26, 2012 [Page 7]
Internet-Draft Improving DNS Service Availability February 2012
$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 ...
Pappas & Osterweil Expires August 26, 2012 [Page 8]
Internet-Draft Improving DNS Service Availability February 2012
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 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.
Pappas & Osterweil Expires August 26, 2012 [Page 9]
Internet-Draft Improving DNS Service Availability February 2012
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.
Pappas & Osterweil Expires August 26, 2012 [Page 10]
Internet-Draft Improving DNS Service Availability February 2012
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.
Pappas & Osterweil Expires August 26, 2012 [Page 11]
Internet-Draft Improving DNS Service Availability February 2012
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
Pappas & Osterweil Expires August 26, 2012 [Page 12]
Internet-Draft Improving DNS Service Availability February 2012
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.
Pappas & Osterweil Expires August 26, 2012 [Page 13]
Internet-Draft Improving DNS Service Availability February 2012
7. References
7.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
July 1997.
[RFC3258] Hardie, T., "Distributing Authoritative Name Servers via
Shared Unicast Addresses", RFC 3258, April 2002.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
7.2. Informative References
[HOT05DNS]
Handley, M. and A. Greenhalgh, "The Case for Pushing DNS",
HotNets, 2005.
[IMW01CACHE]
Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS
Performance and the Effectiveness of Caching", IMW, 2001.
[SIG88DNS]
Mockapetris, P. and K. Dunlap, "Development of the Domain
Name System", SIGCOMM, 1988.
Pappas & Osterweil Expires August 26, 2012 [Page 14]
Internet-Draft Improving DNS Service Availability February 2012
Appendix A. Measurements
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.
A.2. Effectiveness of Long TTL Values
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:
Pappas & Osterweil Expires August 26, 2012 [Page 15]
Internet-Draft Improving DNS Service Availability February 2012
---------------------------------------------------------------------
| || 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% |
---------------------------------------------------------------------
Clearly, we see that by using a longer TTL value we can increase the
overall system availability under denial of service attacks. The
table shows that with a TTL value of seven days we can decrease the
impact of such an attack at the root and TLD servers by 70%,
independent of the attack duration. Also the table shows that by
increasing the TTL value, we are more resilient to attacks. Based on
these results we believe that a TTL value of seven days is adequate
enough to considerably improve the resilience of the DNS system
against denial of service attacks.
Pappas & Osterweil Expires August 26, 2012 [Page 16]
Internet-Draft Improving DNS Service Availability February 2012
Authors' Addresses
Vasileios Pappas (editor)
IBM Research, Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532
US
Email: vpappas@us.ibm.com
Eric Osterweil (editor)
Verisign, Inc.
12061 Bluemont Way
Reston, VA 20190
US
Email: eosterweil@verisign.com
Pappas & Osterweil Expires August 26, 2012 [Page 17]