rfc1713.txt

RFC 的详细文档！

Network Working Group                                           A. Romao
Request for Comments: 1713                                          FCCN
FYI: 27                                                    November 1994
Category: Informational


                        Tools for DNS debugging

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

   Although widely used (and most of the times unnoticed), DNS (Domain
   Name System) is too much overlooked, in the sense that people,
   especially administrators, tend to ignore possible anomalies as long
   as applications that need name-to-address mapping continue to work.
   This document presents some tools available for domain administrators
   to detect and correct those anomalies.

1. Introduction

   Today more than 3,800,000 computers are inter-connected in a global
   Internet [1], comprising several millions of end-users, able to reach
   any of those machines just by naming it.  This facility is possible
   thanks to the world widest distributed database, the Domain Name
   System, used to provide distributed applications various services,
   the most notable one being translating names into IP addresses and
   vice-versa.  This happens when you do an FTP or Telnet, when your
   gopher client follows a link to some remote server, when you click on
   a hypertext item and have to reach a server as defined by the URL,
   when you talk to [e-mail], when your mail has to be routed
   through a set to gateways before it reaches the final recipient, when
   you post an article to Usenet and want it propagated all over the
   world.  While these may be the most visible uses of DNS, a lot more
   applications rely on this system to operate, e.g., network security,
   monitoring and accounting tools, just to mention a few.

   DNS owes much of its success to its distributed administration.  Each
   component (called a zone, the same as a domain in most cases), is
   seen as an independent entity, being responsible for what happens
   inside its domain of authority, how and what information changes and
   for letting the tree grow downwards, creating new components.





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


   On the other hand, many inconsistencies arise from this distributed
   nature: many administrators make mistakes in the way they configure
   their domains and when they delegate authority to sub-domains; many
   of them don't even know how to do these things properly, letting
   problems last and propagate.  Also, many problems occur due to bad
   implementations of both DNS clients and servers, especially very old
   ones, either by not following the standards or by being error prone,
   creating or allowing many of the above problems to happen.

   All these anomalies make DNS less efficient than it could be, causing
   trouble to network operations, thus affecting the overall Internet.
   This document tries to show how important it is to have DNS properly
   managed, including what is already in place to help administrators
   taking better care of their domains.

2. DNS debugging

   To help finding problems in DNS configurations and/or implementations
   there is a set of tools developed specifically for this purpose.
   There is probably a lot of people in charge of domain administration
   having no idea of these tools (and, worse, not aware of the anomalies
   that may exist in their configurations).  What follows is a
   description of some of these programs, their scope, motivations and
   availability, and is hoped to serve as an introduction to the subject
   of DNS debugging, as well as a guide to those who are looking for
   something to help them finding out how healthy their domains and
   servers are.

   Some prior knowledge from the reader is assumed, both on DNS basics
   and some other tools (e.g., dig and nslookup), which are not analyzed
   in detail here; hopefully they are well-known enough from daily
   usage.

