If you manage Domain Name System (DNS) records, you probably already know how seemingly minor errors can cause big problems. Leaving a semicolon off the end of a statement, forgetting the trailing period, or failing to add that right bracket can cause a DNS server to fail to load or to respond incorrectly to requests. Dlint is a utility that will check your domains for common errors, allowing you to fix them before a problem gets out of hand. Dlint uses Domain Information Groper (DiG) and a combination shell/Perl script to gather and parse DNS information. This script can help verify your configuration and save you some troubleshooting time in the future.
What Dlint does
Dlint is basically an error checker for DNS databases. DNS allows host names to be mapped to IP addresses. Every domain name on the Internet has at least one primary “name server” (DNS server) that stores its information. This information is usually in the form of plain text files listing such DNS information as refresh rates, MX records, A records, CNAMEs, and much more.
Most DNS software, such as BIND, will perform some syntax checking when it initializes. But a number of errors that won’t halt the software from starting will still cause problems down the road. This is where Dlint comes in.
Dlint will check the DNS for a supplied domain and determine whether it contains any errors. Dlint looks for things like common typing errors, nonfully qualified domain names, and A-record-to-PTR correspondence. Dlint will also detect subdomains automatically and recursively check them. Once this information has been gathered and processed, Dlint will provide you with the results.
Dlint requires DiG 2.1 and Perl 5 or newer. Typing dig by itself should list the version number on the first line (e.g., ; <<>> DiG 9.2.1 <<>>), and entering perl –v should give you Perl’s version number. Once you have verified that both are on your system and of an appropriate version, you can start installing Dlint.
Dlint packages exist in multiple distribution formats from common software repositories such as RPMfind and freshmeat. Simply select the appropriate package for your Linux system. Alternatively, you can download the source tarball here.
Once you have the source distribution on your system, unpack it with the tar xpfz command and cd to the newly created directory. In this directory will be a file called digparse, which you will need to modify. The digparse script performs parsing functions for the various versions of DiG and passes the information to Dlint. Open it with your favorite text editor and change the first line to represent the path to Perl. This is typically /usr/bin/perl, but it may be different on your Linux distribution. Running whereis perl can help you track down this information.
You will need to manually edit a couple of additional files, the next one being the main program script itself. Open the dlint file and modify the rrfilt variable to be the destination path of digparse. The default is /usr/local/bin/digparse, and it should be fine there unless individual requirements dictate otherwise. Next, you should edit the Makefile and set your desired installation directory. The default is /usr/local and shouldn’t need to be changed for most installations. If you do need to change this, modify the DEST variable to be the desired path. Note that not everything will be installed into the root /usr/local/ directory but will end up in the appropriate subdirectories, such as bin and man. After you have completed the file editing, all that is left to do is run make install. Dlint should now be installed and ready to run.
You can run Dlint against any domain on the Internet, not just ones you administer. Since it uses DiG to gather DNS information, it can work with information gathered from any DNS server. To execute Dlint, run the command dlint and simply pass it a domain name, such as:
You can also specify a nonrecursive check with the –n command-line option. Dlint will automatically find the primary and secondary name servers for the supplied domain and attempt to do a zone transfer (AXFR). In some cases, zone transfers will be disabled to unauthorized hosts, so keep that in mind when attempting to use Dlint with domains you do not administer. If it is one of your domains and Dlint returns an error, you might need to run it locally on the name server itself or configure the DNS software to accept zone transfers from your administrator workstation.
Once you get the results, you will see that Dlint issues either a warning or an error depending on the severity of the problem. Warnings do not halt program execution, but some errors will. Warnings are basically things you should know about, possibly site-specific necessities. Errors are problems that almost always should be corrected.
The first thing Dlint verifies is whether a domain’s serial number matches across all listed DNS servers. The serial number is a method for keeping track of updates, and it is important to make sure all servers have the same version. Otherwise, newly added information may be inaccessible depending on which server answers a particular query.
Next, all A records are checked to make sure that a PTR is pointing from the IP address back to the host. This is how reverse DNS operates, and it’s widely used and highly recommended. Many Web sites and services check to make sure that these match as a security feature. If a record is missing, or they do not match, a warning is displayed. Dlint will also do the opposite when checking in-addr.arpa zones, verifying an A record exists for each PTR. These zone files contain the mappings from the IP address back to the host name. In addition, Dlint checks for the pound sign (#) character in domain records. A # is commonly used to comment out lines, but in BIND, a semicolon is used instead.
This brings us to an important point: Dlint is geared mainly toward UNIX and Linux operating systems, and especially ones running the BIND software package for DNS services. If you are investigating domains served from another platform or program, you may need to check its literature to verify whether a problem exists.
Here is the output from a test run of dlint:
;; command line: /usr/bin/dlint -n test.com
;; flags: normal-domain not-recursive.
;; using dig version 9.2.1
;; run starting: Mon Aug 5 13:35:40 PDT 2002
;; Now linting test.com
;; Checking serial numbers per nameserver
;; 2002063000 NS1.TEST.COM.
;; 2002063000 NS2.TEST.COM.
;; All nameservers agree on the serial number.
;; Now caching whole zone (this could take a minute)
;; trying nameserver NS1.TEST.COM.
;; 12 A records found.
ERROR: “rtr3.test.com. A 192.168.1.32”, but the PTR record for 22.214.171.124.in-addr.arpa. is “srvr4.test.com.”
One of the above two records are wrong unless the host is a name server or mail server.
To have 2 names for 1 address on any other hosts, replace the A record with a CNAME record: rtr3.sfo.test.com. IN CNAME srvr4.sfo.test.com.
ERROR: 126.96.36.199.in-addr.arpa. has 2 PTR records, but there should be only 1.
ERROR: www.test.com. has an A record of 192.168.1.78, but no reverse PTR record
for 188.8.131.52.in-addr.arpa. can be found on nameserver NS1.TEST.COM.
The following resource record should be added:
184.108.40.206.in-addr.arpa. IN PTR www.test.com.
;; dlint of vix.com run ending with errors.
;; run ending: Mon Aug 5 13:38:15 PDT 2002
As you can see, the Dlint program detected three errors for Test.com. The first thing it noticed was an A-record-to-PTR-record mismatch. It is possible the naming convention for a device changed or maybe IP addresses were reassigned. In most networks, such changes can be common, and it’s easy to forget to change an IP’s reverse information.
The next error Dlint saw was in 220.127.116.11.in-addr.arpa. It listed two PTRs, but Dlint was able to find only one corresponding A record. Once again, this could be an indication that the forward DNS was changed and the reverse configuration was not. And the last error shows another problem with reverse DNS—the lack of a PTR for an A record. As you can see from the error messages above, Dlint gives you some helpful information on what the problem is and what you can do to fix it, even going so far as to provide configuration suggestions.
Administration of DNS, especially in a large-scale environment, can be difficult to keep up with. Constant changes can leave holes or misconfigurations on your DNS server. Dlint will check DNS records for a domain and attempt to find possible errors, offering a quick-and-easy way to keep your DNS database viable and up to date.