Common DNS Implementation Errors and Suggested Fixes
RFC 1536

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

Network Working Group                                           A. Kumar
Request for Comments: 1536                                     J. Postel
Category: Informational                                        C. Neuman
                                                                     ISI
                                                               P. Danzig
                                                               S. Miller
                                                                     USC
                                                            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
   unlimited.

Abstract

   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
   example.

Introduction

   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
   software.

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
   value.

   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.

A GOOD IMPLEMENTATION:

   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
   exponentially.

   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

FIXES:

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

      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
         estimate.

   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