Common DNS Implementation Errors and Suggested Fixes (RFC1536)
Original Publication Date: 1993-Oct-01
Included in the Prior Art Database: 2019-Feb-13
Internet Society Requests For Comment (RFCs)
A. Kumar: AUTHOR [+4]
This memo describes common errors seen in DNS implementations and suggests some fixes. This memo provides information for the Internet community. It does not specify an Internet standard.
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.
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.
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 IM...