Browse Prior Art Database

Common DNS Data File Configuration Errors (RFC1537)

IP.com Disclosure Number: IPCOM000002368D
Original Publication Date: 1993-Oct-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 8 page(s) / 18K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

P. Beertema: AUTHOR

Abstract

This memo describes errors often found in DNS data files. It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time.

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

Network Working Group P. Beertema

Request for Comments: 1537 CWI

Category: Informational October 1993

Common DNS Data File Configuration Errors

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 errors often found in DNS data files. It points

out common mistakes system administrators tend to make and why they

often go unnoticed for long periods of time.

Introduction

Due to the lack of extensive documentation and automated tools, DNS

zone files have mostly been configured by system administrators, by

hand. Some of the rules for writing the data files are rather subtle

and a few common mistakes are seen in domains worldwide.

This document is an attempt to list "surprises" that administrators

might find hidden in their zone files. It describes the symptoms of

the malady and prescribes medicine to cure that. It also gives some

general recommendations and advice on specific nameserver and zone

file issues and on the (proper) use of the Domain Name System.

1. SOA records

A problem I've found in quite some nameservers is that the various

timers have been set (far) too low. Especially for top level domain

nameservers this causes unnecessary traffic over international and

intercontinental links.

Unfortunately the examples given in the BIND manual, in RFC's and in

some expert documents give those very short timer values, and that's

most likely what people have modeled their SOA records after.

First of all a short explanation of the timers used in the SOA

record:

- Refresh: The SOA record of the primary server is checked

every "refresh" time by the secondary servers;

if it has changed, a zone transfer is done.

- Retry: If a secondary server cannot reach the primary

server, it tries it again every "retry" time.

- Expire: If for "expire" time the primary server cannot

be reached, all information about the zone is

invalidated on the secondary servers (i.e., they

are no longer authoritative for that zone).

- Minimum TTL: The default TTL value for all records in the

zone file; a different TTL value may be given

explicitly in a record when necessary.

(This timer is named "Minimum", and that's

...