rfc1912.txt

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

Network Working Group                                            D. Barr
Request for Comments: 1912             The Pennsylvania State University
Obsoletes: 1537                                            February 1996
Category: Informational


            Common DNS Operational and Configuration Errors

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This memo describes errors often found in both the operation of
   Domain Name System (DNS) servers, and in the data that these DNS
   servers contain.  This memo tries to summarize current Internet
   requirements as well as common practice in the operation and
   configuration of the DNS.  This memo also tries to summarize or
   expand upon issues raised in [RFC 1537].

1. Introduction

   Running a nameserver is not a trivial task.  There are many things
   that can go wrong, and many decisions have to be made about what data
   to put in the DNS and how to set up servers.  This memo attempts to
   address many of the common mistakes and pitfalls that are made in DNS
   data as well as in the operation of nameservers.  Discussions are
   also made regarding some other relevant issues such as server or
   resolver bugs, and a few political issues with respect to the
   operation of DNS on the Internet.

2. DNS Data

   This section discusses problems people typically have with the DNS
   data in their nameserver, as found in the zone data files that the
   nameserver loads into memory.

2.1 Inconsistent, Missing, or Bad Data

   Every Internet-reachable host should have a name.  The consequences
   of this are becoming more and more obvious.  Many services available
   on the Internet will not talk to you if you aren't correctly
   registered in the DNS.





Barr                         Informational                      [Page 1]

RFC 1912                   Common DNS Errors               February 1996


   Make sure your PTR and A records match.  For every IP address, there
   should be a matching PTR record in the in-addr.arpa domain.  If a
   host is multi-homed, (more than one IP address) make sure that all IP
   addresses have a corresponding PTR record (not just the first one).
   Failure to have matching PTR and A records can cause loss of Internet
   services similar to not being registered in the DNS at all.  Also,
   PTR records must point back to a valid A record, not a alias defined
   by a CNAME.  It is highly recommended that you use some software
   which automates this checking, or generate your DNS data from a
   database which automatically creates consistent data.

   DNS domain names consist of "labels" separated by single dots.  The
   DNS is very liberal in its rules for the allowable characters in a
   domain name.  However, if a domain name is used to name a host, it
   should follow rules restricting host names.  Further if a name is
   used for mail, it must follow the naming rules for names in mail
   addresses.

   Allowable characters in a label for a host name are only ASCII
   letters, digits, and the `-' character.  Labels may not be all
   numbers, but may have a leading digit  (e.g., 3com.com).  Labels must
   end and begin only with a letter or digit.  See [RFC 1035] and [RFC
   1123].  (Labels were initially restricted in [RFC 1035] to start with
   a letter, and some older hosts still reportedly have problems with
   the relaxation in [RFC 1123].)  Note there are some Internet
   hostnames which violate this rule (411.org, 1776.com).  The presence
   of underscores in a label is allowed in [RFC 1033], except [RFC 1033]
   is informational only and was not defining a standard.  There is at
   least one popular TCP/IP implementation which currently refuses to
   talk to hosts named with underscores in them.  It must be noted that
   the language in [1035] is such that these rules are voluntary -- they
   are there for those who wish to minimize problems.  Note that the
   rules for Internet host names also apply to hosts and addresses used
   in SMTP (See RFC 821).

   If a domain name is to be used for mail (not involving SMTP), it must
   follow the rules for mail in [RFC 822], which is actually more
   liberal than the above rules.  Labels for mail can be any ASCII
   character except "specials", control characters, and whitespace
   characters.  "Specials" are specific symbols used in the parsing of
   addresses.  They are the characters "()<>@,;:\".[]".  (The "!"
   character wasn't in [RFC 822], however it also shouldn't be used due
   to the conflict with UUCP mail as defined in RFC 976)  However, since
   today almost all names which are used for mail on the Internet are
   also names used for hostnames, one rarely sees addresses using these
   relaxed standard, but mail software should be made liberal and robust
   enough to accept them.




Barr                         Informational                      [Page 2]

RFC 1912                   Common DNS Errors               February 1996


   You should also be careful to not have addresses which are valid
   alternate syntaxes to the inet_ntoa() library call.  For example 0xe
   is a valid name, but if you were to type "telnet 0xe", it would try
   to connect to IP address 0.0.0.14.  It is also rumored that there
   exists some broken inet_ntoa() routines that treat an address like
   x400 as an IP address.

   Certain operating systems have limitations on the length of their own
   hostname.  While not strictly of issue to the DNS, you should be
   aware of your operating system's length limits before choosing the
   name of a host.

   Remember that many resource records (abbreviated RR) take on more
   than one argument.  HINFO requires two arguments, as does RP.  If you
   don't supply enough arguments, servers sometime return garbage for
   the missing fields.  If you need to include whitespace within any
   data, you must put the string in quotes.

2.2 SOA records

   In the SOA record of every zone, remember to fill in the e-mail
   address that will get to the person who maintains the DNS at your
   site (commonly referred to as "hostmaster").  The `@' in the e-mail
   must be replaced by a `.' first.  Do not try to put an `@' sign in
   this address.  If the local part of the address already contains a
   `.' (e.g., [e-mail]), then you need to quote the `.' by
   preceding it with `\' character.  (e.g., to become
   John\.Smith.widget.xx) Alternately (and preferred), you can just use
   the generic name `hostmaster', and use a mail alias to redirect it to
   the appropriate persons.  There exists software which uses this field
   to automatically generate the e-mail address for the zone contact.
   This software will break if this field is improperly formatted.  It
   is imperative that this address get to one or more real persons,
   because it is often used for everything from reporting bad DNS data
   to reporting security incidents.

   Even though some BIND versions allow you to use a decimal in a serial
   number, don't.  A decimal serial number is converted to an unsigned
   32-bit integer internally anyway.  The formula for a n.m serial
   number is n*10^(3+int(0.9+log10(m))) + m which translates to
   something rather unexpected.  For example it's routinely possible
   with a decimal serial number (perhaps automatically generated by
   SCCS) to be incremented such that it is numerically larger, but after
   the above conversion yield a serial number which is LOWER than
   before.  Decimal serial numbers have been officially deprecated in
   recent BIND versions.  The recommended syntax is YYYYMMDDnn
   (YYYY=year, MM=month, DD=day, nn=revision number.  This won't
   overflow until the year 4294.



Barr                         Informational                      [Page 3]

RFC 1912                   Common DNS Errors               February 1996


   Choose logical values for the timer values in the SOA record (note
   values below must be expressed as seconds in the zone data):

      Refresh: How often a secondary will poll the primary server to see
          if the serial number for the zone has increased (so it knows
          to request a new copy of the data for the zone).  Set this to
          how long your secondaries can comfortably contain out-of-date
          data.  You can keep it short (20 mins to 2 hours) if you
          aren't worried about a small increase in bandwidth used, or
          longer (2-12 hours) if your Internet connection is slow or is
          started on demand.  Recent BIND versions (4.9.3) have optional
          code to automatically notify secondaries that data has
          changed, allowing you to set this TTL to a long value (one
          day, or more).

      Retry: If a secondary was unable to contact the primary at the
          last refresh, wait the retry value before trying again.  This
          value isn't as important as others, unless the secondary is on
          a distant network from the primary or the primary is more
          prone to outages.  It's typically some fraction of the refresh
          interval.


      Expire: How long a secondary will still treat its copy of the zone
          data as valid if it can't contact the primary.  This value
          should be greater than how long a major outage would typically
          last, and must be greater than the minimum and retry
          intervals, to avoid having a secondary expire the data before
          it gets a chance to get a new copy.  After a zone is expired a
          secondary will still continue to try to contact the primary,
          but it will no longer provide nameservice for the zone.  2-4
          weeks are suggested values.

      Minimum: The default TTL (time-to-live) for resource records --
          how long data will remain in other nameservers' cache.  ([RFC
          1035] defines this to be the minimum value, but servers seem
          to always implement this as the default value)  This is by far
          the most important timer.  Set this as large as is comfortable
          given how often you update your nameserver.  If you plan to
          make major changes, it's a good idea to turn this value down
          temporarily beforehand.  Then wait the previous minimum value,
          make your changes, verify their correctness, and turn this
          value back up.  1-5 days are typical values.  Remember this
          value can be overridden on individual resource records.







