rfc1713.txt

RFC 的详细文档！

   necessity of dedicating an entire section to any of them.  This
   doesn't mean they are not valuable contributions, in some cases they
   may be just what you are looking for, without having to install a
   complete package to do some testings on your domain.

   The reference taken was the contrib directory in the latest BIND
   distribution (where some of the above programs can also be found).
   There you will find tools for creating your DNS configuration files
   and NIS maps from /etc/hosts and vice-versa or generate PTR from A
   records (these things may be important as a means of avoiding common
   typing errors and inconsistencies between those tables), syntax
   checkers for zone files, programs for querying and monitoring name
   servers, all the small programs presented in [8], and more.  It is
   worth spending some time looking at them, maybe you'll find that



Romao                                                           [Page 9]

RFC 1713                Tools for DNS debugging            November 1994


   program you were planning to write yourself.  The latest public
   version of BIND can be found at
   ftp://gatekeeper.dec.com/pub/misc/vixie/4.9.2-940221.tar.gz.  As of
   this writing BIND-4.9.3 is in its final beta stages and a public
   release is expected soon, also at gatekeeper.dec.com.

   You may also want to consider using a version control system like
   SCCS or RCS to maintain your configuration files consistent through
   updates, or use tools like M4 macros to generate those files.  As
   stated above, it's important to avoid human-generated errors,
   creating problems that are difficult to track down, since they're
   often hidden behind some mistyped name.  Errors like this may end up
   in many queries for a non-existing name, just to mention the less
   serious kind.  See [9] for a description of the most common errors
   made while configuring domains.

3. Why look after DNS?

   Several pieces of software were presented to help people administer
   and debug their name services.  They exhibit many differences in
   their way of doing things, scope and requirements and it may be
   difficult just to choose one of them to work with.  For one thing,
   people's expectations from these tools vary according to their kind
   of involvement with DNS.  If you are responsible for a big domain,
   e.g., a top-level one or a big institution with many hosts and sub-
   domains, you probably want to see how well is the tree below your
   node organized, since the consequences of errors tend to propagate
   upwards, thus affecting your own domain and servers.  For that you
   need some program that recursively descends the domain tree and
   analyzes each domain per se and the interdependencies between them
   all.  You will have to consider how deep you want your analysis to
   be, the effects it will have on the network infrastructure, i.e.,
   will it generate traffic only inside a campus network, no matter how
   big it is, or will it be spread over, say, a whole country (of
   course, your kind of connectivity plays an important role here).

   You may simply want to perform some sanity checks on your own domain,
   without any further concerns.  Or you may want to participate in some
   kind of global effort to monitor name server traffic, either for
   research purposes or just to point out the "trouble-queries" that
   flow around.

   Whatever your interest may be, you can almost surely find a tool to
   suit it.  Eliminating problems like those described in this document
   is a major contribution for the efficiency of an important piece of
   the Internet mechanism.  Just to have an idea of this importance,
   think of all the applications that depend on it, not just to get
   addresses out of names.  Many systems rely on DNS to store, retrieve



Romao                                                          [Page 10]

RFC 1713                Tools for DNS debugging            November 1994


   and spread the information they need: Internet electronic mail was
   already mentioned (see [10] for details) and work is in progress to
   integrate X.400 operations with DNS [11]; others include "remote
   printing" services [12], distributed file systems and network routing
   purposes, among others.  These features may be accomplished by some
   standard, well-known resource records [13], or by new, experimental
   ones [14, 15].  Even if some of them won't succeed, one may well
   expect some more load on the DNS burden.

   The ubiquitous DNS thus deserves a great deal of attention, perhaps
   much more than it generally has.  One may say that it is a victim of
   its own success: if a user triggers an excessive amount of queries
   only to have one request satisfied, he won't worry about it (in fact,
   he won't notice it), won't complain to his system administrator, and
   things will just go on like this.  Of course, DNS was designed to
   resist and provide its services despite all these anomalies.  But by
   doing so it is frequently forgotten, as long as people can Telnet or
   ftp.  As DNS will be given new responsibilities, as pointed in the
   above paragraph, the problems described in this text will grow more
   serious and new ones may appear (notably security ones [16], with a
   lot of work being presently in progress addressing security in DNS),
   if nothing is done to purge them.

References

   [1] Lottor, M., "Internet Domain Survey, October 1994",
       http://www.nw.com/zone/WWW/report.html, October 1994.

   [2] Beecher, B., "Dealing With Lame Delegations", Univ. Michigan,
       LISA VI, October 1992.

   [3] Frazao, J. and J. L. Martins, "Ddt - Domain Debug Tools, A
       Package to Debug the DNS Tree", Dept. Informatica Faculdade
       Ciencias Univ. Lisboa, DI-FCUL-1992-04, January 1992.

   [4] Danzig, P., "Probabilistic Error Checkers: Fixing DNS", Univ.
       Southern California, Technical Report, February 1992.

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

   [6] Miller, S. and P. Danzig, "The Checker Project, Installation and
       Operator's Manual", Univ. Southern California, TR CS94-560, 1994.

   [7] Danzig, P., K. Obraczka and A. Kumar, "An Analisys of Wide-Area
       Name Server Traffic", Univ. Southern California, TR 92-504, 1992.




Romao                                                          [Page 11]

RFC 1713                Tools for DNS debugging            November 1994


   [8] Albitz, P. and C. Liu, "DNS and BIND", O'Reilly and Associates
       Inc., October 1992.

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

  [10] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
       974, CSNET CIC BBN Laboratories Inc., January 1986.

  [11] Allocchio, C., A. Bonito, B. Cole, S. Giordano and R. Hagens,
       "Using the Internet DNS to Distribute RFC1327 Mail Address
       Mapping Tables", RFC 1664, GARR, Cisco Systems Inc., Centro
       Svizzero Calcolo Scientifico, ANS, August 1994.

  [12] Malamud, C. and M. Rose, "Principles of Operation for the TPC.INT
       Subdomain: General Principles and Policy", RFC 1530, Internet
       Multicasting Service, Dover Beach Consulting Inc., October 1993.

  [13] Rosenbaum, R., "Using the Domain Name System to Store Arbitrary
       String Attributes", RFC 1464, Digital Equipment Corporation, May
       1993.

  [14] Everhart, C., L. Mamakos, R. Ullmann and P. Mockapetris (Ed.),
       "New DNS RR Definitions", RFC 1183, Transarc, Univ. Maryland,
       Prime Computer, Information Sciences Institute, October 1990.

  [15] Manning, B., and R. Colella, "DNS NSAP Resource Records", RFC
       1706, USC/Information Sciences Institute, NIST, October 1994.

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



















Romao                                                          [Page 12]

RFC 1713                Tools for DNS debugging            November 1994


Security Considerations

   Security issues are not discussed in this memo (although security is
   briefly mentioned at the end of section 3).

Author's Address

   Artur Romao
   DI - Faculdade de Ciencias e Tecnologia
   Universidade Nova de Lisboa
   Quinta da Torre
   P-2825 Monte de Caparica
   Portugal

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


































Romao                                                          [Page 13]