Common DNS Data File Configuration Errors
RFC 1537

Document Type RFC - Informational (October 1993; No errata)
Obsoleted by RFC 1912
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1537 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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-
Show full document text