Verify DNS records with Dlint
ZDNet
Published: 05 Sep 2002 13:07 BST
Running Dlint
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: dlint test.com
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 32.1.168.192.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: 66.2.168.192.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 78.1.168.192.in-addr.arpa. can be found on nameserver NS1.TEST.COM.
The following resource record should be added:
78.1.168.192.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 66.2.168.192.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.
Summary
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.
Have your say instantly in the
Tech Update forum.
Find out what's where in the new Tech Update with our
Guided Tour.
Let the editors know what you think in the
Mailroom.
Previous
Did you find this article useful?
136 out of 266 people found this useful
- Share this article:
