draft-ietf-dnsext-forgery-resilience-03.txt   draft-ietf-dnsext-forgery-resilience-04.txt 
DNS Extensions (DNSEXT) A. Hubert DNS Extensions (DNSEXT) A. Hubert
Internet-Draft Netherlabs Computer Consulting BV. Internet-Draft Netherlabs Computer Consulting BV.
Updates: 1034 (if approved) R. van Mook Updates: 1034 (if approved) R. van Mook
Intended status: Standards Track Virtu Intended status: Standards Track Virtu
Expires: September 25, 2008 March 24, 2008 Expires: December 25, 2008 June 23, 2008
Measures for making DNS more resilient against forged answers Measures for making DNS more resilient against forged answers
draft-ietf-dnsext-forgery-resilience-03.txt draft-ietf-dnsext-forgery-resilience-04.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 35 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 September 25, 2008. This Internet-Draft will expire on December 25, 2008.
Copyright Notice
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 harden the DNS to make more fully, measures can already be taken to harden the DNS to make
'spoofing' a 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 responses 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 responses. This document
RFC 1034. updates RFC 1034.
Table of Contents Table of Contents
1. Requirements and definitions . . . . . . . . . . . . . . . . . 3 1. Requirements and definitions . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Key words . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Key words . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Description of DNS spoofing . . . . . . . . . . . . . . . . . 6 3. Description of DNS spoofing . . . . . . . . . . . . . . . . . 6
4. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Detailed Description of Spoofing Scnearios . . . . . . . . . . 7
4.1. Forcing a question . . . . . . . . . . . . . . . . . . . . 7 4.1. Forcing a question . . . . . . . . . . . . . . . . . . . . 7
4.2. Matching the question section . . . . . . . . . . . . . . 8 4.2. Matching the question section . . . . . . . . . . . . . . 8
4.3. Matching the ID field . . . . . . . . . . . . . . . . . . 8 4.3. Matching the ID field . . . . . . . . . . . . . . . . . . 8
4.4. Matching the source address of the authentic answer . . . 8 4.4. Matching the source address of the authentic response . . 8
4.5. Matching the destination address of the authentic 4.5. Matching the destination address and port of the
answer . . . . . . . . . . . . . . . . . . . . . . . . . . 8 authentic response . . . . . . . . . . . . . . . . . . . . 8
4.6. Have the answer arrive before the authentic answer . . . . 9 4.6. Have the response arrive before the authentic response . . 9
5. Birthday attacks . . . . . . . . . . . . . . . . . . . . . . . 10 5. Birthday attacks . . . . . . . . . . . . . . . . . . . . . . . 10
6. Accepting only in-zone answers . . . . . . . . . . . . . . . . 11 6. Accepting only in-zone records . . . . . . . . . . . . . . . . 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. Recommended ountermeasures . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
12. Normative References . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
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, or a full service resolver
([RFC1123], paragraph 6.1.3.1)
Stub resolver: a very limited Resolver on a client computer, that Stub resolver: a very limited Resolver on a client computer, that
leaves most of the recursing work to a full resolver leaves the recursing work to a full resolver
Question: a question sent out by a resolver, typically in a UDP Query: a question sent out by a resolver, typically in a UDP
packet packet
Answer: the answer sent back by an authoritative nameserver, Reponse: 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 entity other than the resolver or the intended
recipient of a question. The third party may have access to an recipient of a question. The third party may have access to an
arbitrary 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 response: the correct answer that comes from the right
party interferes authoritative server
Target domain: domain for which the attacker wishes to spoof in an Target domain name: domain for which the attacker wishes to spoof
answer in an answer
Fake data: answer chosen by the attacker Fake data: response chosen by the attacker
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. The goal is to make the
existing DNS as secure as possible within the current protocol
boundaries.
The words below are aimed at authors of resolvers: it is up to The words below are aimed at authors of resolvers: it is up to
operators to decide which nameserver implementation to use, or which operators to decide which nameserver implementation to use, or which
options to enable. Operational constraints may override the security options to enable. Operational constraints may override the security
concerns described below. However, implementations are expected to concerns described below. However, implementations are expected to
allow an operator to enable functionality described in this document. allow an operator to enable functionality described in this document.
Almost every transaction on the Internet involves the Domain Name 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.
skipping to change at page 4, line 52 skipping to change at page 5, line 5
It should be noted that the most commonly used resolvers currently do It should be noted that the most commonly used resolvers currently do
not perform as well as possible in this respect, making this document not perform as well as possible in this respect, making this document
of urgent importance. of urgent importance.
A thorough analysis of risks facing DNS can be found in [RFC3833]. A thorough analysis of risks facing DNS can be found in [RFC3833].
This document expands on some of the risks mentioned in RFC 3833, This document expands on some of the risks mentioned in RFC 3833,
especially those outlined in the sections on 'ID Guessing and Query especially those outlined in the sections on 'ID Guessing and Query
Prediction' and 'Name Chaining'. Furthermore, it emphasises a number Prediction' and 'Name Chaining'. Furthermore, it emphasises a number
of existing rules and guidelines embodied in the relevant STDs and of existing rules and guidelines embodied in the relevant DNS
RFCs. The following also specifies new requirements to make sure the protocol specifications. The following also specifies new
Domain Name System can be relied upon until a more secure protocol requirements to make sure the Domain Name System can be relied upon
has been standardised and deployed. until a more secure protocol has been standardised and deployed.
It should be noted that even when all measures suggested below are It should be noted that even when all measures suggested below are
implemented, protocol users are not protected against third parties implemented, protocol users are not protected against third parties
with the ability to intercept, change or inject packets sent to the with the ability to intercept, change or inject packets sent to the
resolver. resolver.
For protocol extensions under development that offer protection For protocol extensions under development that offer protection
against these scenarios, see [RFC4033] and beyond. against these scenarios, see [RFC4033] and beyond.
3. Description of DNS spoofing 3. Description of DNS spoofing
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 resolvers with carefully crafted and timed DNS
timed DNS packets. Once spoofed, a caching server will repeat the packets. Once spoofed, a caching server will repeat the data it
data it wrongfully accepted, and make its clients contact the wrong, wrongfully accepted, and make its clients contact the wrong, and
and possibly malicious, servers. 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 accept a response.
answer.
The following sentence in section 5.3.3 of [RFC1034] presaged the The following sentence in section 5.3.3 of [RFC1034] presaged the
present problem: 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 to be accepted by a resolver if and only if: DNS data is to be accepted by a resolver if and only if:
1. The question section of the reply packet is equivalent to that of 1. The question section of the reply packet is equivalent to that of
a question packet currently waiting for an answer a question packet currently waiting for a response
2. The ID field of the reply packet matches that of the question 2. The ID field of the reply packet matches that of the question
packet packet
3. The answer comes from the same network address the question was 3. The response 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 response comes in on the same network address, including port
number, as the question was sent from number, as the question was sent from
In general, the first answer matching these four conditions is In general, the first response matching these four conditions is
accepted. accepted.
If a third party succeeds in meeting the four conditions before the If a third party succeeds in meeting the four conditions before the
answer from the authentic answer does so, it is in a position to feed response from the authentic nameserver does so, it is in a position
a resolver fabricated data. When it does so, we dub it an attacker, to feed a resolver fabricated data. When it does so, we dub it an
attempting to spoof in fake data. attacker, attempting to spoof in fake data.
All conditions mentioned above can theoretically be met by a third All conditions mentioned above can theoretically be met by a third
party, with the difficulty being a function of the resolver party, with the difficulty being a function of the resolver
implementation and zone configuration. implementation and zone configuration.
4. Details 4. Detailed Description of Spoofing Scnearios
The previous paragraph discussed a number of requirements an attacker The previous paragraph discussed a number of requirements an attacker
must match in order to spoof in manipulated (or fake) data. This must match in order to spoof in manipulated (or fake) data. This
section discusses the relative difficulties and how implementation section discusses the relative difficulties and how implementation
defined choices impact the amount of work an attacker has to perform defined choices impact the amount of work an attacker has to perform
to meet said difficulties. to meet said difficulties.
Some more details can be found in section 2.2 of [RFC3833]. Some more details can be found in section 2.2 of [RFC3833].
4.1. Forcing a question 4.1. Forcing a question
Formally, there is no need for a nameserver to perform service except Formally, there is no need for a nameserver to perform service except
for its operator, its customers or more generally its users. for its operator, its customers or more generally its users.
Recently, open recursing nameservers have been used to amplify denial Recently, open recursing nameservers have been used to amplify denial
of service attacks. 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 Providing full service enables the third party to send the target
resolver a question for the domain name it intends to spoof. On resolver a question for the domain name it intends to spoof. On
receiving this question, and not finding the answer in its cache, the receiving this question, and not finding the answer in its cache, the
resolver will transmit questions to relevant authoritative resolver will transmit queries to relevant authoritative nameservers.
nameservers. This opens up a window of opportunity for getting fake This opens up a window of opportunity for getting fake answer data
answer data accepted. accepted.
Queries may however be forced indirectly, for example by inducing a
mail server to perform DNS lookups.
Some operators restrict access by not recursing for unauthorised IP Some operators restrict access by not recursing for unauthorised IP
addresses, but only respond with data from the cache. This makes addresses, but only respond with data from the cache. This makes
spoofing harder for a third party as it cannot then force the exact 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 moment a question will be asked. It is still possible however to
determine a time range when this will happen, because nameservers determine a time range when this will happen, because nameservers
helpfully publish the decreasing TTL of entries in the cache, which helpfully publish the decreasing TTL of entries in the cache, which
indicate from which absolute time onwards a new query could be sent indicate from which absolute time onwards a new query could be sent
to refresh the expired entry. to refresh the expired entry.
The time to live of the 'target domain' determines how often a window The time to live of the target domain name's RRSETs determines how
of opportunity is available, which implies that a short TTL makes often a window of opportunity is available, which implies that a
spoofing far more viable. short TTL makes spoofing far more viable.
Note that the attacker might very well have authorised access to the Note that the attacker might very well have authorised access to the
target resolver by virtue of being a customer or employee of its target resolver by virtue of being a customer or employee of its
operator. operator. In addition, access may be enabled through the use of
reflectors as outlined in [I-D.ietf-dnsop-reflectors-are-evil].
4.2. Matching the question section 4.2. Matching the question section
DNS packets, both queries and answers, contain a question section. DNS packets, both queries and responses, contain a question section.
Incoming answers should be verified to have a question section that Incoming responses should be verified to have a question section that
is equivalent to that of the outgoing query. is equivalent to that of the outgoing query.
4.3. Matching the ID field 4.3. Matching the ID field
The DNS ID field is 16 bits wide, meaning that if full use is made of 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 all these bits, and if their contents are truly random, it will
require on average 32768 attempts to guess. Anecdotal evidence require on average 32768 attempts to guess. Anecdotal evidence
suggests there are implementations utilising only 14 bits, meaning on suggests there are implementations utilising only 14 bits, meaning on
average 8192 attempts will suffice. average 8192 attempts will suffice.
Additionally, if the target nameserver can be forced into having Additionally, if the target nameserver can be forced into having
multiple identical questions outstanding, the 'Birthday Attack' multiple identical queries outstanding, the 'Birthday Attack'
phenomenon means that any fake data sent by the attacker is matched phenomenon means that any fake data sent by the attacker is matched
against multiple outstanding questions, significantly raising the against multiple outstanding queries, significantly raising the
chance of success. Further details in Section 5. chance of success. Further details in Section 5.
4.4. Matching the source address of the authentic answer 4.4. Matching the source address of the authentic response
Most domains have two or three authoritative nameservers, which make It should be noted that meeting this condition entails being able to
matching the source address of the authentic answer very likely with transmit packets on behalf of the address of the authoritative
even a naive choice having a double digit success rate. nameserver. While two Best Current Practice 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.
Many zones have two or three authoritative nameservers, which make
matching the source address of the authentic response very likely
with even a naive choice having a double digit success rate.
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 4.5. Matching the destination address and port of the authentic
transmit packets on behalf of the address of the authoritative response
nameserver. While two Best Current Practice 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.5. 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 response 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 an arbitrary port at startup (possibly at random) and resolvers pick an arbitrary port at startup (possibly at random) and
use this for all outgoing questions. In quite a number of cases the use this for all outgoing questions. In quite a number of cases the
source port of outgoing questions is fixed at the traditional DNS source port of outgoing questions is fixed at the traditional DNS
assigned server port number of 53. 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 ID space by a factor equal to the number of ports used.
used.
Less common resolving servers choose a random port per outgoing Less common resolving servers choose a random port per outgoing
question. If this strategy is followed, this port number can be question. If this strategy is followed, this port number can be
regarded as an additional ID field, again containing up to 16 bits. regarded as an additional ID field, again containing up to 16 bits.
If the maximum ports range is utilized, on average, around 32128 If the maximum ports range is utilized, on average, around 32128
source ports would have to be tried before matching the source port source ports would have to be tried before matching the source port
of the original question as ports below 1024 may be unavailable for of the original question as ports below 1024 may be unavailable for
use, leaving 64512 options. use, leaving 64512 options.
It should be noted that a firewall will not prevent the matching of 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 this address, as it will accept answers that (appear) to come from
the correct address, offering no additional security. the correct address, offering no additional security.
4.6. Have the answer arrive before the authentic answer 4.6. Have the response arrive before the authentic response
Once any packet has matched the previous four conditions (plus Once any packet has matched the previous four conditions (plus
possible additional conditions), no further answers are generally possible additional conditions), no further responses are generally
accepted. accepted.
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 response. For calculations we will assume a window in
(depending on the network distance to the authentic authoritative order of at most 100ms (depending on the network distance to the
nameserver). authentic authoritative nameserver).
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
The so called birthday paradox implies that a group of 23 people The so called birthday paradox implies that a group of 23 people
suffices to have a more than even chance of 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 exact phenomenon if it can force An attacker can benefit from this exact phenomenon if it can force
the target resolver to have multiple equivalent outstanding questions the target resolver to have multiple equivalent outstanding queries
at any one time to the same authoritative server. at any one time 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 queries and responses, 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 queries are sent out, the chance of
successfully spoofing an answer rises linearly with the number of successfully spoofing a response rises linearly with the number of
outstanding questions for the exact domain and nameserver. outstanding queries 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 records
Answers from authoritative nameservers often contain information that Responses from authoritative nameservers often contain information
is not part of the zone for which we deem it authoritative. As an that is not part of the zone for which we deem it authoritative. As
example, a query for the MX record of a domain might get as its 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 responses a mail exchanger in another domain, and additionally the IP
address of this mail exchanger. address of this mail exchanger.
If accepted uncritically, the resolver stands the chance of accepting If accepted uncritically, the resolver stands the chance of accepting
data from an untrusted source. Care must be taken to only accept 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 if it is known that the originator is authoritative for that
data. data.
One very simple way to achieve this is to only accept data if it is One very simple way to achieve this is to only accept data if it is
part of the domain we asked the question for. part of the domain the query was for.
7. Combined difficulty 7. Combined difficulty
Given a known or static destination port, matching ID field, source Given a known or static destination port, matching ID field, source
and destination address requires on average in the order of 2 * 2^15 and destination address requires on average in the order of 2 * 2^15
= 65000 packets, assuming a domain has 2 authoritative nameservers. = 65000 packets, assuming a domain has 2 authoritative nameservers.
If the window of opportunity available is around 100ms, as assumed If the window of opportunity available is around 100ms, as assumed
above, an attacker would need to be able to briefly transmit 650000 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 packets/s to have a 50% chance to get spoofed data accepted on the
first attempt. first attempt.
A realistic minimal DNS answer consists of around 80 bytes, including A realistic minimal DNS response consists of around 80 bytes,
IP headers, making the packet rate above correspond to a respectable including IP headers, making the packet rate above correspond to a
burst of 416Mb/s. respectable 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 response can be
by overloading the bonafide authoritative hosts with decoy questions. prevented by overloading the bonafide authoritative hosts with decoy
This reduces the needed bandwidth to 42 Mb/s. queries. 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 queries to authoritative nameservers, opening
opening windows of opportunity. windows of opportunity.
7.1. Symbols used in calculation 7.1. Symbols used in calculation
Assume the following symbols are used: Assume the following symbols are used:
I: Number distinct IDs available (maximum 65536) I: Number distinct IDs available (maximum 65536)
P: Number of ports used (maximum around 64000 as ports under 1024 P: Number of ports used (maximum around 64000 as ports under 1024
are not always available, but often 1) are not always available, but often 1)
N: Number of authoritative nameservers for a domain (averages N: Number of authoritative nameservers for a domain (averages
around 2.5) around 2.5)
F: Number of 'fake' packets sent by the attacker F: Number of 'fake' packets sent by the attacker
R: Number of packets sent per second by the attacker R: Number of packets sent per second by the attacker
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 queries 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 the 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 queries,
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 queries. 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:
D * F D * F
P_s = --------- P_s = ---------
N * P * I N * P * I
It is more useful to reason not in terms of aggregate packets but to 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 convert to packet rate, which can easily be converted to bandwidth if
skipping to change at page 14, line 27 skipping to change at page 14, line 27
( R ) ( R )
P_cs = 1 - ( 1 - ------- ) P_cs = 1 - ( 1 - ------- )
( 1638400 ) ( 1638400 )
From this formula it can be seen that, if the nameserver From this formula it can be seen that, if the nameserver
implementation is unchanged, only raising the TTL offers protection. implementation is unchanged, only raising the TTL offers protection.
Raising N, the number of authoritative nameservers, is not feasible Raising N, the number of authoritative nameservers, is not feasible
beyond a small number. beyond a small number.
For the degenerate case of a zero-second TTL, a window of opportunity 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' opens for each query sent, making the effective TTL equal to 'W'
above, the response time of the authoritative server. above, the response time of the authoritative server.
8. Discussion 8. Discussion
The calculations above indicate the relative ease with which DNS data The calculations above indicate the relative ease with which DNS data
can be spoofed. For example, using the formula derived earlier on a can be spoofed. For example, using the formula derived earlier on a
domain with a 3600 second TTL, an attacker sending 7000 fake answer domain with a 3600 second TTL, an attacker sending 7000 fake response
packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a 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. 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 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. minutes, 50% after less than 3 hours, 90% after around 9 hours.
Note that the attacks mentioned above can be detected by watchful Note that the attacks mentioned above can be detected by watchful
server operators - an unexpected incoming stream of 4.5mbit/s of server operators - an unexpected incoming stream of 4.5mbit/s of
packets might be noticed. packets might be noticed.
An important assumption however in these calculations is a known or An important assumption however in these calculations is a known or
static destination port of the authentic answer. static destination port of the authentic response.
If that port number is unknown and needs to be guessed as well, the 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 problem space expands by a factor of 64000, leading the attacker to
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. Recommended ountermeasures
Given the above, a resolver implementation MUST match answers to the Given the above, a resolver implementation MUST match responses to
following attributes of the question: the following attributes of the query:
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 name (compared case-insensitively) o Question name (compared case-insensitively)
o Question class and type o Question class and type
before applying DNS trustworthiness rules. A mismatch should be before applying DNS trustworthiness rules (see [RFC2181], section
considered a format error, and the answer invalid. 5.4.1). More precisely, the response source IP address MUST match
the query's destination IP address and the response destination IP
address MUST match the query's source IP address. A mismatch should
be considered a format error, and the response invalid.
Resolver implementations MUST have the ability to: 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 the
(53, or > 1024) of ports that is as large as possible and range (53, or > 1024) of available ports that is as large as
practicable; possible and practicable;
o Use multiple different source ports simultaneously in case of o Use multiple different source ports simultaneously in case of
multiple outstanding questions; multiple outstanding queries;
o Use an unpredictable query ID for outgoing queries, utilizing the o Use an unpredictable query ID for outgoing queries, utilizing the
full range available (0-65535); full range available (0-65535);
Please note that source ports could be selected from a larger range
than indicated, but that this range is regarded as safe, with some
lower port numbers reserved for activities which might conflict with
proper DNS operation.
In case these abilities are enabled, the implementation MUST strive In case these abilities are enabled, the implementation MUST strive
to have its choices of source port and question ID remain to have its choices of source port and query ID remain unpredictable,
unpredictable, even if an attacker has knowledge of its even if an attacker has knowledge of its (pseudo-)random generator.
(pseudo-)random generator.
If a resolver is multihomed or otherwise has the ability to transmit If a resolver is multihomed or otherwise has the ability to transmit
and receive datagrams using more than one IP source address, then an and receive datagrams using more than one IP source address, then an
IP address can be chosen at random in order to increase an attacker's IP address can be chosen at random in order to increase an attacker's
difficulty in guessing what address to flood. difficulty in guessing what address to flood.
If a resolver sends out multiple equivalent questions to any If a resolver sends out multiple equivalent queries to any
authoritative server, before receiving an answer, all MUST have authoritative server, before receiving a response, all MUST have
identical ID, source address and source port. identical ID, source address and source port.
Resolvers SHOULD favour authoritative nameservers with which a trust Resolvers SHOULD favour authoritative nameservers with which a trust
relation has been established; Stub-resolvers SHOULD be able to use relation has been established; Stub-resolvers SHOULD be able to use
TSIG ([RFC2845]) or IPSEC ([RFC2401]) when communicating with their TSIG ([RFC2845]) or IPSEC ([RFC2401]) when communicating with their
recursive resolver. recursive resolver.
In case a cryptographic verification of answer validity is available, In case a cryptographic verification of response validity is
resolver implementations MAY waive above rules, and rely on this available, resolver implementations MAY waive above rules, and rely
guarantee instead. on this guarantee instead.
Proper unpredictability can be achieved by employing a high quality Proper unpredictability can be achieved by employing a high quality
random generator, as described in [RFC4086]. random generator, as described in [RFC4086].
If a resolver detects that an attempt is being made to spoof it,
perhaps by discovering that many packets fail the criteria as
outlined above, it MAY abandon the UDP query and re-issue it over
TCP. TCP, by the nature of its use of sequence numbers, is far more
resilient against forgery by third parties.
10. Security Considerations 10. Security Considerations
This document provides clarification of the DNS specification to This document provides clarification of the DNS specification to
decrease the probability that DNS answers can be successfully forged. decrease the probability that DNS responses can be successfully
Recommendations found above should be considered complementary to forged. Recommendations found above should be considered
possible cryptographical enhancements of the domain name system. complementary to possible cryptographical enhancements of the domain
name system.
This document recommends the use of UDP source port number
randomization to extend the effective DNS transaction ID beyond the
available 16 bits.
A resolver that does not implement the recommendations outlined above A resolver that does not implement the recommendations outlined above
can easily be forced to accept spoofed answers, which in turn are can easily be forced to accept spoofed responses, which in turn are
passed on to client computers - misdirecting (user) traffic to passed on to client computers - misdirecting (user) traffic to
possibly malicious entities. possibly malicious entities.
This document directly impacts the security of the Domain Name This document directly impacts the security of the Domain Name
System, implementers are urged to follow its recommendations. System, implementers are urged to follow its recommendations.
Most security considerations can be found in Section 5, while Most security considerations can be found in Section 5, while
proposed countermeasures are described in Section 9. proposed countermeasures are described in Section 9.
For brevity's sake, in lieu of repeating the security considerations For brevity's sake, in lieu of repeating the security considerations
skipping to change at page 20, line 5 skipping to change at page 20, line 5
Norbert Sendetzky, Norbert Sendetzky,
Paul Vixie, Paul Vixie,
Florian Weimer, Florian Weimer,
Wouter Wijngaards, Wouter Wijngaards,
Dan Wing Dan Wing
12. Normative References 12. References
12.1. 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 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Internet Protocol", RFC 2401, November 1998. Specification", RFC 2181, July 1997.
[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. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for DNS
skipping to change at page 20, line 44 skipping to change at page 20, line 46
[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 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
12.2. Informative References
[I-D.ietf-dnsop-reflectors-are-evil]
Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks",
draft-ietf-dnsop-reflectors-are-evil-05 (work in
progress), December 2007.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[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 44 skipping to change at line 798
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 74 change blocks. 
136 lines changed or deleted 168 lines changed or added

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