draft-ietf-dnsop-bad-dns-res-05.txt   draft-ietf-dnsop-bad-dns-res-06.txt 
DNS Operations M. Larson DNS Operations M. Larson
Internet-Draft P. Barber Internet-Draft P. Barber
Expires: August 14, 2006 VeriSign Expires: August 5, 2006 VeriSign
February 10, 2006 February 2006
Observed DNS Resolution Misbehavior Observed DNS Resolution Misbehavior
draft-ietf-dnsop-bad-dns-res-05 draft-ietf-dnsop-bad-dns-res-06
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 34 skipping to change at page 1, line 34
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 August 14, 2006. This Internet-Draft will expire on August 5, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This memo describes DNS iterative resolver behavior that results in a This memo describes DNS iterative resolver behavior that results in a
significant query volume sent to the root and top-level domain (TLD) significant query volume sent to the root and top-level domain (TLD)
name servers. We offer implementation advice to iterative resolver name servers. We offer implementation advice to iterative resolver
skipping to change at page 2, line 40 skipping to change at page 2, line 40
2.9. Queries for domain names resembling IPv4 addresses . . . . 14 2.9. Queries for domain names resembling IPv4 addresses . . . . 14
2.9.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14 2.9.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14
2.10. Misdirected recursive queries . . . . . . . . . . . . . . 15 2.10. Misdirected recursive queries . . . . . . . . . . . . . . 15
2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15 2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15
2.11. Suboptimal name server selection algorithm . . . . . . . . 15 2.11. Suboptimal name server selection algorithm . . . . . . . . 15
2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16 2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18
5. Security considerations . . . . . . . . . . . . . . . . . . . 19 5. Security considerations . . . . . . . . . . . . . . . . . . . 19
6. Internationalization considerations . . . . . . . . . . . . . 20 6. Internationalization considerations . . . . . . . . . . . . . 20
7. Informative References . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22 7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
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).
skipping to change at page 8, line 6 skipping to change at page 8, line 6
2.2.1. Recommendation 2.2.1. Recommendation
Iterative resolvers SHOULD cache name servers that they discover are Iterative resolvers SHOULD cache name servers that they discover are
not authoritative for zones delegated to them (i.e. lame servers). not authoritative for zones delegated to them (i.e. lame servers).
If this caching is performed, lame servers MUST be cached against the If this caching is performed, lame servers MUST be cached against the
specific query tuple <zone name, class, server IP address>. Zone specific query tuple <zone name, class, server IP address>. Zone
name can be derived from the owner name of the NS record that was name can be derived from the owner name of the NS record that was
referenced to query the name server that was discovered to be lame. referenced to query the name server that was discovered to be lame.
Implementations that perform lame server caching MUST refrain from Implementations that perform lame server caching MUST refrain from
sending queries to known lame servers based on a time interval from sending queries to known lame servers for a configurable time
when the server is discovered to be lame. A minimum interval of interval after the server is discovered to be lame. A minimum
thirty minutes is RECOMMENDED. interval of thirty minutes is RECOMMENDED.
An exception to this recommendation occurs if all name servers for a An exception to this recommendation occurs if all name servers for a
zone are marked lame. In that case, the iterative resolver SHOULD zone are marked lame. In that case, the iterative resolver SHOULD
temporarily ignore the servers' lameness status and query one or more temporarily ignore the servers' lameness status and query one or more
servers. This behavior is a workaround for the type-specific servers. This behavior is a workaround for the type-specific
lameness issue described in the previous section. lameness issue described in the previous section.
Implementors should take care not to make lame server avoidance logic Implementors should take care not to make lame server avoidance logic
overly broad: note that a name server could be lame for a parent zone overly broad: note that a name server could be lame for a parent zone
but not a child zone, e.g., lame for "example.com" but properly but not a child zone, e.g., lame for "example.com" but properly
skipping to change at page 10, line 5 skipping to change at page 10, line 5
We have observed situations where the iterative resolver of a glue- We have observed situations where the iterative resolver of a glue-
fetching name server can send queries that reach other name servers, fetching name server can send queries that reach other name servers,
but is apparently prevented from receiving the responses. For but is apparently prevented from receiving the responses. For
example, perhaps the name server is authoritative-only and therefore example, perhaps the name server is authoritative-only and therefore
its administrators expect it to receive only queries and not its administrators expect it to receive only queries and not
responses. Perhaps unaware of glue fetching and presuming that the responses. Perhaps unaware of glue fetching and presuming that the
name server's iterative resolver will generate no queries, its 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 glue- prevents it from receiving responses. If this is the case, all glue-
fetching queries will go answered. fetching queries will go unanswered.
We have observed name server implementations whose iterative We have observed name server implementations whose iterative
resolvers retry excessively when glue-fetching queries are resolvers retry excessively when glue-fetching queries are
unanswered. A single com/net name server has received hundreds of unanswered. A single com/net name server has received hundreds of
queries per second from a single such source. Judging from the queries per second from a single such source. Judging from the
specific queries received and based on additional analysis, we specific queries received and based on additional analysis, we
believe these queries result from overly aggressive glue fetching. believe these queries result from overly aggressive glue fetching.
2.4.1. Recommendation 2.4.1. Recommendation
skipping to change at page 15, line 6 skipping to change at page 15, line 6
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. A possible solution is to delegate these numeric TLDs bandwidth. A possible solution is to delegate these numeric TLDs
from the root zone to a separate set of servers to absorb the from the root zone to a separate set of servers to absorb the
traffic. The "black hole servers" used by the AS 112 Project [8], traffic. The "black hole servers" used by the AS 112 Project
which are currently delegated the in-addr.arpa zones corresponding to (http://www.as112.net), which are currently delegated the in-
RFC 1918 [7] private use address space, would be a possible choice to addr.arpa zones corresponding to RFC 1918 [7] private use address
receive these delegations. Of course, the proper and usual root zone space, would be a possible choice to receive these delegations. Of
change procedures would have to be followed to make such a change to course, the proper and usual root zone change procedures would have
the root zone. to be followed to make such a change to the root zone.
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 offers 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
skipping to change at page 20, line 10 skipping to change at page 21, line 5
We believe that implementation of the recommendations offered in this We believe that implementation of the recommendations offered in this
document will reduce the amount of unnecessary traffic seen at root document will reduce the amount of unnecessary traffic seen at root
and TLD name servers, thus reducing the opportunity for an attacker and TLD name servers, thus reducing the opportunity for an attacker
to use such queries to his or her advantage. to use such queries to his or her advantage.
6. Internationalization considerations 6. Internationalization considerations
There are no new internationalization considerations introduced by There are no new internationalization considerations introduced by
this memo. this memo.
7. Informative References 7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Mockapetris, P., "Domain names - concepts and facilities", [2] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
7.2. Informative References
[3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
RFC 2181, July 1997. RFC 2181, July 1997.
[4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
RFC 2308, March 1998. RFC 2308, March 1998.
[5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
Queries for IPv6 Addresses", RFC 4074, May 2005. Queries for IPv6 Addresses", RFC 4074, May 2005.
[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, Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997. April 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, Lear, "Address Allocation for Private Internets", BCP 5,
RFC 1918, February 1996. RFC 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
 End of changes. 10 change blocks. 
20 lines changed or deleted 24 lines changed or added

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