Observed DNS Resolution Misbehavior
RFC 4697
Document | Type |
RFC - Best Current Practice
(October 2006; No errata)
Also known as BCP 123
|
|
---|---|---|---|
Authors | Piet Barber , Matt Larson | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4697 (Best Current Practice) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | David Kessens | ||
Send notices to | (None) |
Network Working Group M. Larson Request for Comments: 4697 P. Barber BCP: 123 VeriSign, Inc. Category: Best Current Practice October 2006 Observed DNS Resolution Misbehavior Status of This Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo describes DNS iterative resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. We offer implementation advice to iterative resolver developers to alleviate these unnecessary queries. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers. Table of Contents 1. Introduction ....................................................2 1.1. A Note about Terminology in this Memo ......................3 1.2. Key Words ..................................................3 2. Observed Iterative Resolver Misbehavior .........................3 2.1. Aggressive Requerying for Delegation Information ...........3 2.1.1. Recommendation ......................................5 2.2. Repeated Queries to Lame Servers ...........................6 2.2.1. Recommendation ......................................6 2.3. Inability to Follow Multiple Levels of Indirection .........7 2.3.1. Recommendation ......................................7 2.4. Aggressive Retransmission when Fetching Glue ...............8 2.4.1. Recommendation ......................................9 2.5. Aggressive Retransmission behind Firewalls .................9 2.5.1. Recommendation .....................................10 2.6. Misconfigured NS Records ..................................10 2.6.1. Recommendation .....................................11 Larson & Barber Best Current Practice [Page 1] RFC 4697 Observed DNS Resolution Misbehavior October 2006 2.7. Name Server Records with Zero TTL .........................11 2.7.1. Recommendation .....................................12 2.8. Unnecessary Dynamic Update Messages .......................12 2.8.1. Recommendation .....................................13 2.9. Queries for Domain Names Resembling IPv4 Addresses ........13 2.9.1. Recommendation .....................................14 2.10. Misdirected Recursive Queries ............................14 2.10.1. Recommendation ....................................14 2.11. Suboptimal Name Server Selection Algorithm ...............15 2.11.1. Recommendation ....................................15 3. Security Considerations ........................................16 4. Acknowledgements ...............................................16 5. Internationalization Considerations ............................16 6. References .....................................................16 6.1. Normative References ......................................16 6.2. Informative References ....................................16 1. Introduction Observation of query traffic received by two root name servers and the thirteen com/net Top-Level Domain (TLD) name servers has revealed that a large proportion of the total traffic often consists of "requeries". A requery is the same question (<QNAME, QTYPE, QCLASS>) asked repeatedly at an unexpectedly high rate. We have observed requeries from both a single IP address and multiple IP addresses (i.e., the same query received simultaneously from multiple IP addresses). By analyzing requery events, we have found that the cause of the duplicate traffic is almost always a deficient iterative resolver, stub resolver, or application implementation combined with an operational anomaly. The implementation deficiencies we have identified to date include well-intentioned recovery attempts gone awry, insufficient caching of failures, early abort when multiple levels of indirection must be followed, and aggressive retry by stub resolvers or applications. Anomalies that we have seen trigger requery events include lame delegations, unusual glue records, and anything that makes all authoritative name servers for a zone unreachable (Denial of Service (DoS) attacks, crashes, maintenance, routing failures, congestion, etc.). In the following sections, we provide a detailed explanation of theShow full document text