draft-ietf-dnsop-bad-dns-res-02.txt   draft-ietf-dnsop-bad-dns-res-03.txt 
DNS Operations M. Larson DNS Operations M. Larson
Internet-Draft P. Barber Internet-Draft P. Barber
Expires: January 17, 2005 VeriSign Expires: April 27, 2005 VeriSign
July 19, 2004 October 27, 2004
Observed DNS Resolution Misbehavior Observed DNS Resolution Misbehavior
draft-ietf-dnsop-bad-dns-res-02 draft-ietf-dnsop-bad-dns-res-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 17, 2005. This Internet-Draft will expire on April 27, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This memo describes DNS name server and resolver behavior that This memo describes DNS name server and resolver behavior that
results in a significant query volume sent to the root and top-level results in a significant query volume sent to the root and top-level
domain (TLD) name servers. In some cases we recommend minor domain (TLD) name servers. In some cases we recommend minor
additions to the DNS protocol specification and corresponding changes additions to the DNS protocol specification and corresponding changes
in iterative resolver implementations to alleviate these unnecessary in iterative resolver implementations to alleviate these unnecessary
queries. The recommendations made in this document are a direct queries. The recommendations made in this document are a direct
byproduct of observation and analysis of abnormal query traffic byproduct of observation and analysis of abnormal query traffic
skipping to change at page 2, line 11 skipping to change at page 2, line 15
thirteen com/net TLD name servers. thirteen com/net TLD name servers.
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 RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 A note about terminology in this memo . . . . . . . . . . 3 1.1 A note about terminology in this memo . . . . . . . . . . 3
2. Observed name server misbehavior . . . . . . . . . . . . . . 5 2. Observed iterative resolver misbehavior . . . . . . . . . . 5
2.1 Aggressive requerying for delegation information . . . . . 5 2.1 Aggressive requerying for delegation information . . . . . 5
2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . 6 2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . 6
2.2 Repeated queries to lame servers . . . . . . . . . . . . . 6 2.2 Repeated queries to lame servers . . . . . . . . . . . . . 6
2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . 7 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . 7
2.3 Inability to follow multiple levels of out-of-zone glue . 7 2.3 Inability to follow multiple levels of out-of-zone glue . 7
2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . 8 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . 8
2.4 Aggressive retransmission when fetching glue . . . . . . . 8 2.4 Aggressive retransmission when fetching glue . . . . . . . 8
2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . 9 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . 9
2.5 Aggressive retransmission behind firewalls . . . . . . . . 9 2.5 Aggressive retransmission behind firewalls . . . . . . . . 9
2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . 9 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . 10
2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 10 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 10
2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . 11 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . 11
2.7 Name server records with zero TTL . . . . . . . . . . . . 11 2.7 Name server records with zero TTL . . . . . . . . . . . . 11
2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . 12 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . 12
2.8 Unnecessary dynamic update messages . . . . . . . . . . . 12 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 12
2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13
2.9 Queries for domain names resembling IP addresses . . . . . 13 2.9 Queries for domain names resembling IP addresses . . . . . 13
2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13
2.10 Misdirected recursive queries . . . . . . . . . . . . . 14 2.10 Misdirected recursive queries . . . . . . . . . . . . . 14
2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . 14 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 3, line 17 skipping to change at page 3, line 17
Observation of query traffic received by two root name servers and Observation of query traffic received by two root name servers and
the thirteen com/net TLD name servers has revealed that a large the thirteen com/net TLD name servers has revealed that a large
proportion of the total traffic often consists of "requeries". A proportion of the total traffic often consists of "requeries". A
requery is the same question (<qname, qtype, qclass>) asked requery is the same question (<qname, qtype, qclass>) asked
repeatedly at an unexpectedly high rate. We have observed requeries repeatedly at an unexpectedly high rate. We have observed requeries
from both a single IP address and multiple IP addresses (i.e., the from both a single IP address and multiple IP addresses (i.e., the
same query received simultaneously from multiple IP addresses). same query received simultaneously from multiple IP addresses).
By analyzing requery events we have found that the cause of the By analyzing requery events we have found that the cause of the
duplicate traffic is almost always a deficient iterative resolver, duplicate traffic is almost always a deficient iterative resolver,
stub resolver and/or application implementation combined with an stub resolver or application implementation combined with an
operational anomaly. The implementation deficiencies we have operational anomaly. The implementation deficiencies we have
identified to date include well-intentioned recovery attempts gone identified to date include well-intentioned recovery attempts gone
awry, insufficient caching of failures, early abort when multiple awry, insufficient caching of failures, early abort when multiple
levels of glue records must be followed, and aggressive retry by stub levels of glue records must be followed, and aggressive retry by stub
resolvers and/or applications. Anomalies that we have seen trigger resolvers or applications. Anomalies that we have seen trigger
requery events include lame delegations, unusual glue records, and requery events include lame delegations, unusual glue records, and
anything that makes all authoritative name servers for a zone anything that makes all authoritative name servers for a zone
unreachable (DoS attacks, crashes, maintenance, routing failures, unreachable (DoS attacks, crashes, maintenance, routing failures,
congestion, etc.). congestion, etc.).
In the following sections, we provide a detailed explanation of the In the following sections, we provide a detailed explanation of the
observed behavior and recommend changes that will reduce the requery observed behavior and recommend changes that will reduce the requery
rate. Some of the changes recommended affect the core DNS protocol rate. Some of the changes recommended affect the core DNS protocol
specification, described principally in RFC 1034 [2], RFC 1035 [3] specification, described principally in RFC 1034 [2], RFC 1035 [3]
and RFC 2181 [4]. and RFC 2181 [4].
1.1 A note about terminology in this memo 1.1 A note about terminology in this memo
To recast an old saying about standards, the nice thing about DNS To recast an old saying about standards, the nice thing about DNS
terms is that there are so many of them to choose from. Writing or terms is that there are so many of them to choose from. Writing or
talking about DNS can be difficult and cause confusion resulting from talking about DNS can be difficult and cause confusion resulting from
a lack of agreed-upon terms for its various components. Further a lack of agreed-upon terms for its various components. Further
complicating matters are implementations that combine multiple roles complicating matters are implementations that combine multiple roles
into one piece of software, which makes naming the result into one piece of software, which makes naming the result
problematic. An example is the entity that accepts recursive problematic. An example is the entity that accepts recursive
queries, issues iterative queries as necessary to resolve them, queries, issues iterative queries as necessary to resolve the initial
caches responses it receives, and which is also able answer questions recursive query, caches responses it receives, and which is also able
about certain zones authoritatively. Often called a "recursive name answer questions about certain zones authoritatively. Often called a
server" or a "caching name server", it is in fact an iterative "recursive name server" or a "caching name server", it is in fact an
resolver combined with an authoritative name server. iterative resolver combined with an authoritative name server.
This memo is concerned principally with the behavior of iterative This memo is concerned principally with the behavior of iterative
resolvers, which are typically found as part of a recursive name resolvers, which are typically found as part of a recursive name
server. This memo uses the more precise term "iterative resolver", server. This memo uses the more precise term "iterative resolver",
because the focus is usually on that component, rather than the more because the focus is usually on that component. In instances where
general term "recursive name server". the name server role of this entity requires mentioning, this memo
uses the term "recursive name server". For example, the name server
component of a recursive name server receives DNS queries and the
iterative resolver component sends queries.
The advent of IPv6 requires mentioning AAAA records as well as A The advent of IPv6 requires mentioning AAAA records as well as A
records when discussing glue. To avoid continuous repetition and records when discussing glue. To avoid continuous repetition and
qualification, this memo uses the general term "address records" to qualification, this memo uses the general term "address records" to
encompass both A and AAAA records when a particular situation is encompass both A and AAAA records when a particular situation is
relevant to both types. relevant to both types.
2. Observed name server misbehavior 2. Observed iterative resolver misbehavior
2.1 Aggressive requerying for delegation information 2.1 Aggressive requerying for delegation information
There can be times when every name server in a zone's NS RRset is There can be times when every name server in a zone's NS RRset is
unreachable (e.g., during a network outage), unavailable (e.g., the unreachable (e.g., during a network outage), unavailable (e.g., the
name server process is not running on the server host) or name server process is not running on the server host) or
misconfigured (e.g., the name server is not authoritative for the misconfigured (e.g., the name server is not authoritative for the
given zone, also known as "lame"). Consider an iterative resolver given zone, also known as "lame"). Consider an iterative resolver
that attempts to resolve a query for a domain name in such a zone and that attempts to resolve a query for a domain name in such a zone and
discovers that none of the zone's name servers can provide an answer. discovers that none of the zone's name servers can provide an answer.
We have observed an iterative resolver implementation that then We have observed a recursive name server implementation whose
verifies the zone's NS RRset in its cache by querying for the zone's iterative resolver then verifies the zone's NS RRset in its cache by
delegation information: it sends a query for the zone's NS RRset to querying for the zone's delegation information: it sends a query for
one of the parent zone's name servers. the zone's NS RRset to one of the parent zone's name servers.
For example, suppose that "example.com" has the following NS RRset: For example, suppose that "example.com" has the following NS RRset:
example.com. IN NS ns1.example.com. example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com. example.com. IN NS ns2.example.com.
Upon receipt of a query for "www.example.com" and assuming that Upon receipt of a query for "www.example.com" and assuming that
neither "ns1.example.com" nor "ns2.example.com" can provide an neither "ns1.example.com" nor "ns2.example.com" can provide an
answer, this iterative resolver implementation immediately queries a answer, this iterative resolver implementation immediately queries a
"com" zone name server for the "example.com" NS RRset to verify it "com" zone name server for the "example.com" NS RRset to verify it
has the proper delegation information. This name server has the proper delegation information. This implementation performs
implementation performs this query to a zone's parent zone for each this query to a zone's parent zone for each recursive query it
recursive query it receives that fails because of a completely receives that fails because of a completely unresponsive set of name
unresponsive set of name servers for the target zone. Consider the servers for the target zone. Consider the effect when a popular zone
effect when a popular zone experiences a catastrophic failure of all experiences a catastrophic failure of all its name servers: now every
its name servers: now every recursive query for domain names in that recursive query for domain names in that zone sent to this recursive
zone sent to this name server implementation results in a query to name server implementation results in a query to the failed zone's
the failed zone's parent name servers. On one occasion when several parent name servers. On one occasion when several dozen popular
dozen popular zones became unreachable, the query load on the com/net zones became unreachable, the query load on the com/net name servers
name servers increased by 50%. increased by 50%.
We believe this verification query is not reasonable. Consider the We believe this verification query is not reasonable. Consider the
circumstances: When an iterative resolver is resolving a query for a circumstances: When an iterative resolver is resolving a query for a
domain name in a zone it has not previously searched, it uses the domain name in a zone it has not previously searched, it uses the
list of name servers in the referral from the target zone's parent. list of name servers in the referral from the target zone's parent.
If on its first attempt to search the target zone, none of the name If on its first attempt to search the target zone, none of the name
servers in the referral is reachable, a verification query to the servers in the referral is reachable, a verification query to the
parent is pointless: this query to the parent would come so quickly parent is pointless: this query to the parent would come so quickly
on the heels of the referral that it would be almost certain to on the heels of the referral that it would be almost certain to
contain the same list of name servers. The chance of discovering any contain the same list of name servers. The chance of discovering any
new information is slim. new information is slim.
The other possibility is that the iterative resolver successfully The other possibility is that the iterative resolver successfully
contacts one of the target zone's name servers and then caches the NS contacts one of the target zone's name servers and then caches the NS
RRset from the authority section of a response, the proper behavior RRset from the authority section of a response, the proper behavior
according to section 5.4.1 of RFC 2181 [4], because the NS RRset from according to section 5.4.1 of RFC 2181 [4], because the NS RRset from
the target zone is more trustworthy than delegation information from the target zone is more trustworthy than delegation information from
the parent zone. If, while processing a subsequent recursive query, the parent zone. If, while processing a subsequent recursive query,
the recursing name server discovers that none of the name servers the iterative resolver discovers that none of the name servers
specified in the cached NS RRset is available or authoritative, specified in the cached NS RRset is available or authoritative,
querying the parent would be wrong. An NS RRset from the parent zone querying the parent would be wrong. An NS RRset from the parent zone
would now be less trustworthy than data already in the cache. would now be less trustworthy than data already in the cache.
For this query of the parent zone to be useful, the target zone's For this query of the parent zone to be useful, the target zone's
entire set of name servers would have to change AND the former set of entire set of name servers would have to change AND the former set of
name servers would have to be deconfigured and/or decommissioned AND name servers would have to be deconfigured or decommissioned AND the
the delegation information in the parent zone would have to be delegation information in the parent zone would have to be updated
updated with the new set of name servers, all within the TTL of the with the new set of name servers, all within the TTL of the target
target zone's NS RRset. We believe this scenario is uncommon: zone's NS RRset. We believe this scenario is uncommon:
administrative best practices dictate that changes to a zone's set of administrative best practices dictate that changes to a zone's set of
name servers happen gradually, with servers that are removed from the name servers happen gradually when at all possible, with servers
NS RRset left authoritative for the zone as long as possible. The removed from the NS RRset left authoritative for the zone as long as
scenarios that we can envision that would benefit from the parent possible. The scenarios that we can envision that would benefit from
requery behavior do not outweigh its damaging effects. the parent requery behavior do not outweigh its damaging effects.
2.1.1 Recommendation 2.1.1 Recommendation
Name servers offering recursion MUST NOT send a query for the NS An iterative resolver MUST NOT send a query for the NS RRset of a
RRset of a non-responsive zone to any of the name servers for that non-responsive zone to any of the name servers for that zone's parent
zone's parent zone. For the purposes of this injunction, a zone. For the purposes of this injunction, a non-responsive zone is
non-responsive zone is defined as a zone for which every name server defined as a zone for which every name server listed in the zone's NS
listed in the zone's NS RRset: RRset:
1. is not authoritative for the zone (i.e., lame), or, 1. is not authoritative for the zone (i.e., lame), or,
2. returns a server failure response (RCODE=2), or, 2. returns a server failure response (RCODE=2), or,
3. is dead or unreachable according to section 7.2 of RFC 2308 [5]. 3. is dead or unreachable according to section 7.2 of RFC 2308 [5].
2.2 Repeated queries to lame servers 2.2 Repeated queries to lame servers
Section 2.1 describes a catastrophic failure: when every name server Section 2.1 describes a catastrophic failure: when every name server
for a zone is unable to provide an answer for one reason or another. for a zone is unable to provide an answer for one reason or another.
A more common occurrence is a subset of a zone's name servers being A more common occurrence is when a subset of a zone's name servers
unavailable or misconfigured. Different failure modes have different are unavailable or misconfigured. Different failure modes have
expected durations. Some symptoms indicate problems that are different expected durations. Some symptoms indicate problems that
potentially transient: various types of ICMP unreachable messages are potentially transient; for example, various types of ICMP
because a name server process is not running or a host or network is unreachable messages because a name server process is not running or
unreachable, or a complete lack of a response to a query. Such a host or network is unreachable, or a complete lack of a response to
responses could be the result of a host rebooting or temporary a query. Such responses could be the result of a host rebooting or
outages; these events don't necessarily require any human temporary outages; these events don't necessarily require any human
intervention and can be reasonably expected to be temporary. intervention and can be reasonably expected to be temporary.
Other symptoms clearly indicate a condition requiring human Other symptoms clearly indicate a condition requiring human
intervention, such as lame server: if a name server is misconfigured intervention, such as lame server: if a name server is misconfigured
and not authoritative for a zone delegated to it, it is reasonable to and not authoritative for a zone delegated to it, it is reasonable to
assume that this condition has potential to last longer than assume that this condition has potential to last longer than
unreachability or unresponsiveness. Consequently, repeated queries unreachability or unresponsiveness. Consequently, repeated queries
to known lame servers are not useful. In this case of a condition to known lame servers are not useful. In this case of a condition
with potential to persist for a long time, a better practice would be with potential to persist for a long time, a better practice would be
to maintain a list of known lame servers and avoid querying them to maintain a list of known lame servers and avoid querying them
skipping to change at page 7, line 40 skipping to change at page 7, line 40
foo.example. IN NS ns1.example.com. foo.example. IN NS ns1.example.com.
foo.example. IN NS ns2.example.com. foo.example. IN NS ns2.example.com.
example.com. IN NS ns1.test.example.net. example.com. IN NS ns1.test.example.net.
example.com. IN NS ns2.test.example.net. example.com. IN NS ns2.test.example.net.
test.example.net. IN NS ns1.test.example.net. test.example.net. IN NS ns1.test.example.net.
test.example.net. IN NS ns2.test.example.net. test.example.net. IN NS ns2.test.example.net.
A name server processing a recursive query for "www.foo.example" must An iterative resolver resolving the name "www.foo.example" must
follow two levels of indirection, first obtaining address records for follow two levels of indirection, first obtaining address records for
"ns1.test.example.net" and/or "ns2.test.example.net" in order to "ns1.test.example.net" or "ns2.test.example.net" in order to obtain
obtain address records for "ns1.example.com" and/or "ns2.example.com" address records for "ns1.example.com" or "ns2.example.com" in order
in order to query those name servers for the address records of to query those name servers for the address records of
"www.foo.example". While this situation may appear contrived, we "www.foo.example". While this situation may appear contrived, we
have seen multiple similar occurrences and expect more as new generic have seen multiple similar occurrences and expect more as new generic
top-level domains (gTLDs) become active. We anticipate many zones in top-level domains (gTLDs) become active. We anticipate many zones in
the new gTLDs will use name servers in other gTLDs, increasing the new gTLDs will use name servers in other gTLDs, increasing the amount
amount of inter-zone glue. of inter-zone glue.
2.3.1 Recommendation 2.3.1 Recommendation
Clearly constructing a delegation that relies on multiple levels of Clearly constructing a delegation that relies on multiple levels of
out-of-zone glue is not a good administrative practice. This issue out-of-zone glue is not a good administrative practice. This issue
could be mitigated with an operational injunction in an RFC to could be mitigated with an operational injunction in an RFC to
refrain from construction of such delegations. In our opinion the refrain from construction of such delegations. In our opinion the
practice is widespread enough to merit clarifications to the DNS practice is widespread enough to merit clarifications to the DNS
protocol specification to permit it on a limited basis. protocol specification to permit it on a limited basis.
Name servers offering recursion SHOULD be able to handle at least Iterative resolvers SHOULD be able to handle at least three levels of
three levels of indirection resulting from out-of-zone glue. indirection resulting from out-of-zone glue.
2.4 Aggressive retransmission when fetching glue 2.4 Aggressive retransmission when fetching glue
When an authoritative name server responds with a referral, it When an authoritative name server responds with a referral, it
includes NS records in the authority section of the response. includes NS records in the authority section of the response.
According to the algorithm in section 4.3.2 of RFC 1034 [2], the name According to the algorithm in section 4.3.2 of RFC 1034 [2], the name
server should also "put whatever addresses are available into the server should also "put whatever addresses are available into the
additional section, using glue RRs if the addresses are not available additional section, using glue RRs if the addresses are not available
from authoritative data or the cache." Some name server from authoritative data or the cache." Some name server
implementations take this address inclusion a step further with a implementations take this address inclusion a step further with a
feature called "glue fetching". A name server that implements glue feature called "glue fetching". A name server that implements glue
fetching attempts to include A records for every NS record in the fetching attempts to include address records for every NS record in
authority section. If necessary, the name server issues multiple the authority section. If necessary, the name server issues multiple
queries of its own to obtain any missing address records. queries of its own to obtain any missing address records.
Problems with glue fetching can arise in the context of Problems with glue fetching can arise in the context of
"authoritative-only" name servers, which only serve authoritative "authoritative-only" name servers, which only serve authoritative
data and ignore requests for recursion. Such a server will not data and ignore requests for recursion. Such an entity will not
generate any queries of its own. Instead it answers non-recursive normally generate any queries of its own. Instead it answers
queries from resolvers looking for information in zones it serves. non-recursive queries from iterative resolvers looking for
With glue fetching enabled, however, an authoritative server will information in zones it serves. With glue fetching enabled, however,
generate queries whenever it needs to look up an unknown address an authoritative server invokes an iterative resolver to look up an
record to complete the additional section of a response. unknown address record to complete the additional section of a
response.
We have observed situations where a glue-fetching name server can We have observed situations where the iterative resolver of a
send queries that reach other name servers, but apparently is glue-fetching name server can send queries that reach other name
prevented from receiving the responses. For example, perhaps the servers, but is apparently prevented from receiving the responses.
name server is authoritative-only and therefore its administrators For example, perhaps the name server is authoritative-only and
expect it to receive only queries. Perhaps unaware of glue fetching therefore its administrators expect it to receive only queries and
and presuming that the name server will generate no queries, its not responses. Perhaps unaware of glue fetching and presuming that
the name server's iterative resolver will generate no queries, its
administrators place the name server behind a network device that administrators place the name server behind a network device that
prevents it from receiving responses. If this is the case, all prevents it from receiving responses. If this is the case, all
glue-fetching queries will go answered. glue-fetching queries will go answered.
We have observed name server implementations that retry excessively We have observed name server implementations whose iterative
when glue-fetching queries are unanswered. A single com/net name resolvers retry excessively when glue-fetching queries are
server has received hundreds of queries per second from a single name unanswered. A single com/net name server has received hundreds of
server. Judging from the specific queries received and based on queries per second from a single such source. Judging from the
additional analysis, we believe these queries result from overly specific queries received and based on additional analysis, we
aggressive glue fetching. believe these queries result from overly aggressive glue fetching.
2.4.1 Recommendation 2.4.1 Recommendation
Implementers whose name servers support glue fetching SHOULD take Implementers whose name servers support glue fetching SHOULD take
care to avoid sending queries at excessive rates. Implementations care to avoid sending queries at excessive rates. Implementations
SHOULD support throttling logic to detect when queries are sent but SHOULD support throttling logic to detect when queries are sent but
no responses are received. no responses are received.
2.5 Aggressive retransmission behind firewalls 2.5 Aggressive retransmission behind firewalls
A common occurrence and one of the largest sources of repeated A common occurrence and one of the largest sources of repeated
queries at the com/net and root name servers appears to result from queries at the com/net and root name servers appears to result from
resolvers behind misconfigured firewalls. In this situation, a resolvers behind misconfigured firewalls. In this situation, an
recursive name server is apparently allowed to send queries through a iterative resolver is apparently allowed to send queries through a
firewall to other name servers, but not receive the responses. The firewall to other name servers, but not receive the responses. The
result is more queries than necessary because of retransmission, all result is more queries than necessary because of retransmission, all
of which are useless because the responses are never received. Just of which are useless because the responses are never received. Just
as with the glue-fetching scenario described in Section 2.4, the as with the glue-fetching scenario described in Section 2.4, the
queries are sometimes sent at excessive rates. To make matters queries are sometimes sent at excessive rates. To make matters
worse, sometimes the responses, sent in reply to legitimate queries, worse, sometimes the responses, sent in reply to legitimate queries,
trigger an alarm on the originator's intrusion detection system. We trigger an alarm on the originator's intrusion detection system. We
are frequently contacted by administrators responding to such alarms are frequently contacted by administrators responding to such alarms
who believe our name servers are attacking their systems. who believe our name servers are attacking their systems.
Not only do some resolvers in this situation retransmit queries at an Not only do some resolvers in this situation retransmit queries at an
excessive rate, but they continue to do so for days or even weeks. excessive rate, but they continue to do so for days or even weeks.
This scenario could result from an organization with multiple This scenario could result from an organization with multiple
iterative resolvers, only a subset of whose traffic is improperly recursive name servers, only a subset of whose iterative resolvers'
filtered in this manner. Stub resolvers in the organization could be traffic is improperly filtered in this manner. Stub resolvers in the
configured to query multiple name servers. Consider the case where a organization could be configured to query multiple recursive name
stub resolver queries a filtered name server first. This name server servers. Consider the case where a stub resolver queries a filtered
sends one or more queries whose replies are filtered, so it can't recursive name server first. The iterative resolver of this
respond to the stub resolver, which times out. The resolver recursive name server sends one or more queries whose replies are
retransmits to a name server that is able to provide an answer. filtered, so it can't respond to the stub resolver, which times out.
Since resolution ultimately succeeds the underlying problem might not Then the stub resolver retransmits to a recursive name server that is
be recognized or corrected. A popular stub resolver has a very able to provide an answer. Since resolution ultimately succeeds the
aggressive retransmission schedule, including simultaneous queries to underlying problem might not be recognized or corrected. A popular
multiple name servers, which could explain how such a situation could stub resolver implementation has a very aggressive retransmission
persist without being detected. schedule, including simultaneous queries to multiple recursive name
servers, which could explain how such a situation could persist
without being detected.
2.5.1 Recommendation 2.5.1 Recommendation
The most obvious recommendation is that administrators SHOULD take The most obvious recommendation is that administrators SHOULD take
care not to place iterative resolvers behind a firewall that allows care not to place iterative resolvers behind a firewall that allows
queries to pass through but not the resulting replies. queries to pass through but not the resulting replies.
Name servers SHOULD take care to avoid sending queries at excessive Iterative resolvers SHOULD take care to avoid sending queries at
rates. Implementations SHOULD support throttling logic to detect excessive rates. Implementations SHOULD support throttling logic to
when queries are sent but no responses are received. detect when queries are sent but no responses are received.
2.6 Misconfigured NS records 2.6 Misconfigured NS records
Sometimes a zone administrator forgets to add the trailing dot on the Sometimes a zone administrator forgets to add the trailing dot on the
domain names in the RDATA of a zone's NS records. Consider this domain names in the RDATA of a zone's NS records. Consider this
fragment of the zone file for "example.com": fragment of the zone file for "example.com":
$ORIGIN example.com. $ORIGIN example.com.
example.com. 3600 IN NS ns1.example.com ; Note missing example.com. 3600 IN NS ns1.example.com ; Note missing
example.com. 3600 IN NS ns2.example.com ; trailing dots example.com. 3600 IN NS ns2.example.com ; trailing dots
skipping to change at page 10, line 31 skipping to change at page 10, line 37
return NS records with this incorrect RDATA in responses, including return NS records with this incorrect RDATA in responses, including
typically the authority section of every response containing records typically the authority section of every response containing records
from the "example.com" zone. from the "example.com" zone.
Now consider a typical sequence of queries. An iterative resolver Now consider a typical sequence of queries. An iterative resolver
attempting to resolve address records for "www.example.com" with no attempting to resolve address records for "www.example.com" with no
cached information for this zone will query a "com" authoritative cached information for this zone will query a "com" authoritative
server. The "com" server responds with a referral to the server. The "com" server responds with a referral to the
"example.com" zone, consisting of NS records with valid RDATA and "example.com" zone, consisting of NS records with valid RDATA and
associated glue records. (This example assumes that the associated glue records. (This example assumes that the
"example.com" zone information is correct in the "com" zone.) The "example.com" zone delegation information is correct in the "com"
iterative resolver caches the NS RRset from the "com" server and zone.) The iterative resolver caches the NS RRset from the "com"
follows the referral by querying one of the "example.com" server and follows the referral by querying one of the "example.com"
authoritative servers. This server responds with the authoritative servers. This server responds with the
"www.example.com" address record in the answer section and, "www.example.com" address record in the answer section and,
typically, the "example.com" NS records in the authority section and, typically, the "example.com" NS records in the authority section and,
if space in the message remains, glue address records in the if space in the message remains, glue address records in the
additional section. According to Section 5.4 of RFC 2181 [4], NS additional section. According to Section 5.4 of RFC 2181 [4], NS
records in the authority section of an authoritative answer are more records in the authority section of an authoritative answer are more
trustworthy than NS records from the authority section of a trustworthy than NS records from the authority section of a
non-authoritative answer. Thus the "example.com" NS RRset just non-authoritative answer. Thus the "example.com" NS RRset just
received from the "example.com" authoritative server displaces the received from the "example.com" authoritative server overrides the
"example.com" NS RRset received moments ago from the "com" "example.com" NS RRset received moments ago from the "com"
authoritative server. authoritative server.
But the "example.com" zone contains the erroneous NS RRset as shown But the "example.com" zone contains the erroneous NS RRset as shown
in the example above. Subsequent queries for names in "example.com" in the example above. Subsequent queries for names in "example.com"
will cause the server to attempt to use the incorrect NS records and will cause the iterative resolver to attempt to use the incorrect NS
so the server will try to resolve the nonexistent names records and so it will try to resolve the nonexistent names
"ns1.example.com.example.com" and "ns2.example.com.example.com". In "ns1.example.com.example.com" and "ns2.example.com.example.com". In
this example, since all of the zone's name servers are named in the this example, since all of the zone's name servers are named in the
zone itself (i.e., "ns1.example.com.example.com" and zone itself (i.e., "ns1.example.com.example.com" and
"ns2.example.com.example.com" both end in "example.com") and all are "ns2.example.com.example.com" both end in "example.com") and all are
bogus, the recursive server cannot reach any "example.com" name bogus, the iterative resolver cannot reach any "example.com" name
servers. Therefore attempts to resolve these names result in address servers. Therefore attempts to resolve these names result in address
record queries to the "com" authoritative servers. Queries for such record queries to the "com" authoritative servers. Queries for such
obviously bogus glue address records occur frequently at the com/net obviously bogus glue address records occur frequently at the com/net
name servers. name servers.
2.6.1 Recommendation 2.6.1 Recommendation
An authoritative server can detect this situation. A trailing dot An authoritative server can detect this situation. A trailing dot
missing from an NS record's RDATA always results by definition in a missing from an NS record's RDATA always results by definition in a
name server name that exists somewhere under the SOA of the zone the name server name that exists somewhere under the SOA of the zone the
NS record appears in. (Note that further levels of delegation are NS record appears in. Note that further levels of delegation are
possible, so a missing trailing dot could inadvertently create a name possible, so a missing trailing dot could inadvertently create a name
server name that actually exists in a subzone.) But in any case, the server name that actually exists in a subzone. But in any case, the
address record must be present in this zone, either as authoritative address record must still be present in this zone, either as
data or glue. authoritative data or glue.
An authoritative name server SHOULD report an error when one of a An authoritative name server SHOULD report an error when one of a
zone's NS records references a name server below the zone's SOA when zone's NS records references a name server below the zone's SOA when
a corresponding address record does not exist in the zone. a corresponding address record does not exist in the zone.
2.7 Name server records with zero TTL 2.7 Name server records with zero TTL
Sometimes a popular com/net subdomain's zone is configured with a TTL Sometimes a popular com/net subdomain's zone is configured with a TTL
of zero on the zone's NS records, which prohibits these records from of zero on the zone's NS records, which prohibits these records from
being cached and will result in a higher query volume to the zone's being cached and will result in a higher query volume to the zone's
authoritative servers. The zone's administrator should understand authoritative servers. The zone's administrator should understand
the consequences of such a configuration and provision resources the consequences of such a configuration and provision resources
accordingly. A zero TTL on the zone's NS RRset, however, carries accordingly. A zero TTL on the zone's NS RRset, however, carries
additional consequences beyond the zone itself: if a recursive name additional consequences beyond the zone itself: if an iterative
server cannot cache a zone's NS records because of a zero TTL, it resolver cannot cache a zone's NS records because of a zero TTL, it
will be forced to query that zone's parent's name servers each time will be forced to query that zone's parent's name servers each time
it resolves a name in the zone. The com/net authoritative servers do it resolves a name in the zone. The com/net authoritative servers do
see an increased query load when a popular com/net subdomain's zone see an increased query load when a popular com/net subdomain's zone
is configured with a TTL of zero on the zone's NS records. is configured with a TTL of zero on the zone's NS records.
A zero TTL on an RRset expected to change frequently is extreme but A zero TTL on an RRset expected to change frequently is extreme but
permissible. A zone's NS RRset is a special case, however, because permissible. A zone's NS RRset is a special case, however, because
changes to it must be coordinated with the zone's parent. In most changes to it must be coordinated with the zone's parent. In most
zone parent/child relationships we are aware of, there is typically zone parent/child relationships we are aware of, there is typically
some delay involved in effecting changes. Further, changes to the some delay involved in effecting changes. Further, changes to the
set of a zone's authoritative name servers (and therefore to the set of a zone's authoritative name servers (and therefore to the
zone's NS RRset) are typically relatively rare: providing reliable zone's NS RRset) are typically relatively rare: providing reliable
authoritative service requires a reasonably stable set of servers. authoritative service requires a reasonably stable set of servers.
Therefore an extremely low or zero TTL on a zone's NS RRset rarely Therefore an extremely low or zero TTL on a zone's NS RRset rarely
makes sense, except in anticipation of an upcoming change. In this makes sense, except in anticipation of an upcoming change. In this
case, when the zone's administrator has planned a change and does not case, when the zone's administrator has planned a change and does not
want recursive name servers throughout the Internet to cache the NS want iterative resolvers throughout the Internet to cache the NS
RRset for a long period of time, a low TTL is reasonable. RRset for a long period of time, a low TTL is reasonable.
2.7.1 Recommendation 2.7.1 Recommendation
Because of the additional load placed on a zone's parent's Because of the additional load placed on a zone's parent's
authoritative servers imposed by a zero TTL on a zone's NS RRset, authoritative servers resulting from a zero TTL on a zone's NS RRset,
under such circumstances authoritative name servers SHOULD issue a under such circumstances authoritative name servers SHOULD issue a
warning when loading a zone or refuse to load the zone altogether. warning when loading a zone or refuse to load the zone altogether.
2.8 Unnecessary dynamic update messages 2.8 Unnecessary dynamic update messages
The UPDATE message specified in RFC 2136 [6] allows an authorized The UPDATE message specified in RFC 2136 [6] allows an authorized
agent to update a zone's data on an authoritative name server using a agent to update a zone's data on an authoritative name server using a
DNS message sent over the network. Consider the case of an agent DNS message sent over the network. Consider the case of an agent
desiring to add a particular resource record. Because of zone cuts, desiring to add a particular resource record. Because of zone cuts,
the agent does not necessarily know the proper zone to which the the agent does not necessarily know the proper zone to which the
skipping to change at page 13, line 34 skipping to change at page 13, line 40
The root name servers receive a significant number of A record The root name servers receive a significant number of A record
queries where the qname is an IP address. The source of these queries where the qname is an IP address. The source of these
queries is unknown. It could be attributed to situations where a queries is unknown. It could be attributed to situations where a
user believes an application will accept either a domain name or an user believes an application will accept either a domain name or an
IP address in a given configuration option. The user enters an IP IP address in a given configuration option. The user enters an IP
address, but the application assumes any input is a domain name and address, but the application assumes any input is a domain name and
attempts to resolve it, resulting in an A record lookup. There could attempts to resolve it, resulting in an A record lookup. There could
also be applications that produce such queries in a misguided attempt also be applications that produce such queries in a misguided attempt
to reverse map IP addresses. to reverse map IP addresses.
These queries result in Name Error (RCODE=3) responses. A recursive These queries result in Name Error (RCODE=3) responses. An iterative
name server can negatively cache such responses, but each response resolver can negatively cache such responses, but each response
requires a separate cache entry, i.e., a negative cache entry for the requires a separate cache entry, i.e., a negative cache entry for the
domain name "192.0.2.1" does not prevent a subsequent query for the domain name "192.0.2.1" does not prevent a subsequent query for the
domain name "192.0.2.2". domain name "192.0.2.2".
2.9.1 Recommendation 2.9.1 Recommendation
It would be desirable for the root name servers not to have to answer It would be desirable for the root name servers not to have to answer
these queries: they unnecessarily consume CPU resources and network these queries: they unnecessarily consume CPU resources and network
bandwidth. One possibility is for iterative resolver implementations bandwidth. One possibility is for iterative resolver implementations
to produce the Name Error response directly. We suggest that to produce the Name Error response directly. We suggest that
implementors consider the option of synthesizing Name Error responses implementors consider the option of synthesizing Name Error responses
at the iterative resolver. The server could claim authority for at the iterative resolver. The server could claim authority for
synthesized TLD zones corresponding to the first octet of every synthesized TLD zones corresponding to the first octet of every
possible IP address, e.g. 1., 2., through 255. This behavior could possible IP address, e.g. 1., 2., through 255. This behavior could
be configurable in the (probably unlikely) event that numeric TLDs be configurable in the (probably unlikely) event that numeric TLDs
are ever put into use. are ever put into use.
Another option is to delegate these numeric TLDs from the root zone Another option is to delegate these numeric TLDs from the root zone
to a separate set of servers to absorb the traffic. The "black hole to a separate set of servers to absorb the traffic. The "black hole
servers" used by the <http://www.as112.net>, which are currently servers" used by the the AS 112
Project [8], which are currently
delegated the in-addr.arpa zones corresponding to RFC 1918 [7] delegated the in-addr.arpa zones corresponding to RFC 1918 [7]
private use address space, would be a possible choice to receive private use address space, would be a possible choice to receive
these delegations. these delegations.
2.10 Misdirected recursive queries 2.10 Misdirected recursive queries
The root name servers receive a significant number of recursive The root name servers receive a significant number of recursive
queries (i.e., queries with the RD bit set in the header). Since queries (i.e., queries with the RD bit set in the header). Since
none of the root servers offer recursion, the servers' response in none of the root servers offers recursion, the servers' response in
such a situation ignores the request for recursion and the response such a situation ignores the request for recursion and the response
probably does not contain the data the querier anticipated. Some of probably does not contain the data the querier anticipated. Some of
these queries result from users configuring stub resolvers to query a these queries result from users configuring stub resolvers to query a
root server. (This situation is not hypothetical: we have received root server. (This situation is not hypothetical: we have received
complaints from users when this configuration does not work as complaints from users when this configuration does not work as
hoped.) Of course, users should not direct stub resolvers to use name hoped.) Of course, users should not direct stub resolvers to use name
servers that do not offer recursion, but we are not aware of any stub servers that do not offer recursion, but we are not aware of any stub
resolver implementation that offers any feedback to the user when so resolver implementation that offers any feedback to the user when so
configured, aside from simply "not working". configured, aside from simply "not working".
2.10.1 Recommendation 2.10.1 Recommendation
When the IP address of a (supposedly) iterative resolver is When the IP address of a name server that supposedly offers recursion
configured in a stub resolver using an interactive user interface, is configured in a stub resolver using an interactive user interface,
the resolver could send a test query to verify that the server the resolver could send a test query to verify that the server indeed
supports recursion (i.e., the response has the RA bit set in the supports recursion (i.e., verify that the response has the RA bit set
header). The user could be immediately notified if the server is in the header). The user could be immediately notified if the server
non-recursive. is non-recursive.
The stub resolver could also report an error, either through a user The stub resolver could also report an error, either through a user
interface or in a log file, if the queried server does not support interface or in a log file, if the queried server does not support
recursion. Error reporting SHOULD be throttled to avoid a recursion. Error reporting SHOULD be throttled to avoid a
notification or log message for every response from a non-recursive notification or log message for every response from a non-recursive
server. server.
2.11 Suboptimal name server selection algorithm 2.11 Suboptimal name server selection algorithm
An entire document could be devoted to the topic of problems with An entire document could be devoted to the topic of problems with
skipping to change at page 15, line 22 skipping to change at page 15, line 28
2.11.1 Recommendation 2.11.1 Recommendation
This list is not conclusive, but reflects the changes that would This list is not conclusive, but reflects the changes that would
produce the most impact in terms of reducing disproportionate query produce the most impact in terms of reducing disproportionate query
load among a zone's authoritative servers. I.e., these changes would load among a zone's authoritative servers. I.e., these changes would
help spread the query load evenly. help spread the query load evenly.
o Do not make assumptions based on NS RRset order: all NS RRs SHOULD o Do not make assumptions based on NS RRset order: all NS RRs SHOULD
be treated equally. (In the case of the "com" zone, for example, be treated equally. (In the case of the "com" zone, for example,
most of the root servers return the NS record for most of the root servers return the NS record for
"a.gtld-servers.net" first in the authority section of referrals. "a.gtld-servers.net" first in the authority section of referrals.
As a result, this server receives disproportionately more traffic Apparently as a result, this server receives disproportionately
than the other 12 authoritative servers for "com".) more traffic than the other 12 authoritative servers for "com".)
o Use all NS records in an RRset. (For example, we are aware of o Use all NS records in an RRset. (For example, we are aware of
implementations that hard-coded information for a subset of the implementations that hard-coded information for a subset of the
root servers.) root servers.)
o Maintain state and favor the best-performing of a zone's o Maintain state and favor the best-performing of a zone's
authoritative servers. A good definition of performance is authoritative servers. A good definition of performance is
response time. Non-responsive servers can be penalized with an response time. Non-responsive servers can be penalized with an
extremely high response time. extremely high response time.
o Do not lock onto the best-performing of a zone's name servers. An o Do not lock onto the best-performing of a zone's name servers. An
iterative resolver SHOULD periodically check the performance of iterative resolver SHOULD periodically check the performance of
all of a zone's name servers to adjust its determination of the all of a zone's name servers to adjust its determination of the
skipping to change at page 18, line 36 skipping to change at page 18, line 36
2308, March 1998. 2308, March 1998.
[6] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic [6] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
1997. 1997.
[7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E.
Lear, "Address Allocation for Private Internets", BCP 5, RFC Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996. 1918, February 1996.
[8] <http://www.as112.net>
Authors' Addresses Authors' Addresses
Matt Larson Matt Larson
VeriSign, Inc. VeriSign, Inc.
21345 Ridgetop Circle 21345 Ridgetop Circle
Dulles, VA 20166-6503 Dulles, VA 20166-6503
USA USA
EMail: mlarson@verisign.com EMail: mlarson@verisign.com
Piet Barber Piet Barber
VeriSign, Inc. VeriSign, Inc.
21345 Ridgetop Circle 21345 Ridgetop Circle
Dulles, VA 20166-6503 Dulles, VA 20166-6503
USA USA
EMail: pbarber@verisign.com EMail: pbarber@verisign.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. 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 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 which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/