
			      Dlint Version 1.1.2

		  A Domain Name Server Verification Utility

		    By: Paul Balyoz <pbalyoz@netzone.com>
                  Copyright (c) 1993-1997 by Paul A. Balyoz

DESCRIPTION

This program can analyze any regular or in-addr domain, either singularly or
recursively, notifying you of possible problems it sees by printing out
errors and/or warnings.

Here's what dlint checks for you:

    * hosts with "A" records giving an IP address but no PTR record pointing
      from the address back to the host.  (exception: when "A" record is for
      a domain instead of a host, in which case there may not be a PTR record).

    * in-addr PTR records giving a host domain name which has no associated
      "A" record.

Dlint will notice if there are subdomains (subzones), and recursively traverse
them as well, looking for problems.

You can run dlint on your own domains, or on somebody else's.  Dlint is very
useful since most nameservers do no more than syntax-check your database files.
Dlint's messages are very informative, often suggesting ways to fix problems
that it finds.

Note that dlint doesn't catch every kind of problem, just the ones listed above
which can cause strange host access problems for you, and for other sites trying
to reach your computer systems on the Internet.


REQUIREMENTS

Dlint requires DiG version 2.0 or later.  To see if you have it, just type "dig".
The first line of output tells the version.  Example:

	; <<>> DiG 2.1 <<>> 

The latest version of DiG is always available with the BIND nameserver package
available at:

	http://www.isc.org/isc/bind/


INSTALLATION

Edit Makefile, then type "make install" to install dlint.  Or, you can simply
run dlint from this directory.


RUNNING DLINT AND ITS OUTPUT

	% dlint your.dom.ain.
or:
	% dlint 4.3.2.1.in-addr.arpa.

Dlint is fairly talky; comment lines are preceded by semicolons (";").
Any line not commented out is something important: a warning, an error,
whatever.

Not all warnings and errors are really problems -- you need to use your best
judgment when considering making changes to your DNS database.  One warning you
might see which you can ignore is:

   WARNING: "localhost.cse.nau.edu. A 127.0.0.1": the PTR record for 1.0.0.127.in-addr.arpa. says "localhost."
        (one of the above two records might be wrong.)

This is not really a problem because Unix systems can really use a record like
"localhost.cse.nau.edu." in their local domain to speed up "localhost"
address queries.  Every zone containing Unix machines should have one of
these fake "localhost" hosts in it with an address of 127.0.0.1.

Another warning that may not be a problem looks like this:

   WARNING: csenet.cse.nau.edu. has no A record, but that's OK only if it's a network or other special name instead of a host.

If that domain name is the name of a network or subnet at your site
and _not_ the name of an actual host (no single IP address is associated
with it), then ignore it.  If you know it's supposed to be a host, then
an A resource-record should be added to the zone it lives in.


FUTURE ENHANCEMENTS

 * Detect duplicate domain names and report "missing end-period",
   for example, if we see: host.cse.nau.edu.cse.nau.edu.

 * Character-set checking on all domain names

 * Optionally verify your RFC 1101 compliant domain records,
   if they are implemented in your domain database files.

 * Comprehend CIDR style subnet records

 * Zones with SOA but no NS, or NS but no SOA


SEE ALSO

 * Doc, which comes with Dig.  It checks for lame delegations and other
   problems with just your primary/secondary nameservers.  Solve those
   problems first, then run Dlint to get the best output.


--
Paul Balyoz                                 pbalyoz@netzone.com
Unix Systems Admin & Programmer             pbalyoz@sedona.intel.com
Intel Corporation, Chandler AZ
