Common DNS Implementation Errors and Suggested Fixes
RFC 1536
|
| Document |
Type |
|
RFC - Informational
(October 1993; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
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
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
Show full document text