LINUXMAKER, OpenSource, Tutorials

Get useful information with DIG

Roll out your own named.root file

Any DNS server connected to the Internet is likely to have a copy of InterNIC's named.root file, which lists named.root for the entire Internet. This file is very easy to get with the build-it-yourself mode with dig.

dig +nocmd . NS +noall +answer +additional

Compared to the output on ftp://ftp.internic.net/domain/named.root, the TTL values will be slightly shorter, but otherwise the output will be just as up to date.

traceroute with dig

Whom traceroute is known and the way the packages take from point A to point B will appreciate this possibility even with dig. The +trace option offers similar possibilities.

dig linuxmaker.de +trace

Clearly visible is the path to the root name servers, the servers responsible for all * .de domains, and finally the name servers responsible for linuxmaker.de.

Select SOA informations

If the DNS administrator makes changes to the DNS files and wants to know if the name servers are still pushing the old data, then the + nssearch option is helpful.

dig linuxmaker.com +nssearch

All SOA entries are delivered here. Whereas the result of this command only supplies the serial number and the IP address of the respective host.

dig linuxmaker.com +nssearch | cut -d' ' -f4,11

Interpretation of TTL numbers

Time to live (TTL) is the validity period that is given to data in computer networks. When the local DNS server asks for an Internet address, the server determines where to find an authoritative response and asks for it. Once the server receives a response, it retains the response in a local cache, so if the same IP address is requested again a short time later, it can quickly deliver the response without having to re-browse the Internet.

When domain administrators configure their DNS records, they decide how long the records should remain in remote caches. This is the TTL number, which is generally given in seconds.

Typically, a remote server caches these records in its cache only for the amount of time specified by the TTL. Thereafter, the remote server clears its local cache and asks again for an authoritative response.
When dig is used to query a DNS server for a particular record, the server tells dig the time in seconds that the record will remain in the cache.

This behavior can be observed:

dig +nocmd google.com MX +noall +answer
google.com.             68      IN      MX      40 alt3.aspmx.l.google.com.
google.com.             68      IN      MX      30 alt2.aspmx.l.google.com.
google.com.             68      IN      MX      10 aspmx.l.google.com.
google.com.             68      IN      MX      20 alt1.aspmx.l.google.com.
google.com.             68      IN      MX      50 alt4.aspmx.l.google.com.

Seconds later, when the command is issued again, the TTL will already have decreased.

dig +nocmd google.com MX +noall +answer
google.com.             56      IN      MX      30 alt2.aspmx.l.google.com.
google.com.             56      IN      MX      40 alt3.aspmx.l.google.com.
google.com.             56      IN      MX      10 aspmx.l.google.com.
google.com.             56      IN      MX      20 alt1.aspmx.l.google.com.
google.com.             56      IN      MX      50 alt4.aspmx.l.google.com.

After that, the DNS server will forget the request and delete it from its cache, so that the whole cycle will start again when it requests again. Normally, the TTL is 300 seconds.

Verify DNS mappings

A misconfigured DNS system can cost time and nerves. Frankly, an incorrect character or a missing dot in the zone files already suffices to throw the entire DNS configuration overboard. Nothing will work as required. And the troubleshooting is nerve-wracking. In principle, it should be ensured that the DNS assignments work in both directions.

  • Each hostname should be resolved to an IP address and this IP address should in turn resolve to the correct hostname.
  • Once an IP address in the subnet has been assigned a reverse pointer to a hostname, then that hostname should also point to the original IP address.

Of course, there are exceptions to these two rules. For example, a CNAME is first resolved to a different hostname and then resolved to an IP address. Or sometimes several hostnames refer to the same address, but of course this IP address has only one reverse pointer.