Dlint version 1.4.0 A Domain Name Server Zone Verification Utility Copyright (C) 1993-1999 Paul A. Balyoz 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. DESCRIPTION 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: http://www.domtools.com/dlint/ (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 command-line option. 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. REQUIREMENTS * DiG 2.1 or newer * Perl 5 or newer INSTALLATION 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. or: % dlint 4.3.2.1.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 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 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). FUTURE ENHANCEMENTS * 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) SEE ALSO * 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: http://www.isc.org/bind.html * 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 DISTRIBUTION The latest version of Dlint can be found at the master site: http://www.domtools.com/dns/dlint.shtml -- Paul Balyoz, Unix Sysadmin and Programmer Domtools Consulting pab at domtools dotcom Phoenix Arizona, USA pbalyoz at jammed dot com