draft-ietf-dnsext-forgery-resilience-01.txt   draft-ietf-dnsext-forgery-resilience-02.txt 
DNS Extensions (DNSEXT) A. Hubert DNS Extensions (DNSEXT) A. Hubert
Internet-Draft Netherlabs Computer Consulting BV. Internet-Draft Netherlabs Computer Consulting BV.
Updates: 1035 (if approved) R. van Mook Updates: 1034 (if approved) R. van Mook
Intended status: Standards Track Virtu Intended status: Standards Track Virtu
Expires: August 22, 2008 February 19, 2008
Measures for making DNS more resilient against forged answers Measures for making DNS more resilient against forged answers
draft-ietf-dnsext-forgery-resilience-01.txt draft-ietf-dnsext-forgery-resilience-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2008. This Internet-Draft will expire on August 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The current internet climate poses serious threats to the Domain Name The current Internet climate poses serious threats to the Domain Name
System. In the interim period before the DNS protocol can be secured System. In the interim period before the DNS protocol can be secured
more fully, measures can already be taken to make 'spoofing' a more fully, measures can already be taken to harden the DNS to make
recursing nameserver many orders of magnitude harder. 'spoofing' a recursing nameserver many orders of magnitude harder.
Even a cryptographically secured DNS benefits from having the ability Even a cryptographically secured DNS benefits from having the ability
to discard bogus answers quickly, as this potentially saves large to discard bogus answers quickly, as this potentially saves large
amounts of computation. amounts of computation.
By describing certain behaviour that has previously not been By describing certain behaviour that has previously not been
standardised, this document sets out how to make the DNS more standardised, this document sets out how to make the DNS more
resilient against accepting incorrect answers. This document updates resilient against accepting incorrect answers. This document updates
RFC1034. RFC1034.
skipping to change at page 2, line 42 skipping to change at page 2, line 42
4.4. Matching the destination address of the authentic 4.4. Matching the destination address of the authentic
answer . . . . . . . . . . . . . . . . . . . . . . . . . . 8 answer . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Have the answer arrive before the authentic answer . . . . 9 4.5. Have the answer arrive before the authentic answer . . . . 9
5. Birthday attacks . . . . . . . . . . . . . . . . . . . . . . . 10 5. Birthday attacks . . . . . . . . . . . . . . . . . . . . . . . 10
6. Accepting only in-zone answers . . . . . . . . . . . . . . . . 11 6. Accepting only in-zone answers . . . . . . . . . . . . . . . . 11
7. Combined difficulty . . . . . . . . . . . . . . . . . . . . . 12 7. Combined difficulty . . . . . . . . . . . . . . . . . . . . . 12
7.1. Symbols used in calculation . . . . . . . . . . . . . . . 12 7.1. Symbols used in calculation . . . . . . . . . . . . . . . 12
7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 13
8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 16 9. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
12. Normative References . . . . . . . . . . . . . . . . . . . . . 20 12. Normative References . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Requirements and definitions 1. Requirements and definitions
1.1. Definitions 1.1. Definitions
This document uses the following definitions: This document uses the following definitions:
Client: typically a 'stub-resolver' on an end-user's computer Client: typically a 'stub-resolver' on an end-user's computer
Resolver: a nameserver performing recursive service for clients, Resolver: a nameserver performing recursive service for clients,
also known as a caching server also known as a caching server
Stub resolver: a very limited Resolver on a client computer, that
leaves most of the recursing work to a full resolver
Question: a question sent out by a resolver, typically in a UDP Question: a question sent out by a resolver, typically in a UDP
packet packet
Answer: the answer sent back by an authoritative nameserver, Answer: the answer sent back by an authoritative nameserver,
typically in a UDP packet typically in a UDP packet
Third party: any host other than the resolver or the intended Third party: any host other than the resolver or the intended
recipient of a question. The third party may have access to a recipient of a question. The third party may have access to an
random authoritative nameserver, but has no access to packets arbitrary authoritative nameserver, but has no access to packets
transmitted by the Resolver or authoritative server transmitted by the Resolver or authoritative server
Attacker: malicious third party. Attacker: malicious third party.
Spoof: the activity of attempting to subvert the DNS process by Spoof: the activity of attempting to subvert the DNS process by
getting a chosen answer accepted getting a chosen answer accepted
Authentic answer: the answer that would be accepted if no third Authentic answer: the answer that would be accepted if no third
party interferes party interferes
Target domain: domain for which the attacker wishes to spoof in an Target domain: domain for which the attacker wishes to spoof in an
answer answer
Fake data: answer chosen by the attacker 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 1.2. Key words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
This document describes several common problems in DNS This document describes several common problems in DNS
implementations which, although previously recognized, remain largely implementations which, although previously recognized, remain largely
unsolved. Besides briefly recapping these problems, this RFC unsolved. Besides briefly recapping these problems, this RFC
contains rules that, if implemented, make complying resolvers vastly contains rules that, if implemented, make complying resolvers vastly
more resistant to the attacks described. more resistant to the attacks described.
Almost every transaction on the internet involves the Domain Name The words below are aimed at authors of resolvers: it is up to
operators to decide which nameserver implementation to use, or which
options to enable. Operational constraints may override the security
concerns described below. However, implementations are expected to
allow an operator to enable functionality described in this document.
Almost every transaction on the Internet involves the Domain Name
System, which is described in [RFC1034], [RFC1035] and beyond. System, which is described in [RFC1034], [RFC1035] and beyond.
Additionally, it has recently become possible to acquire SSL Additionally, it has recently become possible to acquire SSL/TLS
certificates with no other confirmation of identity than the ability certificates with no other confirmation of identity than the ability
to respond to a verification email sent via SMTP ([RFC2821]) - which to respond to a verification email sent via SMTP ([RFC2821]) - which
generally uses DNS for its routing. generally uses DNS for its routing.
In other words, any party that (temporarily) controls the Domain Name In other words, any party that (temporarily) controls the Domain Name
System is in a position to reroute most kinds of Internet System is in a position to reroute most kinds of Internet
transactions, including the verification steps in acquiring an SSL transactions, including the verification steps in acquiring an SSL/
certificate for a domain. This in turn means that even transactions TLS certificate for a domain. This in turn means that even
protected by SSL could be diverted. transactions protected by SSL/TLS could be diverted.
It is entirely conceivable that such rerouted traffic could be used It is entirely conceivable that such rerouted traffic could be used
to the disadvantage of internet users. to the disadvantage of Internet users.
These and other developments have made the security and These and other developments have made the security and
trustworthiness of DNS of renewed importance. Although the DNS trustworthiness of DNS of renewed importance. Although the DNS
community is working hard on finalising and implementing a community is working hard on finalising and implementing a
cryptographically enhanced DNS protocol, steps should be taken to cryptographically enhanced DNS protocol, steps should be taken to
make sure that the existing use of DNS is as secure as possible make sure that the existing use of DNS is as secure as possible
within the bounds of the relevant standards. within the bounds of the relevant standards.
It should be noted that the most commonly used resolver currently It should be noted that the most commonly used resolver currently
does not perform as well as possible in this respect, making this does not perform as well as possible in this respect, making this
skipping to change at page 6, line 17 skipping to change at page 6, line 17
When certain steps are taken it is feasible to 'spoof' the current When certain steps are taken it is feasible to 'spoof' the current
deployed majority of caching resolvers with carefully crafted and deployed majority of caching resolvers with carefully crafted and
timed DNS packets. Once spoofed, a caching server will repeat the timed DNS packets. Once spoofed, a caching server will repeat the
data it wrongfully accepted, and make its clients contact the wrong, data it wrongfully accepted, and make its clients contact the wrong,
and possibly malicious, servers. and possibly malicious, servers.
To understand how this process works it is important to know what To understand how this process works it is important to know what
makes a resolver (and more specifically a caching server) accept an makes a resolver (and more specifically a caching server) accept an
answer. answer.
Section 5.3.3 of [RFC1034] presaged the present problem: The following sentence in section 5.3.3 of [RFC1034] presaged the
present problem:
The resolver should be highly paranoid in its parsing of responses. The resolver should be highly paranoid in its parsing of responses.
It should also check that the response matches the query it sent It should also check that the response matches the query it sent
using the ID field in the response. using the ID field in the response.
DNS data is accepted by a resolver if and only if: DNS data is accepted by a resolver if and only if:
1. The question section of the reply packet is identical to that of 1. The question section of the reply packet is identical to that of
a question packet currently waiting for an answer a question packet currently waiting for an answer
skipping to change at page 6, line 39 skipping to change at page 6, line 40
packet packet
3. The answer comes from the same network address the question was 3. The answer comes from the same network address the question was
sent to sent to
4. The answer comes in on the same network address, including port 4. The answer comes in on the same network address, including port
number, as the question was sent from number, as the question was sent from
5. It is the first answer to match the previous four conditions. 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 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 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 feed a resolver fabricated data. When it does so, we dub it an
attacker, attempting to spoof in fake data. attacker, attempting to spoof in fake data.
All conditions mentioned above can theoretically be met, with the All conditions mentioned above can theoretically be met, with the
difficulty being a function of the resolver implementation and zone difficulty being a function of the resolver implementation and zone
configuration. configuration.
4. Details 4. Details
skipping to change at page 8, line 35 skipping to change at page 8, line 35
Most recursing nameservers store relative performance indications of Most recursing nameservers store relative performance indications of
authoritative nameservers, which may make it easier to predict which authoritative nameservers, which may make it easier to predict which
nameserver would originally be queried - the one most likely to nameserver would originally be queried - the one most likely to
respond the quickest. respond the quickest.
Generally, this condition requires at most two or three attempts Generally, this condition requires at most two or three attempts
before it is matched. before it is matched.
It should be noted that meeting this condition entails being able to It should be noted that meeting this condition entails being able to
transmit packets on behalf of the address of the authoritative transmit packets on behalf of the address of the authoritative
nameserver. While several important documents ([RFC2827] and nameserver. While two Best Current Practice documents ([RFC2827] and
[RFC3013] specifically) direct internet access providers to prevent [RFC3013] specifically) direct Internet access providers to prevent
their customers from assuming IP addresses that are not assigned to their customers from assuming IP addresses that are not assigned to
them, these recommendations are not universally (nor even widely) them, these recommendations are not universally (nor even widely)
implemented. implemented.
4.4. Matching the destination address of the authentic answer 4.4. Matching the destination address of the authentic answer
Note that the destination address of the authentic answer is the Note that the destination address of the authentic answer is the
source address of the original question. source address of the original question.
The actual address of a recursing nameserver is generally known; the The actual address of a recursing nameserver is generally known; the
port used for asking questions is harder to determine. Most current port used for asking questions is harder to determine. Most current
resolvers pick a random port at startup and use this for all outgoing 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. In quite a number of cases the source port of outgoing
questions is fixed at the traditional DNS assigned port of 53. questions is fixed at the traditional DNS assigned server port number
of 53.
If the source port of the original question is random, but static, If the source port of the original question is random, but static,
any authoritative nameserver under observation by the attacker can be any authoritative nameserver under observation by the attacker can be
used to determine this port. This means that matching this used to determine this port. This means that matching this
conditions often requires no guess work. conditions often requires no guess work.
If multiple ports are used for sending questions, this enlarges the If multiple ports are used for sending questions, this enlarges the
effective address space by a factor equal to the number of ports effective address space by a factor equal to the number of ports
used. used.
skipping to change at page 10, line 7 skipping to change at page 10, line 7
This means that the third party has a limited time in which to inject 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. its spoofed answer, typically in the order of at most 100ms.
This time period can be far longer if the authentic authoritative This time period can be far longer if the authentic authoritative
nameservers are (briefly) overloaded by queries, perhaps by the nameservers are (briefly) overloaded by queries, perhaps by the
attacker. attacker.
5. Birthday attacks 5. Birthday attacks
A curious mathematical phenomenon means that a group of 22 people The so called birthday paradox means that a group of 22 people
suffices to have a more than even chance at having two or more suffices to have a more than even chance of having two or more
members of the group share a birthday. members of the group share a birthday.
An attacker can benefit from this phenomenon if it can force the An attacker can benefit from this exact phenomenon if it can force
target resolver to have multiple outstanding questions at any one the target resolver to have multiple outstanding questions at any one
time for the same domain to the same authoritative server. time for the same domain to the same authoritative server.
Any packet the attacker sends then has a much higher chance of being 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 accepted because it only has to match any of the outstanding queries
for that single domain. Compared to the birthday analogy above, of for that single domain. Compared to the birthday analogy above, of
the group composed of questions and answers, the chance of having any the group composed of questions and answers, the chance of having any
of these share an ID rises quickly. of these share an ID rises quickly.
As long as small numbers of questions are sent out, the chance of As long as small numbers of questions are sent out, the chance of
successfully spoofing an anwers rises linearly with the number of successfully spoofing an answer rises linearly with the number of
outstanding questions for the exact domain and nameserver. outstanding questions for the exact domain and nameserver.
For larger numbers this effect is less pronounced. For larger numbers this effect is less pronounced.
More details are available in US-CERT [vu-457875]. More details are available in US-CERT [vu-457875].
6. Accepting only in-zone answers 6. Accepting only in-zone answers
Answers from authoritative nameservers often contain information that Answers from authoritative nameservers often contain information that
is not part of the zone for which we deem it authoritative. As an is not part of the zone for which we deem it authoritative. As an
skipping to change at page 12, line 26 skipping to change at page 12, line 26
A realistic minimal DNS answer consists of around 80 bytes, including A realistic minimal DNS answer consists of around 80 bytes, including
IP headers, making the packet rate above correspond to a respectable IP headers, making the packet rate above correspond to a respectable
burst of 416Mb/s. burst of 416Mb/s.
As of mid-2006, this kind of bandwidth was not common but not scarce 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. either, especially among those in a position to control many servers.
These numbers change when a window of a full second is assumed, These numbers change when a window of a full second is assumed,
possibly because the arrival of the authentic answer can be prevented possibly because the arrival of the authentic answer can be prevented
by overloading the bonafide authoritative hosts with decoy questions. by overloading the bonafide authoritative hosts with decoy questions.
This reduces the needed bandwith to 42 Mb/s. This reduces the needed bandwidth to 42 Mb/s.
If in addition the attacker is granted more than a single chance and 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 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 300 seconds, a meagre 4Mb/s suffices for a 50% chance at getting fake
data accepted. Once equipped with a longer time, matching condition data accepted. Once equipped with a longer time, matching condition
1 mentioned above is straightforward - any popular domain will have 1 mentioned above is straightforward - any popular domain will have
been queried a number of times within this hour, and given the short been queried a number of times within this hour, and given the short
TTL, this would lead to questions to authoritative nameservers, TTL, this would lead to questions to authoritative nameservers,
opening windows of opportunity. opening windows of opportunity.
skipping to change at page 13, line 16 skipping to change at page 13, line 16
W: Window of opportunity, in seconds. Bounded by the response W: Window of opportunity, in seconds. Bounded by the response
time of the authoritative servers (often 0.1s) time of the authoritative servers (often 0.1s)
D: Average number of identical outstanding questions of a resolver D: Average number of identical outstanding questions of a resolver
(typically 1, see Section 5) (typically 1, see Section 5)
A: Number of attempts, one for each window of opportunity A: Number of attempts, one for each window of opportunity
7.2. Calculation 7.2. Calculation
The probability of spoofing a resolver is equal to amount of fake The probability of spoofing a resolver is equal to the amount of fake
packets that arrive within the window of opportunity, divided by the packets that arrive within the window of opportunity, divided by the
size of the problem space. size of the problem space.
When the resolver has 'D' multiple identical outstanding questions, When the resolver has 'D' multiple identical outstanding questions,
each fake packet has a proportionally higher chance of matching any each fake packet has a proportionally higher chance of matching any
of these questions. This assumption only holds for small values of of these questions. This assumption only holds for small values of
'D'. 'D'.
In symbols, if the probability of being spoofed is denoted as P_s: In symbols, if the probability of being spoofed is denoted as P_s:
skipping to change at page 16, line 7 skipping to change at page 16, line 7
need in excess of 285Gb/s to achieve similar success rates. need in excess of 285Gb/s to achieve similar success rates.
Such bandwidth is not generally available, nor expected to be so in Such bandwidth is not generally available, nor expected to be so in
the foreseeable future. the foreseeable future.
Note that some firewalls may need reconfiguring if they are currently Note that some firewalls may need reconfiguring if they are currently
setup to only allow outgoing queries from a single DNS source port. setup to only allow outgoing queries from a single DNS source port.
9. Countermeasures 9. Countermeasures
NOTE: This section is expected to change, and is very much open to Given the above, a resolver implementation MUST match answers to the
discussion! following attributes of the question:
Implementations MUST be able to send queries from ANY UDP port
available to it.
Implementations SHOULD use good random source to select a Query ID
for next query
Implementations SHOULD NOT use UDP source ports <1024 for sending
queries
Implementations MUST use an as large as possible pool of UDP source
ports for sending queries
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 simultaneous identical queries
to the SAME server.
Implementations MUST match answers to the following
o Remote address o Remote address
o Local address o Local address
o Query port o Query port
o Query ID o Query ID
o Question o Question (name and type)
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 before applying DNS trustworthiness rules.
inspiration to further discussions:
Given the above, a resolver MAY/SHOULD/MUST: Additionally, resolver implementations MUST have the ability to:
o Use an unpredictable source port for outgoing queries from a range o Use an unpredictable source port for outgoing queries from a range
(53, or > 1024) of ports that is as large as possible (53, or > 1024) of ports that is as large as possible;
o Make use of all 16 bits of the ID field o Use multiple different source ports simultaneously in case of
multiple outstanding questions;
o Use an unpredictable query ID for outgoing queries, utilizing the
full range available (0-65535);
o Assure that its choices of port and ID cannot be predicted by an o Assure that its choices of port and ID cannot be predicted by an
attacker having knowledge of its (pseudo-)random generator attacker having knowledge of its (pseudo-)random generator.
o Not have multiple equivalent questions outstanding to any If a resolver sends out multiple equivalent questions to any
authoritative server, unless all with identical ID and source port authoritative server, before receiving an answer, all MUST have
identical ID, source address and source port.
A resolver SHOULD offer diagnostics that enable the operator to Resolvers SHOULD favour authoritative nameservers with which a trust
determine a spoofing attempt is under way. relation has been established; Stub-resolvers SHOULD be able to use
TSIG ([RFC2845]) or IPSEC ([RFC2401]) when communicating with their
recursive resolver.
Operators SHOULD attempt to restrict recursing service, either full Proper unpredictability can be achieved by employing a high quality
or partial, to authorised users. random generator, as described in [RFC4086].
A resolver MAY use heuristics to detect an excess of unacceptable 10. Security Considerations
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 This document provides clarification of the DNS specification to
Live of domains to be lower than realistically needed for proper decrease the probability that DNS answers can be successfully forged.
operations. Recommendations found above should be considered complementary to
possible cryptographical enhancements of the domain name system.
10. Security Considerations A resolver that does not implement the recommendations outlined above
can easily be forced to accept spoofed answers, which in turn are
passed on to client computers - misdirecting (user) traffic to
possibly malicious entities.
This document directly impacts the operational security of the Domain This document directly impacts the security of the Domain Name
Name System, readers are urged to implement its recommendations. System, implementers are urged to follow its recommendations.
TBD! Most security considerations can be found in Section 5, while
proposed countermeasures are described in Section 9.
For brevity's sake, in lieu of repeating the security considerations
references, the reader is referred to these sections.
Nothing in this document specifies specific algorithms for operators
to use; it does specify algorithms implementations SHOULD or MUST
support.
The above notwithstanding, it should be noted that using a low Time
To Live for DNS records raises the chances of an attacker spoofing a
resolver.
11. Acknowledgements 11. Acknowledgements
Source port randomisation in DNS was first implemented and possibly Source port randomisation in DNS was first implemented and possibly
invented by Dan. J. Bernstein. invented by Dan. J. Bernstein.
Although any mistakes remain our own, the authors gratefully Although any mistakes remain our own, the authors gratefully
acknowledge the help and contributions of: acknowledge the help and contributions of:
Stephane Bortzmeyer, Stephane Bortzmeyer,
Alfred Hoenes,
Sean Leach, Sean Leach,
Norbert Sendetzky Norbert Sendetzky,
Florian Weimer,
Dan Wing
12. Normative References 12. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC3013] Killalea, T., "Recommended Internet Service Provider [RFC3013] Killalea, T., "Recommended Internet Service Provider
Security Services and Procedures", BCP 46, RFC 3013, Security Services and Procedures", BCP 46, RFC 3013,
November 2000. November 2000.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004. Name System (DNS)", RFC 3833, August 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[vu-457875] [vu-457875]
United States CERT, "Various DNS service implementations United States CERT, "Various DNS service implementations
generate multiple simultaneous queries for the same generate multiple simultaneous queries for the same
resource record", VU 457875, November 2002. resource record", VU 457875, November 2002.
Authors' Addresses Authors' Addresses
bert hubert bert hubert
Netherlabs Computer Consulting BV. Netherlabs Computer Consulting BV.
Braillelaan 10 Braillelaan 10
skipping to change at page 22, line 7 skipping to change at page 21, line 7
Remco van Mook Remco van Mook
Virtu Virtu
Auke Vleerstraat 1 Auke Vleerstraat 1
Enschede 7521 PE Enschede 7521 PE
The Netherlands The Netherlands
Email: remco@virtu.nl Email: remco@virtu.nl
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 45 change blocks. 
93 lines changed or deleted 107 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/