Dlint version 1.4.0
A Domain Name Server Zone Verification Utility
Copyright (C) 1993-1999 Paul A. Balyoz <email@example.com>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
This program analyzes any DNS zone you specify, and reports any problems it
finds by displaying errors and warnings. Then it descends recursively to
examine all zones below the given one (this can be disabled with a command-
line option). Designed for Unix, dlint is written in Bourne Shell and Perl.
Dlint is also available on the Internet from your web browser:
(this server imposes a timeout period; to lint a big zone, you should
install dlint yourself and use it locally - that's what this package is for).
WHAT DLINT REALLY CHECKS
* for each nameserver of the given zone, if its domain name ends in
"in-addr.arpa." then give a warning & ignore it. This can happen
in in-addr.arpa. zones when an NS record contains just a host name
instead of the fully-qualified domain name.
* for each host with an "A" resource record containing an IP address,
there should be an equivalent PTR record pointing from the address
back to the host. Missing records and IP address mismatches are
reported. (exception: when it's really a domain instead of a host,
there may not be a PTR record).
* for each PTR resource record in an in-addr.arpa zone pointing to a host,
there should be an equivalent "A" record for that host listing the same
IP address. Missing records and IP address mismatches are reported.
* special warning if it detects a pound-sign on the front of a record
(a common mistake: using "#" for comment symbol instead of ";").
Dlint will notice if there are subdomains (subzones), and recursively traverse
them, too, looking for problems. This recursion can be disabled with a
You can run dlint on your own domains, or on somebody else's, because it uses
the standard DNS network protocol. Dlint is very useful since most nameservers
do no more than syntax-check your database files. Dlint's messages are very
informative and suggest ways to fix the problems, not just complain about them.
Dlint doesn't catch every kind of problem, just the ones listed here which
can cause strange host-access problems for you and for other sites trying
to reach your computer systems over the Internet.
* DiG 2.1 or newer
* Perl 5 or newer
See file "INSTALL" for details.
RUNNING DLINT, READING ITS OUTPUT
Make sure "dig" is in your path. Type "which dig" to see if it is.
If not, go and get DiG and install it now! (see below)
% dlint your.dom.ain.
% dlint 184.108.40.206.in-addr.arpa.
Dlint is fairly verbose; comment lines are preceded by semicolons (";").
Any line not commented out is something important: a warning or an error.
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 220.127.116.11.in-addr.arpa. says "localhost."
(one of the above two records might be wrong.)
This is not really a problem because Unix systems sometimes use records 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.
If you see different output at different times for the same zone that you
know is not being modified, then get and run the Doc utility (see below)
over your domain first. Some authoritative nameservers for the zone have
different copies of the zone database (check their SOA records).
* Rewrite in Perl using Net::DNS
* Lame delegation checking
* CIDR support
* IPv6 support
* Character-set checking on all domain names
* Detect duplicate domain components and report "missing end-period in zone
file". Example: host.cse.nau.edu.cse.nau.edu. should be host.cse.nau.edu.
* Let user specify what server to query (command-line option)
* Domain Obscurity Checker (DOC), which comes with BIND. 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
results. If a zone is sufficiently misconfigured, Dlint has trouble
producing useful information. BIND comes from:
* FYI 27 - Tools for DNS Debugging. http://www.landfield.com/rfcs/fyi/fyi27.html
* RFC's on DNS, available at http://www.landfield.com/rfcs/
RFC 1032 - Domain Administrators Guide
RFC 1033 - Domain Operations Administrators Guide
RFC 1034 - Domain Names Concepts and Facilities
RFC 1035 - Domain Names Implementation and Specification
RFC 1101 - DNS Encoding of Network Names and Other Types
RFC 1123 - Requirements for Internet Hosts
RFC 1536 - Common DNS Implementation Errors and Fixes
RFC 1713 - Tools for DNS Debugging
RFC 1912 - Common DNS Operational and Configuration Errors
RFC 2181 - Clarifications to the DNS Specification
RFC 2182 - Selection and Operation of Secondary DNS Servers
The latest version of Dlint can be found at the master site:
Paul Balyoz, Unix Sysadmin and Programmer
Domtools Consulting firstname.lastname@example.org
Phoenix Arizona, USA email@example.com