


DNS Extensions (DNSEXT)                                        A. Hubert
Internet-Draft                        Netherlabs Computer Consulting BV.
Updates: 1035                                                R. van Mook
Intended status: Standards Track                                   Virtu
Expires: July 15, 2007                                  January 11, 2007


     Measures for making DNS more resilient against forged answers
              draft-ietf-dnsext-forgery-resilience-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 15, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2007).













Hubert & van Mook         Expires July 15, 2007                 [Page 1]

Internet-Draft    DNS resilience against forged answers     January 2007


Abstract

   The current internet climate poses serious threats to the Domain Name
   System.  In the interim period before the DNS protocol can be secured
   more fully, measures can already be taken to make 'spoofing' a
   recursing nameserver many orders of magnitude harder.

   Even a cryptographically secured DNS benefits from having the ability
   to discard bogus answers quickly, as this potentially saves large
   amounts of computation.

   By describing certain behaviour that has previously not been
   standardised, this document sets out how to make the DNS more
   resilient against accepting incorrect answers.  This document updates
   RFC1034.


Table of Contents

   1.  Requirements and definitions . . . . . . . . . . . . . . . . .  3
     1.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Key words  . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Description of DNS spoofing  . . . . . . . . . . . . . . . . .  6
   4.  Details  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Matching the question  . . . . . . . . . . . . . . . . . .  7
     4.2.  Matching the ID field  . . . . . . . . . . . . . . . . . .  8
     4.3.  Matching the source address of the authentic answer  . . .  8
     4.4.  Matching the destination address of the authentic
           answer . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.5.  Have the answer arrive before the authentic answer . . . .  9
   5.  Birthday attacks . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Accepting only in-zone answers . . . . . . . . . . . . . . . . 11
   7.  Combined difficulty  . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Symbols used in calculation  . . . . . . . . . . . . . . . 12
     7.2.  Calculation  . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  Countermeasures  . . . . . . . . . . . . . . . . . . . . . . . 16
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   12. Normative References . . . . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 22








Hubert & van Mook         Expires July 15, 2007                 [Page 2]

Internet-Draft    DNS resilience against forged answers     January 2007


1.  Requirements and definitions

1.1.  Definitions

   This document uses the following definitions:

      Client: typically a 'stub-resolver' on an end-user's computer

      Resolver: a nameserver performing recursive service for clients,
      also known as a caching server

      Question: a question sent out by a resolver, typically in a UDP
      packet

      Answer: the answer sent back by an authoritative nameserver,
      typically in a UDP packet

      Third party: any host other than the resolver or the intended
      recipient of a question.  The third party may have access to a
      random authoritative nameserver, but has no access to packets
      transmitted by the Resolver ot authoritative server

      Attacker: malicious third party.

      Spoof: the activity of attempting to subvert the DNS process by
      getting a chosen answer accepted

      Authentic answer: the answer that would be accepted if no third
      party interferes

      Target domain: domain for which the attacker wishes to spoof in an
      answer

      Fake data: answer chosen by the attacker

   TBD: Do we need to talk about stub resolvers?  Does this draft apply
   to them?

1.2.  Key words

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








Hubert & van Mook         Expires July 15, 2007                 [Page 3]

Internet-Draft    DNS resilience against forged answers     January 2007


2.  Introduction

   This document describes several common problems in DNS
   implementations which, although previously recognized, remain largely
   unsolved.  Besides briefly recapping these problems, this RFC
   contains rules that, if implemented, make complying resolvers vastly
   more resistant to the attacks described.

   Almost every transaction on the internet involves the Domain Name
   System, which is described in [RFC1034], [RFC1035] and beyond.

   Additionally, it has recently become possible to acquire SSL
   certificates with no other confirmation of identity than the ability
   to respond to a verification email sent via SMTP ([RFC2821]) - which
   generally uses DNS for its routing.

   In other words, any party that (temporarily) controls the Domain Name
   System is in a position to reroute most kinds of Internet
   transactions, including the verification steps in acquiring an SSL
   certificate for a domain.  This in turn means that even transactions
   protected by SSL could be diverted.

   It is entirely conceivable that such rerouted traffic could be used
   to the disadvantage of internet users.

   These and other developments have made the security and
   trustworthiness of DNS of renewed importance.  Although the DNS
   community is working hard on finalising and implementing a
   cryptographically enhanced DNS protocol, steps should be taken to
   make sure that the existing use of DNS is as secure as possible
   within the bounds of the relevant standards.

   It should be noted that the most commonly used resolver currently
   does not perform as well as possible in this respect, making this
   document of urgent importance.

   A thorough analysis of risks facing DNS can be found in [RFC3833].

   This document expands on some of the risks mentioned in RFC 3833,
   especially those outlined in the sections on 'ID Guessing and Query
   Prediction' and 'Name Chaining'.  Furthermore, it emphasises a number
   of existing rules and guidelines embodied in the relevant STDs and
   RFCs.  The following also specifies new requirements to make sure the
   Domain Name System can be relied upon until a more secure protocol
   has been standardised and deployed.

   It should be noted that even when all measures suggested below are
   implemented, protocol users are not protected against third parties



