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: 2000-Sep-12
Document File: 10 page(s) / 24K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A. Kumar: AUTHOR [+5]

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 13% 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

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