Browse Prior Art Database

Common DNS Implementation Errors and Suggested Fixes (RFC1536)

IP.com Disclosure Number: IPCOM000002367D
Original Publication Date: 1993-Oct-01
Included in the Prior Art Database: 2019-Feb-13
Document File: 12 page(s) / 17K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A. Kumar: AUTHOR [+4]

Related Documents

10.17487/RFC1536: DOI

Abstract

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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 15% of the total text.

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

Processing...
Loading...