Hubert & van Mook         Expires July 15, 2007                 [Page 4]

Internet-Draft    DNS resilience against forged answers     January 2007


   with the ability to intercept, change or inject packets sent to the
   resolver.

   For protocol extensions under development that offer protection
   against these scenarios, see [RFC4033] and beyond.














































Hubert & van Mook         Expires July 15, 2007                 [Page 5]

Internet-Draft    DNS resilience against forged answers     January 2007


3.  Description of DNS spoofing

   When certain steps are taken it is feasible to 'spoof' the current
   deployed majority of caching resolvers with carefully crafted and
   timed DNS packets.  Once spoofed, a caching server will repeat the
   data it wrongfully accepted, and make its clients contact the wrong,
   and possibly malicious, servers.

   To understand how this process works it is important to know what
   makes a resolver (and more specifically a caching server) accept an
   answer.

   Section 5.3.3 of [RFC1034] presaged the present problem:

     The resolver should be highly paranoid in its parsing of responses.
     It should also check that the response matches the query it sent
     using the ID field in the response.

   DNS data is accepted by a resolver if and only if:

   1.  The question section of the reply packet is identical to that of
       a question packet currently waiting for an answer

   2.  The ID field of the reply packet matches that of the question
       packet

   3.  The answer comes from the same network address the question was
       sent to

   4.  The answer comes in on the same network address, including port
       number, as the question was sent from

   5.  It is the first answer to match the previous four conditions.

   Note that the fifth condition can strictly speaking be derived from
   the first.  It is included for clarity reasons only.

   If a third party succeeds in meeting the first four conditions before
   the answer from the authentic answer does so, it is in a position to
   feed a resolver fabricated data.  When it does so, we dub it an
   attacker, attempting to spoof in fake data.

   All conditions mentioned above can theoretically be met, with the
   difficulty being a function of the resolver implementation and zone
   configuration.






Hubert & van Mook         Expires July 15, 2007                 [Page 6]

Internet-Draft    DNS resilience against forged answers     January 2007


4.  Details

   The previous paragraph discussed a number of requirements an attacker
   must match in order to spoof in manipulated (or fake) data.  This
   section discusses the relative difficulties and how implementation
   defined choices impact the amount of work an attacker has to perform
   to meet said difficulties.

   Some more details can be found in section 2.2 of [RFC3833].

4.1.  Matching the question

   Formally, there is no need for a nameserver to perform service except
   for its operator, its customers or more generally its users.
   Recently, open recursing nameservers have been used to amplify denial
   of service attacks.

   In spite of this, many resolvers perform at least partial service for
   the whole world.  This is partially out of lack of concern, and is
   reminiscent of the open relay SMTP service the net enjoyed up to the
   early 1990s.  Some access providers may serve so many subnets that it
   is hard to enumerate these all in the DNS configuration.

   Providing full service enables the third party to send the target
   resolver a question for the domain name it intends to spoof.  On
   receiving this question, and not finding the answer in its cache, the
   resolver will transmit questions to relevant authoritative
   nameservers.  This opens up a window of opportunity for getting fake
   answer data accepted.

   Some operators restrict access by not recursing for unauthorised IP
   addresses, but only respond with data from the cache.  This makes
   spoofing harder for a third party as it cannot then force the exact
   moment a question will be asked.  It is still possible however to
   determine a time range when this will happen, because nameservers
   helpfully publish the decreasing TTL of entries in the cache, which
   indicate from which absolute time onwards a new query could be sent
   to refresh the expired entry.

   The time to live of the 'target domain' determines how often a window
   of opportunity is available, which implies that a short TTL makes
   spoofing far more viable.

   Note that the attacker might very well have authorised access to the
   target resolver by virtue of being a customer or employee of its
   operator.





Hubert & van Mook         Expires July 15, 2007                 [Page 7]

Internet-Draft    DNS resilience against forged answers     January 2007


4.2.  Matching the ID field

   The DNS ID field is 16 bits wide, meaning that if full use is made of
   all these bits, and if their contents are truly random, it will
   require on average 32768 attempts to guess.  Anecdotal evidence
   suggests there are implementations utilising only 14 bits, meaning on
   average 8192 attempts will suffice.

   Additionally, if the target nameserver can be forced into having
   multiple identical questions outstanding, the 'Birthday Attack'
   phenomenon means that any fake data sent by the attacker is matched
   against multiple outstanding questions, significantly raising the
   chance of success.  Further details in Section 5.

4.3.  Matching the source address of the authentic answer

   Most domains have two or three authoritative nameservers, which make
   matching the source address of the authentic answer very likely with
   even a naive choice having a double digit success rate.

   Most recursing nameservers store relative performance indications of
   authoritative nameservers, which may make it easier to predict which
   nameserver would originally be queried - the one most likely to
   respond the quickest.

   Generally, this condition requires at most two or three attempts
   before it is matched.

   It should be noted that meeting this condition entails being able to
   transmit packets on behalf of the address of the authoritative
   nameserver.  While several important documents ([RFC2827] and
   [RFC3013] specifically) direct internet access providers to prevent
   their customers from assuming IP addresses that are not assigned to
   them, these recommendations are not universally (nor even widely)
   implemented.

4.4.  Matching the destination address of the authentic answer

   Note that the destination address of the authentic answer is the
   source address of the original question.

   The actual address of a recursing nameserver is generally known; the
   port used for asking questions is harder to determine.  Most current
   resolvers pick a random port at startup and use this for all outgoing
   questions.  In quite a number of cases the source port of outgoing
   questions is fixed at the traditional DNS assigned port of 53.

   If the source port of the original question is random, but static,



Hubert & van Mook         Expires July 15, 2007                 [Page 8]

Internet-Draft    DNS resilience against forged answers     January 2007


   any authoritative nameserver under observation by the attacker can be
   used to determine this port.  This means that matching this
   conditions often requires no guess work.

   If multiple ports are used for sending questions, this enlarges the
   effective address space by a factor equal to the number of ports
   used.

   Less common resolving servers choose a random port per outgoing
   question.  If this strategy is followed, this port number can be
   regarded as an additional ID field, again containing up to 16 bits.

   If the maximum ports range is utilized, on average, around 32128
   source ports would have to be tried before matching the source port
   of the original question as ports below 1024 may be unavailable for
   use, leaving 64512 options.

   It should be noted that a firewall will not prevent the matching of
   this address, as it will accept answers that (appear) to come from
   the correct address, offering no additional security.

4.5.  Have the answer arrive before the authentic answer

   Once any packet has matched the previous four conditions, no further
   answers should be accepted.

   This means that the third party has a limited time in which to inject
   its spoofed answer, typically in the order of at most 100ms.

   This time period can be far longer if the authentic authoritative
   nameservers are (briefly) overloaded by queries, perhaps by the
   attacker.



















Hubert & van Mook         Expires July 15, 2007                 [Page 9]

Internet-Draft    DNS resilience against forged answers     January 2007


5.  Birthday attacks

   A curious mathematical phenomenon means that a group of 22 people
   suffices to have a more than even chance at having two or more
   members of the group share a birthday.

   An attacker can benefit from this phenomenon if it can force the
   target resolver to have multiple outstanding questions at any one
   time for the same domain to the same authoritative server.

   Any packet the attacker sends then has a much higher chance of being
   accepted because it only has to match any of the outstanding queries
   for that single domain.  Compared to the birthday analogy above, of
   the group composed of questions and answers, the chance of having any
   of these share an ID rises quickly.

   As long as small numbers of questions are sent out, the chance of
   successfully spoofing an anwers rises linearly with the number of
   outstanding questions for the exact domain and nameserver.

   For larger numbers this effect is less pronounced.

   More details are available in US-CERT [vu-457875].




























Hubert & van Mook         Expires July 15, 2007                [Page 10]

Internet-Draft    DNS resilience against forged answers     January 2007


6.  Accepting only in-zone answers

   Answers from authoritative nameservers often contain information that
   is not part of the zone for which we deem it authoritative.  As an
   example, a query for the MX record of a domain might get as its
   answer a mail exchanger in another domain, and additionally the IP
   address of this mail exchanger.

   If accepted uncritically, the resolver stands the chance of accepting
   data from an untrusted source.  Care must be taken to only accept
   data if it is known that the originator is authoritative for that
   data.

   One very simple way to achieve this is to only accept data if it is
   part of the domain we asked the question for.




































Hubert & van Mook         Expires July 15, 2007                [Page 11]

Internet-Draft    DNS resilience against forged answers     January 2007


