Common DNS Implementation Errors and Suggested Fixes
RFC 1536

Document Type RFC - Informational (October 1993; No errata)
Authors Peter Danzig  , Anant Kumar  , Steve Miller  , Clifford Neuman  , Jon Postel 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1536 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           A. Kumar
Request for Comments: 1536                                     J. Postel
Category: Informational                                        C. Neuman
                                                               P. Danzig
                                                               S. Miller
                                                            October 1993

          Common DNS Implementation Errors and Suggested Fixes

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is


   This memo describes common errors seen in DNS implementations and
   suggests some fixes. Where applicable, violations of recommendations
   from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo
   also describes, where relevant, the algorithms followed in BIND
   (versions 4.8.3 and 4.9 which the authors referred to) to serve as an


   The last few years have seen, virtually, an explosion of DNS traffic
   on the NSFnet backbone. Various DNS implementations and various
   versions of these implementations interact with each other, producing
   huge amounts of unnecessary traffic. Attempts are being made by
   researchers all over the internet, to document the nature of these
   interactions, the symptomatic traffic patterns and to devise remedies
   for the sick pieces of software.

   This draft is an attempt to document fixes for known DNS problems so
   people know what problems to watch out for and how to repair broken

1. Fast Retransmissions

   DNS implements the classic request-response scheme of client-server
   interaction. UDP is, therefore, the chosen protocol for communication
   though TCP is used for zone transfers. The onus of requerying in case
   no response is seen in a "reasonable" period of time, lies with the
   client. Although RFC 1034 and 1035 do not recommend any

Kumar, Postel, Neuman, Danzig & Miller                          [Page 1]
RFC 1536            Common DNS Implementation Errors        October 1993

   retransmission policy, RFC 1035 does recommend that the resolvers
   should cycle through a list of servers. Both name servers and stub
   resolvers should, therefore, implement some kind of a retransmission
   policy based on round trip time estimates of the name servers. The
   client should back-off exponentially, probably to a maximum timeout

   However, clients might not implement either of the two. They might
   not wait a sufficient amount of time before retransmitting or they
   might not back-off their inter-query times sufficiently.

   Thus, what the server would see will be a series of queries from the
   same querying entity, spaced very close together. Of course, a
   correctly implemented server discards all duplicate queries but the
   queries contribute to wide-area traffic, nevertheless.

   We classify a retransmission of a query as a pure Fast retry timeout
   problem when a series of query packets meet the following conditions.

      a. Query packets are seen within a time less than a "reasonable
         waiting period" of each other.

      b. No response to the original query was seen i.e., we see two or
         more queries, back to back.

      c. The query packets share the same query identifier.

      d. The server eventually responds to the query.


   BIND (we looked at versions 4.8.3 and 4.9) implements a good
   retransmission algorithm which solves or limits all of these
   problems.  The Berkeley stub-resolver queries servers at an interval
   that starts at the greater of 4 seconds and 5 seconds divided by the
   number of servers the resolver queries. The resolver cycles through
   servers and at the end of a cycle, backs off the time out

   The Berkeley full-service resolver (built in with the program
   "named") starts with a time-out equal to the greater of 4 seconds and
   two times the round-trip time estimate of the server.  The time-out
   is backed off with each cycle, exponentially, to a ceiling value of
   45 seconds.

Kumar, Postel, Neuman, Danzig & Miller                          [Page 2]
RFC 1536            Common DNS Implementation Errors        October 1993


      a. Estimate round-trip times or set a reasonably high initial

      b. Back-off timeout periods exponentially.

      c. Yet another fundamental though difficult fix is to send the
         client an acknowledgement of a query, with a round-trip time

   Since UDP is used, no response is expected by the client until the
   query is complete.  Thus, it is less likely to have information about
Show full document text