[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

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]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/