7.  Combined difficulty

   Given a known or static destination port, matching ID field, source
   and destination address requires on average in the order of 2 * 2^15
   = 65000 packets, assuming a domain has 2 authoritative nameservers.

   If the window of opportunity available is around 100ms, as assumed
   above, an attacker would need to be able to briefly transmit 650000
   packets/s to have a 50% chance to get spoofed data accepted on the
   first attempt.

   A realistic minimal DNS answer consists of around 80 bytes, including
   IP headers, making the packet rate above correspond to a respectable
   burst of 416Mb/s.

   As of mid-2006, this kind of bandwidth was not common but not scarce
   either, especially among those in a position to control many servers.

   These numbers change when a window of a full second is assumed,
   possibly because the arrival of the authentic answer can be prevented
   by overloading the bonafide authoritative hosts with decoy questions.
   This reduces the needed bandwith to 42 Mb/s.

   If in addition the attacker is granted more than a single chance and
   allowed up to 60 minutes of work on a domain with a time to live of
   300 seconds, a meagre 4Mb/s suffices for a 50% chance at getting fake
   data accepted.  Once equipped with a longer time, matching condition
   1 mentioned above is straightforward - any popular domain will have
   been queried a number of times within this hour, and given the short
   TTL, this would lead to questions to authoritative nameservers,
   opening windows of opportunity.

7.1.  Symbols used in calculation

   Assume the following symbols are used:

      I: Number distinct IDs available (maximum 65536)

      P: Number of ports used (maximum around 64000, but often 1)

      N: Number of authoritative nameservers for a domain (averages
      around 2.5)

      F: Number of 'fake' packets sent by the attacker







Hubert & van Mook         Expires July 15, 2007                [Page 12]

Internet-Draft    DNS resilience against forged answers     January 2007


      R: Number of packets sent per second by the attacker

      W: Window of opportunity, in seconds.  Bounded by the response
      time of the authoritative servers (often 0.1s)

      D: Average number of identical outstanding questions of a resolver
      (typically 1, see Section 5)

      A: Number of attempts, one for each window of opportunity

7.2.  Calculation

   The probability of spoofing a resolver is equal to amount of fake
   packets that arrive within the window of opportunity, divided by the
   size of the problem space.

   When the resolver has 'D' multiple identical outstanding questions,
   each fake packet has a proportionally higher chance of matching any
   of these questions.  This assumption only holds for small values of
   'D'.

   In symbols, if the probability of being spoofed is denoted as P_s:

              D * F
   P_s =    ---------
            N * P * I

   It is more useful to reason not in terms of aggregate packets but to
   convert to packet rate, which can easily be converted to bandwidth if
   needed.

   If the Window of opportunity length is 'W' and the attacker can send
   'R' packets per second, the number of fake packets 'F' that are
   candidates to be accepted is:

                          D * R * W
   F = R * W  ->   P_s  = ----------
                          N * P * I

   Finally, to calculate the combined chance 'P_cs' of spoofing over a
   chosen time period 'T', it should be realised that the attacker has a
   new window of opportunity each time the TTL 'TTL' of the target
   domain expires.  This means that the number of attempts 'A' is equal
   to 'T / TTL'.







Hubert & van Mook         Expires July 15, 2007                [Page 13]

Internet-Draft    DNS resilience against forged answers     January 2007


   To calculate the combined chance of at least one success, the
   following formula holds:

                                                        (T / TTL)
                         A          (       D * R * W )
   P_cs = 1 - ( 1 - P_s )    =  1 - ( 1  -  --------- )
                                    (       N * P * I )

   When common numbers (as listed above) for D, W, N, P and I are
   inserted, this formula reduces to:

                               (T / TTL)
              (         R    )
   P_cs = 1 - ( 1 -  ------- )
              (      1638400 )

   From this formula it can be seen that, if the nameserver
   implementation is unchanged, only raising the TTL offers protection.
   Raising N, the number of authoritative nameservers, is not feasible
   beyond a small number.

   For the degenerate case of a zero-second TTL, a window of opportunity
   opens for each question asked, making the effective TTL equal to 'W'
   above, the response time of the authoritative server.



























Hubert & van Mook         Expires July 15, 2007                [Page 14]

Internet-Draft    DNS resilience against forged answers     January 2007


8.  Discussion

   The calculations above indicate the relative ease with which DNS data
   can be spoofed.  For example, using the formula derived earlier on a
   domain with a 3600 second TTL, an attacker sending 7000 fake answer
   packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a
   record in the first 24 hours, which rises to 50% after a week.

   For a domain with a TTL of 60 seconds, the 10% level is hit after 24
   minutes, 50% after less than 3 hours, 90% after around 9 hours.

   Note that the attacks mentioned above can be detected by watchful
   server operators - an unexpected incoming stream of 4.5mbit/s of
   packets might be noticed.

   An important assumption however in these calculations is a known or
   static destination port of the authentic answer.

   If that port number is unknown and needs to be guessed as well, the
   problem space expands by a factor of 64000, leading the attacker to
   need in excess of 285Gb/s to achieve similar success rates.

   Such bandwidth is not generally available, nor expected to be so in
   the foreseeable future.

   Note that some firewalls may need reconfiguring if they are currently
   setup to only allow outgoing queries from a single DNS source port.
























Hubert & van Mook         Expires July 15, 2007                [Page 15]

Internet-Draft    DNS resilience against forged answers     January 2007


9.  Countermeasures

   NOTE: This section is expected to change, and is very much open to
   discussion!

   Implementations MUST be able to send queries from ANY UDP port

   Implementations SHOULD use good random source to select Query ID for
   next query

   Implementations SHOULD be configurable to use one or multiple ports
   for queries.

   Implementations MAY be configurable to use one or more addresses for
   queries

   Implementations MUST suppress multiple identical queries to the SAME
   server.

   Implementations MUST match answers to the following

   o  Remote address

   o  Local address

   o  Query port

   o  Query ID

   o  Question

   before applying DNS credibility rules.

   The document can not require the use of either multiple ports or
   addresses as that is an operational issue and should be addressed in
   a separate document in DNSOP.

   NOTE!  A previous version of requirements is listed below as an
   inspiration to further discussions:

   Given the above, a resolver MAY/SHOULD/MUST:

   o  Use an unpredictable source port from its available range for each
      outgoing query

   o  Make full use of all 16 bits of the ID field





Hubert & van Mook         Expires July 15, 2007                [Page 16]

Internet-Draft    DNS resilience against forged answers     January 2007


   o  Assure that its choices of port and ID cannot be predicted by an
      attacker having knowledge of its (pseudo-)random generator

   o  Not send out multiple equivalent questions outstanding to any
      authoritative server, unless all with identical ID and source port

   A resolver SHOULD offer diagnostics that enable the operator to
   determine a spoofing attempt is under way.

   Operators SHOULD attempt to restrict recursing service, either full
   or partial, to authorised users.

   A resolver MAY use heuristics to detect an excess of unacceptable
   answers and take measures if it believes an attempt is made to spoof
   it.

   Futhermore, zone operators are urged not to configure the Time To
   Live of domains to be lower than realistically needed for proper
   operations.
































Hubert & van Mook         Expires July 15, 2007                [Page 17]

Internet-Draft    DNS resilience against forged answers     January 2007


10.  Security Considerations

   This document directly impacts the operational security of the Domain
   Name System, readers are urged to implement its recommendations.

   TBD!













































Hubert & van Mook         Expires July 15, 2007                [Page 18]

Internet-Draft    DNS resilience against forged answers     January 2007


11.  Acknowledgements

   Source port randomisation in DNS was first implemented and possibly
   invented by Dan. J. Bernstein.

   Although any mistakes remain our own, the authors gratefully
   acknowledge the help and contributions of:

      Stephane Bortzmeyer,

      Sean Leach,

      Norbert Sendetzky






































Hubert & van Mook         Expires July 15, 2007                [Page 19]

Internet-Draft    DNS resilience against forged answers     January 2007


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

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

   [RFC3013]  Killalea, T., "Recommended Internet Service Provider
              Security Services and Procedures", BCP 46, RFC 3013,
              November 2000.

   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
              Name System (DNS)", RFC 3833, August 2004.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [vu-457875]
              United States CERT, "Various DNS service implementations
              generate multiple simultaneous queries for the same
              resource record", VU 457875, November 2002.


















Hubert & van Mook         Expires July 15, 2007                [Page 20]

Internet-Draft    DNS resilience against forged answers     January 2007


Authors' Addresses

   bert hubert
   Netherlabs Computer Consulting BV.
   Braillelaan 10
   Rijswijk (ZH)  2289 CM
   The Netherlands

   Email: bert.hubert@netherlabs.nl


   Remco van Mook
   Virtu
   Auke Vleerstraat 1
   Enschede  7521 PE
   The Netherlands

   Email: remco@virtu.nl

































Hubert & van Mook         Expires July 15, 2007                [Page 21]

Internet-Draft    DNS resilience against forged answers     January 2007


Full Copyright Statement

   Copyright (C) The Internet Society (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Hubert & van Mook         Expires July 15, 2007                [Page 22]

