rfc1912.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 900 行 · 第 1/3 页

   keeping track of who has the most current data.  If and only if the
   primary's serial number of the zone is greater will the secondary ask
   the primary for a copy of the new zone data (see special case below).

   Don't forget to change the serial number when you change data!  If
   you don't, your secondaries will not transfer the new zone
   information.  Automating the incrementing of the serial number with
   software is also a good idea.

   If you make a mistake and increment the serial number too high, and
   you want to reset the serial number to a lower value, use the
   following procedure:





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


      Take the `incorrect' serial number and add 2147483647 to it.  If
      the number exceeds 4294967296, subtract 4294967296.  Load the
      resulting number.  Then wait 2 refresh periods to allow the zone
      to propagate to all servers.

      Repeat above until the resulting serial number is less than the
      target serial number.

      Up the serial number to the target serial number.

   This procedure won't work if one of your secondaries is running an
   old version of BIND (4.8.3 or earlier).  In this case you'll have to
   contact the hostmaster for that secondary and have them kill the
   secondary servers, remove the saved backup file, and restart the
   server.  Be careful when editing the serial number -- DNS admins
   don't like to kill and restart nameservers because you lose all that
   cached data.

3.2 Zone file style guide

   Here are some useful tips in structuring your zone files.  Following
   these will help you spot mistakes, and avoid making more.

   Be consistent with the style of entries in your DNS files. If your
   $ORIGIN is podunk.xx., try not to write entries like:

           mary            IN      A       1.2.3.1
           sue.podunk.xx.  IN      A       1.2.3.2

   or:

           bobbi           IN      A       1.2.3.2
                           IN      MX      mary.podunk.xx.


   Either use all FQDNs (Fully Qualified Domain Names) everywhere or
   used unqualified names everywhere.  Or have FQDNs all on the right-
   hand side but unqualified names on the left.  Above all, be
   consistent.

   Use tabs between fields, and try to keep columns lined up.  It makes
   it easier to spot missing fields (note some fields such as "IN" are
   inherited from the previous record and may be left out in certain
   circumstances.)







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


   Remember you don't need to repeat the name of the host when you are
   defining multiple records for one host.  Be sure also to keep all
   records associated with a host together in the file.  It will make
   things more straightforward when it comes time to remove or rename a
   host.

   Always remember your $ORIGIN.  If you don't put a `.' at the end of
   an FQDN, it's not recognized as an FQDN.  If it is not an FQDN, then
   the nameserver will append $ORIGIN to the name.  Double check, triple
   check, those trailing dots, especially in in-addr.arpa zone files,
   where they are needed the most.

   Be careful with the syntax of the SOA and WKS records (the records
   which use parentheses).  BIND is not very flexible in how it parses
   these records.  See the documentation for BIND.

3.3 Verifying data

   Verify the data you just entered or changed by querying the resolver
   with dig (or your favorite DNS tool, many are included in the BIND
   distribution) after a change.  A few seconds spent double checking
   can save hours of trouble, lost mail, and general headaches.  Also be
   sure to check syslog output when you reload the nameserver.  If you
   have grievous errors in your DNS data or boot file, named will report
   it via syslog.

   It is also highly recommended that you automate this checking, either
   with software which runs sanity checks on the data files before they
   are loaded into the nameserver, or with software which checks the
   data already loaded in the nameserver.  Some contributed software to
   do this is included in the BIND distribution.

4. Miscellaneous Topics

4.1 Boot file setup

   Certain zones should always be present in nameserver configurations:

           primary         localhost               localhost
           primary         0.0.127.in-addr.arpa    127.0
           primary         255.in-addr.arpa        255
           primary         0.in-addr.arpa          0

   These are set up to either provide nameservice for "special"
   addresses, or to help eliminate accidental queries for broadcast or
   local address to be sent off to the root nameservers.  All of these
   files will contain NS and SOA records just like the other zone files
   you maintain, the exception being that you can probably make the SOA



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


   timers very long, since this data will never change.

   The "localhost" address is a "special" address which always refers to
   the local host.  It should contain the following line:

           localhost.      IN      A       127.0.0.1

   The "127.0" file should contain the line:

           1    PTR     localhost.

   There has been some extensive discussion about whether or not to
   append the local domain to it.  The conclusion is that "localhost."
   would be the best solution.  The reasons given include:

      "localhost" by itself is used and expected to work in some
      systems.

      Translating 127.0.0.1 into "localhost.dom.ain" can cause some
      software to connect back to the loopback interface when it didn't
      want to because "localhost" is not equal to "localhost.dom.ain".

   The "255" and "0" files should not contain any additional data beyond
   the NS and SOA records.

   Note that future BIND versions may include all or some of this data
   automatically without additional configuration.

4.2 Other Resolver and Server bugs

   Very old versions of the DNS resolver have a bug that cause queries
   for names that look like IP addresses to go out, because the user
   supplied an IP address and the software didn't realize that it didn't
   need to be resolved.  This has been fixed but occasionally it still
   pops up.  It's important because this bug means that these queries
   will be sent directly to the root nameservers, adding to an already
   heavy DNS load.

   While running a secondary nameserver off another secondary nameserver
   is possible, it is not recommended unless necessary due to network
   topologies.  There are known cases where it has led to problems like
   bogus TTL values.  While this may be caused by older or flawed DNS
   implementations, you should not chain secondaries off of one another
   since this builds up additional reliability dependencies as well as
   adds additional delays in updates of new zone data.






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


4.3 Server issues

   DNS operates primarily via UDP (User Datagram Protocol) messages.
   Some UNIX operating systems, in an effort to save CPU cycles, run
   with UDP checksums turned off.  The relative merits of this have long
   been debated.  However, with the increase in CPU speeds, the
   performance considerations become less and less important.  It is
   strongly encouraged that you turn on UDP checksumming to avoid
   corrupted data not only with DNS but with other services that use UDP
   (like NFS).  Check with your operating system documentation to verify
   that UDP checksumming is enabled.

References

   [RFC 974] Partridge, C., "Mail routing and the domain system", STD
              14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.

   [RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC
              1033, USC/Information Sciences Institute, November 1987.

   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
              STD 13, RFC 1034, USC/Information Sciences Institute,
              November 1987.

   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
              Specification", STD 13, RFC 1035, USC/Information Sciences
              Institute, November 1987.

   [RFC 1123] Braden, R., "Requirements for Internet Hosts --
              Application and Support", STD 3, RFC 1123, IETF, October
              1989.

   [RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC
              1178, Integrated Systems Group/NIST, August 1990.

   [RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart,
              "New DNS RR Definitions", RFC 1183, October 1990.

   [RFC 1535] Gavron, E., "A Security Problem and Proposed Correction
              With Widely Deployed DNS Software", RFC 1535, ACES
              Research Inc., October 1993.

   [RFC 1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
              Miller, "Common DNS Implementation Errors and Suggested
              Fixes", RFC 1536, USC/Information Sciences Institute, USC,
              October 1993.





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


   [RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors",
              RFC 1537, CWI, October 1993.

   [RFC 1713] A. Romao, "Tools for DNS debugging", RFC 1713, FCCN,
              November 1994.

   [BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND",
              Vixie Enterprises, July 1994.

5. Security Considerations

   Security issues are not discussed in this memo.

6. Author's Address

   David Barr
   The Pennsylvania State University
   Department of Mathematics
   334 Whitmore Building
   University Park, PA 16802

   Voice: [phone]
   Fax: [phone]
   EMail: [e-mail]



























Barr                         Informational                     [Page 16]