2.1. Host

   Host is a program used to retrieve DNS information from name servers.
   This information may be used simply to get simple things like
   address-to-name mapping, or some more advanced purposes, e.g.,
   performing sanity checks on the data.  It was created at Rutgers
   University, but then Eric Wassenaar from Nikhef did a major rewrite
   and still seems to be actively working on improving it.  The program
   is available from ftp://ftp.nikhef.nl/pub/network/host_YYMMDD.tar.Z
   (YYMMDD is the date of the latest release).

   By default, host just maps host names to Internet addresses, querying
   the default servers or some specific one.  It is possible, though, to
   get any kind of data (resource records) by specifying different query
   types and classes and asking for verbose or debugging output, from



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


   any name server.  You can also control several parameters like
   recursion, retry times, timeouts, use of virtual circuits vs.
   datagrams, etc., when talking to name servers.  This way you can
   simulate a resolver behavior, in order to find any problems
   associated with resolver operations (which is to say, any application
   using the resolver library).  As a query program it may be as
   powerful as others like nslookup or dig.

   As a debugger, host analyzes some set of the DNS space (e.g., an
   entire zone) and produces reports with the results of its operation.
   To do this, host first performs a zone transfer, which may be
   recursive, getting information from a zone and all its sub-zones.
   This data is then analyzed as requested by the arguments given on the
   command line.  Note that zone transfers are done by contacting
   authoritative name servers for that zone, so it must be possible to
   make this kind of request from such servers: some of them refuse zone
   transfers (except from secondaries) to avoid congestion.

   With host you may look for anomalies like those concerning authority
   (e.g., lame delegations, described below) or some more exotic cases
   like extrazone hosts (a host of the form host.some.dom.ain, where
   some.dom.ain is not a delegated zone of dom.ain).  These errors are
   produced upon explicit request on the command line, but you may get a
   variety of other error messages as a result of host's operations,
   something like secondary effects.  These may be mere warnings (which
   may be suppressed) or serious errors - in fact, warning messages are
   not that simple, most of them are due to misconfigured zones, so it
   might not be a good idea to just ignore them.

   Error messages have to do with serious anomalies, either with the
   packets exchanged with the queried servers (size errors, invalid
   ancounts, nscounts and the like), or others related to the DNS
   information itself (also called "status messages" in the program's
   documentation): inconsistencies between SOA records as shown by
   different servers for a domain, unexpected address-to-name mappings,
   name servers not responding, not reachable, not running or not
   existing at all, and so on.

   Host performs all its querying on-line, i.e., it only works with data
   received from name servers, which means you have to query a name
   server more than once if you want to get different kinds of reports
   on some particular piece of data.  You can always arrange arguments
   in such a way that you get all information you want by running it
   once, but if you forget something or for any reason have to run it
   again, this means extra zone transfers, extra load on name servers,
   extra DNS traffic.





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


   Host is an excellent tool, if used carefully.  Like most other
   querying programs it may generate lots of traffic, just by issuing a
   simple command.  Apart from that, its resolver simulation and debug
   capabilities make it useful to find many common and some not so
   common DNS configuration errors, as well as generate useful reports
   and statistics about the DNS tree.  As an example, RIPE (Reseaux IP
   Europeens) NCC uses it to generate a monthly european hostcount,
   giving an overview of the Internet usage evolution in Europe.  Along
   with these counts, error reports are generated, one per country, and
   the whole information is made available in the RIPE archive.

2.2. Dnswalk

   Dnswalk is a DNS debugger written in Perl by David Barr, from
   Pennsylvania State University.  You'll find the latest version at
   ftp://ftp.pop.psu.edu/pub/src/dnswalk.  With the software comes a
   small document where the author points some useful advice so it may
   be worth reading it.

   The program checks domain configurations stored locally, with data
   arranged hierarchically in directories, resembling the DNS tree
   organization of domains.  To set up this information dnswalk may
   first perform zone transfers from authoritative name servers. You can
   have a recursive transfer of a domain and its sub-domains, though you
   should be careful when doing this, as it may generate a great amount
   of traffic.  If the data is already present, dnswalk may skip these
   transfers, provided that it is up to date.

   Dnswalk looks for inconsistencies in resource records, such as MX and
   aliases pointing to aliases or to unknown hosts, incoherent PTR, A
   and CNAME records, invalid characters in names, missing trailing
   dots, unnecessary glue information, and so on.  It also does some
   checking on authority information, namely lame delegations and
   domains with only one name server.  It is easy to use, you only have
   to specify the domain to analyze and some optional parameters and the
   program does the rest.  Only one domain (and its sub-domains, if
   that's the case) can be checked at a time, though.

   While in the process of checking data, dnswalk uses dig and resolver
   routines (gethostbyXXXX from the Perl library) a lot, to get such
   data as authority information from the servers of the analyzed
   domains, names from IP addresses so as to verify the existence of PTR
   records, aliases and so on.  So, besides the zone transfers you may
   count on some more extra traffic (maybe not negligible if you are
   debugging a relatively large amount of data and care about query
   retries and timeouts), just by running the program.





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


2.3. Lamers

   A lame delegation is a serious error in DNS configurations, yet a
   (too) common one.  It happens when a name server is listed in the NS
   records for some domain and in fact it is not a server for that
   domain.  Queries are thus sent to the wrong servers, who don't know
   nothing (at least not as expected) about the queried domain.
   Furthermore, sometimes these hosts (if they exist!) don't even run
   name servers.  As a result, queries are timed out and resent, only to
   fail, thus creating (more) unnecessary traffic.

   It's easy to create a lame delegation: the most common case happens
   when an administrator changes the NS list for his domain, dropping
   one or more servers from that list, without informing his parent