Barr                         Informational                      [Page 4]

RFC 1912                   Common DNS Errors               February 1996


   As you can see, the typical values above for the timers vary widely.
   Popular documentation like [RFC 1033] recommended a day for the
   minimum TTL, which is now considered too low except for zones with
   data that vary regularly.  Once a DNS stabilizes, values on the order
   of 3 or more days are recommended.  It is also recommended that you
   individually override the TTL on certain RRs which are often
   referenced and don't often change to have very large values (1-2
   weeks).  Good examples of this are the MX, A, and PTR records of your
   mail host(s), the NS records of your zone, and the A records of your
   nameservers.

2.3 Glue A Records

   Glue records are A records that are associated with NS records to
   provide "bootstrapping" information to the nameserver.  For example:

           podunk.xx.      in      ns      ns1.podunk.xx.
                           in      ns      ns2.podunk.xx.
           ns1.podunk.xx.  in      a       1.2.3.4
           ns2.podunk.xx.  in      a       1.2.3.5

   Here, the A records are referred to as "Glue records".

   Glue records are required only in forward zone files for nameservers
   that are located in the subdomain of the current zone that is being
   delegated.  You shouldn't have any A records in an in-addr.arpa zone
   file (unless you're using RFC 1101-style encoding of subnet masks).

   If your nameserver is multi-homed (has more than one IP address), you
   must list all of its addresses in the glue to avoid cache
   inconsistency due to differing TTL values, causing some lookups to
   not find all addresses for your nameserver.

   Some people get in the bad habit of putting in a glue record whenever
   they add an NS record "just to make sure".  Having duplicate glue
   records in your zone files just makes it harder when a nameserver
   moves to a new IP address, or is removed. You'll spend hours trying
   to figure out why random people still see the old IP address for some
   host, because someone forgot to change or remove a glue record in
   some other file.  Newer BIND versions will ignore these extra glue
   records in local zone files.

   Older BIND versions (4.8.3 and previous) have a problem where it
   inserts these extra glue records in the zone transfer data to
   secondaries.  If one of these glues is wrong, the error can be
   propagated to other nameservers.  If two nameservers are secondaries
   for other zones of each other, it's possible for one to continually
   pass old glue records back to the other.  The only way to get rid of



Barr                         Informational                      [Page 5]

RFC 1912                   Common DNS Errors               February 1996


   the old data is to kill both of them, remove the saved backup files,
   and restart them.  Combined with that those same versions also tend
   to become infected more easily with bogus data found in other non-
   secondary nameservers (like the root zone data).

2.4 CNAME records

   A CNAME record is not allowed to coexist with any other data.  In
   other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
   can't also have an MX record for suzy.podunk.edu, or an A record, or
   even a TXT record.  Especially do not try to combine CNAMEs and NS
   records like this!: