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:
Beertema [Page 1]RFC 1537 Common DNS Data File Configuration Errors October 1993
- 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
what it's function should be according to
STD 13, RFC 1035, but most (all?)
implementations take it as the default value
exported with records without an explicit TTL
value).
For top level domain servers I would recommend the following values:
86400 ; Refresh 24 hours
7200 ; Retry 2 hours
2592000 ; Expire 30 days
345600 ; Minimum TTL 4 days
For other servers I would suggest:
28800 ; Refresh 8 hours
7200 ; Retry 2 hours
604800 ; Expire 7 days
86400 ; Minimum TTL 1 day
but here the frequency of changes, the required speed of propagation,
the reachability of the primary server etc. play a role in optimizing
the timer values.
2. Glue records
Quite often, people put unnecessary glue (A) records in their zone
files. Even worse is that I've even seen *wrong* glue records for an
external host in a primary zone file! Glue records need only be in a
zone file if the server host is within the zone and there is no A
record for that host elsewhere in the zone file.
Beertema [Page 2]RFC 1537 Common DNS Data File Configuration Errors October 1993
Old BIND versions ("native" 4.8.3 and older versions) showed the
problem that wrong glue records could enter secondary servers in a
zone transfer.
3. "Secondary server surprise"
I've seen it happen on various occasions that hosts got bombarded by
nameserver requests without knowing why. On investigation it turned
out then that such a host was supposed to (i.e., the information was
in the root servers) run secondary for some domain (or reverse (in-
addr.arpa)) domain, without that host's nameserver manager having
been asked or even been told so!
Newer BIND versions (4.9 and later) solved this problem. At the same
time though the fix has the disadvantage that it's far less easy to
spot this problem.
Practice has shown that most domain registrars accept registrations