Specialized DNS Tools

Authoritative DNS servers are databases that contain all the records describing a domain in what are called 'zones'. When you do an IP address lookup of a hostname within a domain, that query may end up going all the way to the authoritative servers using a process known as recursion or it may come from a cached record along the way.

There are usually two authoritative servers, but sometimes more servers are used in the case of a large company with a distributed network. In some DNS implementations, the DNS maintainer changes a record like an MX record defining which machine handles SMTP email by hand and at the same time changes the serial number to show that the zone was altered. This serial number change is automated in other implementions.

The secondary servers get zone information from the primary server when they see that the serial number in SOA record in the primary server is different than the serial number currently in the secondary server. If the serial numbers are not the same, then a "zone transfer" is initiated either using a full zone AXFR or an incremental zone IXFR transfer.

As a side note, zone serial numbers are usually in one of two formats, the first being the most common: YYYYMMDDNN format, where YYYY is the year (four digits), MM is the month (two digits), DD is the day of month (two digits) and nn is the version per day (two digits); the second format is unix time, ie. the number of seconds since Jan 1, 1970. Some DNS maintainers use a simple incrementing number like a revision number.

If there is a breakdown in the process of replicating data between the primary and secondary servers (some DNS software can use methods other than zone transfers), the serial numbers may end up out of sync--especially if the serial number is maintained by hand. To check this, a DNS maintainer would have to individually query each authoritative DNS for its current serial number using NSLOOKUP or DIG to verify that they are all in sync.

To help speed up this process, I have created a new tool that finds the authoritative servers for a domain, then it quickly checks each authoritative server for serial number mismatches. It analyzes the results and tells you if there is a problem -- and since we show each authoritative server with its serial number for the zone, you can quickly see the results yourself. This new tool is tentatively called "Auth Serial Check" and it appears in the new DNS Tools - Advanced window in NetScanTools Pro 10.8 (which is not out yet -- be patient).

dig +trace

If you are curious about how DNS works, you probably should have a look at dig +trace. Dig +trace gives you a hierarchical listing of the DNS servers responsible for each level of a domain name.

The tool starts by going to the top level name servers (you know, the 13 root servers that make DNS work) and asking for the top level domain name servers for .com or .net or .uk or .whatever. Then it picks one of those top level servers and asks for the servers responsible for the next level, like netscantools.com, etc. It does this until it finds the authoritative servers for the hostname or domain name or IP address you entered.

It's great for getting a top down view of how the DNS system works. You can also see if there are problems finding the authoritative servers. You can do this from the unix/linux command line (dig hostname +trace) or from our software.

Here is an example using www.microsoft.com as an input to NetScanTools Pro's Name Server Lookup tool:

[Start Query]
DiG Starting Timestamp: 11/14/08 21:03:54

; <<>> DiG 9.x <<>> www.microsoft.com +trace
. 65326 IN NS a.root-servers.net
. 65326 IN NS b.root-servers.net
{snip}
;; Received 228 bytes from 208.200.248.8 (208.200.248.8) in 63 ms

com. 172800 IN NS H.GTLD-SERVERS.NET
com. 172800 IN NS I.GTLD-SERVERS.NET
{snip}
;; Received 509 bytes from a.root-servers.net (198.41.0.4) in 140 ms

(note: these are the authoritative domain servers for handling the queries for hostnames in the microsoft.com domain)
microsoft.com. 172800 IN NS ns1.msft.net
microsoft.com. 172800 IN NS ns2.msft.net
microsoft.com. 172800 IN NS ns3.msft.net
microsoft.com. 172800 IN NS ns4.msft.net
microsoft.com. 172800 IN NS ns5.msft.net
;; Received 209 bytes from H.GTLD-SERVERS.NET (192.54.112.30) in 234 ms

www.microsoft.com. 3600 IN CNAME toggle.www.ms.akadns.net
;; Received 73 bytes from ns1.msft.net (207.68.160.190) in 62 ms

[End Query]

With each level, you can see that a number was returned. This is the TTL (time-to-live) for the DNS record in seconds. If you do the dig +trace query again, the numbers for the root servers will be smaller reflecting the time you took between queries.

You can see that ns1 told us that www.microsoft.com is aliased to a server handled by Akamai. It did not tell us the IP address -- we did an 'ANY' query and the CNAME record was all that was returned to us.