rfc1537.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 507 行 · 第 1/2 页

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
   of nameservers without checking if primary (!) and secondary servers
   have been set up, informed, or even asked.  It should also be noted
   that a combination of long-lasting unreachability of primary
   nameservers, (therefore) expiration of zone information, plus static
   IP routing, can lead to massive network traffic that can fill up
   lines completely.

4. "MX records surprise"

   In a sense similar to point 3. Sometimes nameserver managers enter MX
   records in their zone files that point to external hosts, without
   first asking or even informing the systems managers of those external
   hosts.  This has to be fought out between the nameserver manager and
   the systems managers involved. Only as a last resort, if really
   nothing helps to get the offending records removed, can the systems
   manager turn to the naming authority of the domain above the
   offending domain to get the problem sorted out.

5. "Name extension surprise"

   Sometimes one encounters weird names, which appear to be an external
   name extended with a local domain. This is caused by forgetting to
   terminate a name with a dot: names in zone files that don't end with
   a dot are always expanded with the name of the current zone (the
   domain that the zone file stands for or the last $ORIGIN).

   Example: zone file for foo.xx:

   pqr          MX 100  relay.yy.
   xyz          MX 100  relay.yy           (no trailing dot!)



Beertema                                                        [Page 3]

RFC 1537       Common DNS Data File Configuration Errors    October 1993


   When fully written out this stands for:

      pqr.foo.xx.  MX 100  relay.yy.
      xyz.foo.xx.  MX 100  relay.yy.foo.xx.   (name extension!)

6. Missing secondary servers

   It is required that there be a least 2 nameservers for a domain. For
   obvious reasons the nameservers for top level domains need to be very
   well reachable from all over the Internet. This implies that there
   must be more than just 2 of them; besides, most of the (secondary)
   servers should be placed at "strategic" locations, e.g., close to a
   point where international and/or intercontinental lines come
   together.  To keep things manageable, there shouldn't be too many
   servers for a domain either.

   Important aspects in selecting the location of primary and secondary
   servers are reliability (network, host) and expedient contacts: in
   case of problems, changes/fixes must be carried out quickly.  It
   should be considered logical that primary servers for European top
   level domains should run on a host in Europe, preferably (if
   possible) in the country itself. For each top level domain there
   should be 2 secondary servers in Europe and 2 in the USA, but there
   may of course be more on either side.  An excessive number of
   nameservers is not a good idea though; a recommended maximum is 7
   nameservers.  In Europe, EUnet has offered to run secondary server
   for each European top level domain.

7. Wildcard MX records

   Wildcard MX records should be avoided where possible. They often
   cause confusion and errors: especially beginning nameserver managers
   tend to overlook the fact that a host/domain listed with ANY type of
   record in a zone file is NOT covered by an overall wildcard MX record
   in that zone; this goes not only for simple domain/host names, but
   also for names that cover one or more domains. Take the following
   example in zone foo.bar:

         *            MX 100  mailhost
         pqr          MX 100  mailhost
         abc.def      MX 100  mailhost

   This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid
   domains, but the wildcard MX record covers NONE of them, nor anything
   below them.  To cover everything by MX records, the required entries
   are:





Beertema                                                        [Page 4]

RFC 1537       Common DNS Data File Configuration Errors    October 1993


         *            MX 100  mailhost
         pqr          MX 100  mailhost
         *.pqr        MX 100  mailhost
         abc.def      MX 100  mailhost
         *.def        MX 100  mailhost
         *.abc.def    MX 100  mailhost

   An overall wildcard MX record is almost never useful.

   In particular the zone file of a top level domain should NEVER
   contain only an overall wildcard MX record (*.XX). The effect of such
   a wildcard MX record can be that mail is unnecessarily sent across
   possibly expensive links, only to fail at the destination or gateway
   that the record points to. Top level domain zone files should
   explicitly list at least all the officially registered primary
   subdomains.

   Whereas overall wildcard MX records should be avoided, wildcard MX
   records are acceptable as an explicit part of subdomain entries,
   provided they are allowed under a given subdomain (to be determined
   by the naming authority for that domain).

   Example: