idnits 2.17.1 draft-pappas-dnsop-long-ttl-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC1034], [RFC1035], [RFC2182]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2012) is 4446 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3258 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Pappas, Ed. 3 Internet-Draft IBM 4 Intended status: Standards Track E. Osterweil, Ed. 5 Expires: August 26, 2012 Verisign 6 February 23, 2012 8 Improving DNS Service Availability by Using Long TTL Values 9 draft-pappas-dnsop-long-ttl-04.txt 11 Abstract 13 Due to the hierarchical tree structure of the Domain Name System 14 [RFC1034][RFC1035], losing all of the authoritative servers that 15 serve a zone can disrupt services to not only that zone but all of 16 its descendants. This problem is particularly severe if all the 17 authoritative servers of the root zone, or of a top level domain's 18 zone, fail. Although proper placement of secondary servers, as 19 discussed in [RFC2182], can be an effective means against isolated 20 failures, it is insufficient to protect the DNS service against a 21 Distributed Denial of Service (DDoS) attack. This document proposes 22 to reduce the impact of DDoS attacks against top level DNS servers by 23 setting long TTL values for NS records and their associated A and 24 AAAA records. Our proposed changes are purely operational and can be 25 deployed incrementally. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 26, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 64 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3. Operational Issues . . . . . . . . . . . . . . . . . . . . . . 9 67 3.1. Cache Coherency . . . . . . . . . . . . . . . . . . . . . 9 68 3.2. Routine Cache Maintenance Issues . . . . . . . . . . . . . 10 69 3.3. Implementation Issues . . . . . . . . . . . . . . . . . . 10 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 5. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 12 72 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 76 Appendix A. Measurements . . . . . . . . . . . . . . . . . . . . 15 77 A.1. Frequency of Infra-RR Changes . . . . . . . . . . . . . . 15 78 A.2. Effectiveness of Long TTL Values . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 81 1. Introduction 83 [RFC2182] provides operational guidelines for selecting and operating 84 authoritative servers to maximize a zone's availability. Proper 85 placement of authoritative servers can be an effective means to guard 86 DNS service against unintentional failures or errors, but it is not 87 well suited to protect DNS services against intentional attacks (like 88 Distributed Denial of Service attacks). A Distributed Denial of 89 Service (DDoS) attack could target all of the authoritative servers 90 for a zone, regardless of where they are placed. By disabling all of 91 a zone's authoritative servers, an attacker can disrupt service for 92 that zone and all the zones below it. In particular, attacks against 93 domains such as the root, generic Top Level Domains (gTLDs), country 94 code Top Level Domains (ccTLDs), and other zones serving popular DNS 95 domains (such as .co.uk or .co.jp) could have a severe global impact. 96 For example, knocking out all of the root zone servers may 97 effectively render the entire Internet unreachable. Successful 98 attacks against all authoritative servers for a large generic top 99 level domain (gTLD) such as ".com" can also impact availability for 100 over one hundred million DNS zones. 102 Currently, some of the root and gTLD and ccTLDs servers use shared 103 unicast addresses [RFC3258] to improve availability during denial of 104 service attacks. This approach can be effective only when the number 105 of replicated servers is large and when they are placed in diverse 106 geographic locations. However the interactions between shared 107 unicast addresses and BGP routing dynamics are still not fully 108 understood. Furthermore, the use of shared unicast introduces one 109 entry in the global BGP routing for every shared unicast enabled 110 server. Therefore, using a shared unicast address is a solution that 111 can not be applied easily for every DNS zone. In this document we 112 propose an alternative and simpler approach for improving 113 availability in the face of denial of service attacks, by 114 recommending longer TTL values for certain DNS resource records 115 (RRs). However, in contrast to shared unicast our recommendation 116 does not protect the attacked zone, but rather all the child zones 117 under the attacked zone. 119 This document proposes a recommendation based on the observation that 120 DNS caching can effectively help mitigate the impact of denial of 121 service attacks. A caching resolver only consults an authoritative 122 server if the requested data is not already present in the cache. 123 The cache contains both specific records such as www.example.com and 124 infrastructure records such as the name servers for example.com. In 125 this document, we focus primarily on the caching of infrastructure 126 records (defined formally in the next section) and show how setting 127 long TTL values on these records can help mitigate the impact of DDoS 128 attacks. For example, consider the case of a successful attack 129 against all of the DNS root servers and suppose all root servers are 130 unavailable for some time period P. Despite the attack, resolvers can 131 still access commonly used gTLDs and ccTLDs as long as the root's NS 132 records and their corresponding A/AAAA resource record sets (RRsets) 133 remain in a locally available cache during the period P. Generally 134 speaking, access to the root servers is only used for looking up top 135 level domain entries that are not presently available in the cache. 136 Similar arguments apply to attacks against servers of other top level 137 domains, or any DNS domain for that matter. If the NS and associated 138 A/AAAA RRsets for a domain are cached, an attack against higher level 139 domains will have little or no impact on descendant domains. When 140 DNSSEC is used, additional RRsets must also be cached in order to 141 weather the attack. 143 1.1. Terminology 145 We use the DNS terminology introduced in [RFC1034], [RFC1035], 146 [SIG88DNS], [RFC2181] and [RFC4034]. Furthermore, this section 147 introduces some additional terminology used in this draft: 149 Application Layer Resource Records (AL-RRs): The set of RRs that can 150 potentially be queried by a stub-resolver. In other words RRs that 151 are used by end-host applications. These records include almost all 152 types of RRs, such as A, AAAA, MX, CNAME, SRV, etc. 154 Infrastructure Resource Records (Infra-RRs): The set of RRs that are 155 used only in order to (securely) resolve a zone. NS and DS RRs are 156 by definition Infra-RRs. The A and AAAA RRs are Infra-RRs if and 157 only if the name associated with the A or AAAA RR exactly matches a 158 name in the data portion of some NS RR. An NSEC RR is an Infra-RR if 159 and only if its owner name is a delegation. A DNSKEY RR is an 160 Infra-RR if and only if it matches a DS RR or is configured as a 161 trust anchor in some resolver. An RRSIG RR is an Infra-RR if and 162 only if it signs an infrastructure RRset. All other resource records 163 defined at the time of this draft are Application Layer resource 164 records. 166 Parent Zone (PZ): The zone defined right above the referenced zone. 168 Child Zone (CZ): A zone defined right below the referenced zone. 170 Authoritative Copy (AC): Some RRs (or RRsets) are defined in more 171 than one zone. For example the NS RRset for a zone is defined both 172 at the zone and at its parent zone. [RFC2181] describes how caches 173 determine which copy of an RRset is most trustworthy and 174 authoritative. 176 1.2. Conventions 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 2. Recommendations 184 Based on the measured TTL values of RRs [IMW01CACHE], data and 185 infrastructure RRs are treated almost equally when setting their TTL 186 values. Measurements show that the TTL values of infrastructure RRs 187 (Infra-RRs), NS RRsets specifically, range from as short as 0 seconds 188 (!) to as long as one week, with most TTLs set to 12 or less hours. 189 Similarly, TTL values for Application Layer RRs (AL-RRs) exhibit 190 similar value variations, with a smaller mean value though. These 191 measurement results suggest that many DNS operators do not 192 distinguish the semantic difference between Infra-RRs and AL-RRs when 193 setting their TTL values. 195 In this draft we argue that Infra-RRs and AL-RRs SHOULD be treated 196 differently when setting their TTL values. The main rationale is the 197 following: Infra-RRs are mainly used by the DNS system itself and as 198 such tend to be relatively stable records, while AL-RRs are primarily 199 used by applications and thus tend to be more dynamic. As such, 200 Infra-RRs can afford to have longer TTL values. More specifically we 201 propose that Infra-RRs SHOULD have longer TTL values than those 202 observed (12 or less hours), and we recommend that their TTL value 203 SHOULD be in the order of days. This specific value recommendation 204 is based on a measurement study (Appendix A.2), which shows that TTL 205 values of 3 to 7 days can considerably improve the overall 206 availability of the DNS system when faced with denial of service 207 attacks. 209 We recommend this range of TTL values both for the authoritative copy 210 of the Infra-RRs, as well as for the copy of the Infra-RRs stored at 211 the parent zone. These TTL values SHOULD be applied for both copies 212 of Infra-RRs for the following reasons: A) If they are applied only 213 at the parent's copy, then a resolver will always replace the 214 parent's copy with the authoritative copy (lower TTL values), 215 whenever it receives a reply that contains or attaches the 216 authoritative copy. B) If they are applied only at the authoritative 217 copy, then it is possible that a resolver will only use the parent's 218 copy. For example most resolvers cache the NS RRs of most TLDs from 219 replies that usually come from the root zone. These RRs are rarely 220 replaced by their authoritative copy, given that TLDs usually reply 221 with referrals for their child zones (and thus they do not attach 222 their own NS records in these replies). In addition, some name 223 server implementations offer a configuration option called "minimal 224 responses." When this option is enabled, name servers will omit the 225 ADDITIONAL section of DNS responses, and thus not include glue 226 records. 228 2.1. Examples 230 In this section we provide, some example configurations for setting 231 the TTL value of Infra-RRs. The first example shows the 232 configuration of a zone (zone1.example.) when all its NS records have 233 names that belong to the same branch of the DNS tree: 235 $example. 236 zone1.example. 432000 NS a.zone1.example. 237 zone1.example. 432000 NS b.zone1.example. 238 a.zone1.example. 432000 A 10.1.0.1 239 b.zone1.example. 432000 A 10.1.0.2 241 $zone1.example. 242 zone1.example. 432000 NS a.zone1.example. 243 zone1.example. 432000 NS b.zone1.example. 244 a.zone1.example. 432000 A 10.1.0.1 245 b.zone1.example. 432000 A 10.1.0.2 247 The following example shows the configuration of a zone 248 (sub1.zone1.example.), when one of its servers has a name that 249 belongs to a different branch of the DNS tree: 251 $zone1.example. 252 sub1.zone1.example. 432000 NS a.sub1.zone1.example. 253 sub1.zone1.example. 432000 NS b.sub2.zone2.example. 254 a.sub1.zone1.example. 432000 A 10.1.1.1 256 $sub1.zone1.example. 257 sub1.zone1.example. 432000 NS a.sub1.zone1.example. 258 sub1.zone1.example. 432000 NS b.sub2.zone2.example. 259 a.sub1.zone1.example. 432000 A 10.1.1.1 261 $sub2.zone2.example. 262 b.sub2.zone2.example. 432000 A 10.2.2.2 264 Finally the following example shows the configuration for a DNSSEC 265 enabled zone (zone2.example.): 267 $example. 268 zone2.example. 432000 NS a.zone2.example. 269 zone2.example. 432000 NS b.zone2.example. 270 zone2.example. 432000 DS ... 271 zone2.example. 432000 RRSIG ... 272 zone2.example. 432000 NSEC ... 274 $zone2.example. 275 zone2.example. 432000 NS a.zone2.example. 276 zone2.example. 432000 NS b.zone2.example. 277 zone2.example. 432000 RRSIG ... 278 zone2.example. 432000 DNSKEY ... 279 zone2.example. 432000 RRSIG ... 280 zone2.example. 432000 NSEC ... 282 3. Operational Issues 284 3.1. Cache Coherency 286 Increasing the TTL value of Infra-RRs can cause some cached Infra-RRs 287 to be inconsistent with the Infra-RRs provided by the authoritative 288 servers for longer periods of time, when these Infra-RRs change. We 289 believe this cache coherency problem is not an issue for most cases, 290 for the following reasons: First, Infra-RRs tend to be relatively 291 stable records (Appendix A.1, [HOT05DNS]), and thus this 292 inconsistency issue is expected to be a rare event. Second, Infra- 293 RRs inconsistencies for all records except NS and the associated 294 A/AAAA RRs can be easily identified and corrected by a resolver (by 295 querying the authoritative zone for these RRs). 297 Perhaps the most worrisome case occurs when there are inconsistencies 298 between NS Infra-RRs and their corresponding A/AAAA Infra-RRs. In 299 such a case, resolvers are still able to correct inconsistencies as 300 long as the NS and A/AAAA RRs have not changed for at least one name 301 server. That is, as long as there is at least one of the former NS+ 302 A/AAAA mappings that corresponds to a reachable name server, the 303 resolver will eventually contact this server and will be able to 304 replace the new NS and A/AAAA Infra-RRs (assuming that these records 305 are attached in the reply). In the case that all NS and A/AAAA 306 Infra-RRs have changed then the resolver may or may not be able to 307 overcome Infra-RR inconsistency. This depends on the resolvers 308 implementation. Some resolvers tend to contact the parent zone in 309 such a case (and thus correct the inconsistency), while others return 310 an error code (and thus stay inconsistent until the RRs expire). 312 Given that different implementations behave differently in the case 313 where all NS and A/AAAA Infra-RRs change at the same time, we 314 recommend the following for zones that implement longer TTL values 315 for Infra-RRs. The zone administrator SHOULD gradually move to the 316 new Infra-RRs, by incrementally changing the NS and A/AAAA RRs (not 317 all of them at once), or she/he SHOULD maintain that availability of 318 the old set of servers (which have been removed from the zone) until 319 all the old Infra-RRs have expired from the caches of any possible 320 resolver. This can be ensured by keeping servers available for at 321 least an interval equal to the former Infra-RRs TTL (plus some 322 jitter). 324 Another approach that an operator MAY follow is to gradually reduce 325 the TTL value of Infra-RRs before the change, and restore the longer 326 TTL values after the change. Clearly a zone administrator MAY follow 327 any of the above strategies when changing the NS and A/AAAA records 328 to a completely different set. 330 3.2. Routine Cache Maintenance Issues 332 A subtle issue may arise in cases where DNS operators manually (or 333 periodically) manage their caches' state. For example, some 334 operators may (as a matter of operational prudence) periodically 335 flush their resolvers' caches. If, for example, an operator flushes 336 his/her caches every day, then the long TTLs on Infra-RRs would not 337 benefit them for any period longer than his/her own inter-flush 338 period. That is, if caches get flushed every 24 hours, then any TTL 339 longer than 24 hours would effectively be truncated. Thus, the 340 operational tradeoffs that prompt this sort of practice may need to 341 be reconsidered in the face of DDoS threats. 343 3.3. Implementation Issues 345 This document does not require or recommend any implementation 346 changes of either the authoritative server software or the resolver 347 software. On the other hand, we should point out that some changes 348 may be beneficial when zones implement longer TTL values for Infra- 349 RRs. 351 4. Security Considerations 353 This document prescribes an operational practice that facilitates DNS 354 queries during prolonged outages. Such outages may result from 355 extended DDoS attacks against key servers in the DNS. The use of 356 long TTL values does not reduce the attack surface of targeted 357 servers to DDoS attacks. However, the use of long TTL values extends 358 the amount of time a DDoS attack must be waged before it impacts an 359 entire DNS subtree, and directly affects the effectiveness of a DDoS 360 to the global DNS. While a DDoS may disrupt the availability of some 361 critical authoritative servers, the NS records for the zones that are 362 delegated by them will be available in remote caches for much longer. 363 The extended buffer between the start of a DDoS and related outages 364 from its effects provides a greater window for operators (DNS, 365 routing, etc.) to collaborate and mitigate it before its effects 366 become crippling. Therefore, while a DDoS is no less likely, the 367 operational window for remediating its effects can be dramatically 368 enhanced. 370 5. Contributing Authors 372 The editors wish to express that the thoughts, opinions, text, and 373 work of this document are due to the following set of authors: 375 Vasileios Pappas 376 IBM Research, Watson Research Center 377 vpappas@us.ibm.com 379 Eric Osterweil 380 Verisign, Inc. 381 eosterweil@verisign.com 383 Danny McPherson 384 Verisign, Inc. 385 dmcpherson@tcb.net 387 Duane Wessels 388 Verisign, Inc. 389 dwessels@verisign.com 391 Matt Larson 392 Verisign, Inc. 393 mlarson@verisign.com 395 Dan Massey 396 Colorado State University, 397 massey@cs.colostate.edu 399 Lixia Zhang 400 University of California, Los Angeles 401 lixia@cs.ucla.edu 403 6. Acknowledgments 405 We would like to express our thanks to Greg Minshall for an early 406 discussion on the feasibility of using long TTLs to improve DNS 407 availability, to Pete Resnick for his support and the suggestion of 408 using one week or even longer TTL values, and to Rob Austin and 409 Patrik Faltstrom who also provided constructive comments to our 410 proposal. 412 7. References 414 7.1. Normative References 416 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 417 STD 13, RFC 1034, November 1987. 419 [RFC1035] Mockapetris, P., "Domain names - implementation and 420 specification", STD 13, RFC 1035, November 1987. 422 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 423 Requirement Levels", BCP 14, RFC 2119, March 1997. 425 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 426 Specification", RFC 2181, July 1997. 428 [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection 429 and Operation of Secondary DNS Servers", BCP 16, RFC 2182, 430 July 1997. 432 [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via 433 Shared Unicast Addresses", RFC 3258, April 2002. 435 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 436 Rose, "Resource Records for the DNS Security Extensions", 437 RFC 4034, March 2005. 439 7.2. Informative References 441 [HOT05DNS] 442 Handley, M. and A. Greenhalgh, "The Case for Pushing DNS", 443 HotNets, 2005. 445 [IMW01CACHE] 446 Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS 447 Performance and the Effectiveness of Caching", IMW, 2001. 449 [SIG88DNS] 450 Mockapetris, P. and K. Dunlap, "Development of the Domain 451 Name System", SIGCOMM, 1988. 453 Appendix A. Measurements 455 A.1. Frequency of Infra-RR Changes 457 To assess the stability of deployed DNS servers, we conducted a 458 measurement study. From a crawl over 15 million DNS zones (the crawl 459 was initiated at DMOZ.ORG), we randomly selected 100,000 zones and 460 measured their infrastructure RRsets over a 4-month period. 462 During this 4-month period we queried each of the 100,000 zones twice 463 a day to obtain its infrastructure RRset. Our data shows that 75% of 464 the measured zones did not change either the NS or corresponding A 465 RRsets during the entire study period. 11% of the zones showed 466 changes to their NS RRset during this 4-month period, and 5% of the 467 zones made the changes in less than 2 months. The A records of all 468 the measured zone servers had more changes than the NS RRsets: 22% of 469 the zones had their servers' A records changed within 4 months, and 470 10% of the zones made servers' A record changes in less than 2 471 months. All in all, our measurement results show that the DNS 472 servers, in the majority of the zones, are very stable. Even those 473 servers that made changes during our measurement period show that 474 their DNS server changes are rather infrequent. 476 A.2. Effectiveness of Long TTL Values 478 In order to gauge the effectiveness of a longer TTL value for the DNS 479 infrastructure records, we used a real DNS trace that was captured by 480 a UCLA caching server for 2 weeks. Based on this trace, we simulated 481 a DoS attack on all root and TLD servers and we measured the 482 percentage of queries that weren't resolved (excluding negative 483 answers from the root and TLD zones), in the case of measured TTL 484 values, and in the case of a hypothetical TTL value of 3, 5, 7, and 9 485 days for all zones. The attack duration was 3, 6, 12 and 24 hours, 486 and started at the eighth day (in simulation time). The following 487 table shows the absolute number as well as the percentage of the 488 queries that did not resolve for each case of attack duration and TTL 489 value: 491 --------------------------------------------------------------------- 492 | || Attack Duration (Hours) | 493 --------------------------------------------------------------------- 494 | || 3 | 6 | 12 | 24 | 495 | TTL ||------------------------------------------------------------- 496 |(day)|| 7776 Queries | 13799 Queries| 23586 Queries| 53636 Queries | 497 |-------------------------------------------------------------------- 498 | - || 2227 - 28.6% | 3829 - 27.7% | 6807 - 28.8% | 17099 - 31.8% | 499 | 3 || 1132 - 14.5% | 1884 - 13.6% | 3154 - 13.3% | 7218 - 13.4% | 500 | 5 || 917 - 11.7% | 1530 - 11.0% | 2562 - 10.8% | 5947 - 11.0% | 501 | 7 || 767 - 9.8% | 1256 - 9.1% | 2092 - 8.8% | 4766 - 8.8% | 502 | 9 || 711 - 9.1% | 1165 - 8.4% | 1898 - 8.0% | 4157 - 7.7% | 503 --------------------------------------------------------------------- 505 Clearly, we see that by using a longer TTL value we can increase the 506 overall system availability under denial of service attacks. The 507 table shows that with a TTL value of seven days we can decrease the 508 impact of such an attack at the root and TLD servers by 70%, 509 independent of the attack duration. Also the table shows that by 510 increasing the TTL value, we are more resilient to attacks. Based on 511 these results we believe that a TTL value of seven days is adequate 512 enough to considerably improve the resilience of the DNS system 513 against denial of service attacks. 515 Authors' Addresses 517 Vasileios Pappas (editor) 518 IBM Research, Watson Research Center 519 19 Skyline Drive 520 Hawthorne, NY 10532 521 US 523 Email: vpappas@us.ibm.com 525 Eric Osterweil (editor) 526 Verisign, Inc. 527 12061 Bluemont Way 528 Reston, VA 20190 529 US 531 Email: eosterweil@verisign.com