In the first and second articles in this series, I introduced the powerful dig utility and its uses in performing DNS lookups along with a few time-saving examples of to put it into practice. In this part, I’ll look at my favorite dig utility feature — which is definitely the “trace” option. For those unfamiliar with this process, let’s slowly run through it.
Without a Trace
When a DNS query is made, the “chain” of events (for want of a better description) starts with the name server initiating the lookup speaking to one of the world’s “root” name servers. The root server knows, via a name server which acts as an authority for a top-level country code, which remote name server is responsible for responding to queries about that particular domain name (if that domain name exists).
Figure 1 shows the delegation from the root servers down into the key servers responsible for the delegation of the Top Level Domain (TLD) .org. Underneath those authoritative “afilias-nst” servers, we see (at the end of the output) the two name servers responsible for answering queries for the domain name sample.org. In this case ns1.mailbank.com and ns2.mailbank.com. The last salient link in the chain is:
sample.org. 300 IN A 64.99.64.45
This is the “A Record” result for the non “www” record for “sample.org” (in other words, if you just typed sample.org into a web browser without a www, this is the IP address you would visit). This is ultimately the answer we’ve been waiting for, and you might be surprised how many servers we had to ask in order to receive it.
Now that we’ve come to grips with DNS delegation and traversed the lengthy chain required for a “.org” namespace lookup, let’s compare that output with a “.co.uk” DNS lookup. Figure 2 shouldn’t cause too many headaches to decipher.
The 10 “.nic.uk” name servers (geographically disparate for resilience, which you could confirm categorically with a “WHOIS” lookup on each of their IP addresses) shows that the .UK namespace is well protected from issues. For reference, Network Information Centre (or NIC) is common parlance throughout the name server world, and if you’re ever unsure which authoritative body is responsible for a country’s domain name space, trying something like http://www.nic.uk, in the case of the United Kingdom, might save the day.
Now, let’s compare that with a much more concise output using the +short option as follows. In Figure 3, you see that the NIC’s inclusion is not displayed but instead just the other salient parts of the chain. The command that used was:
# dig +short +trace @8.8.4.4 sample.co.uk
Tick Tock
The timing of DNS lookups are clearly of paramount importance. Your boss may have invested in the latest dynamic infrastructure for your killer application, but if you are delaying each connection to your application by two seconds because of poorly configured DNS, then your users will be far from pleased.
If you see very slow response times anywhere in the chain (you can see the lookup completion results at the foot of each section in Figures 1 and 2), my advice is to turn to one of the many online tools that assists in measuring performance. They can help isolate and then identify the bottlenecks and additionally suggest improvements.
Hold on for a second. What if you needed to use the dig utility in a script and you foresaw connectivity issues or queries that wouldn’t have valid answers? You can set a timeout function as follows deviating from the default of five seconds using the +time= command switch:
# dig +time=2 chrisbinnie.tld mx
You can now be assured of running through multiple lookups, with or without lookup failures, in two-second increments.
Start of Authority
Those familiar with zone files will understand this next section. Imagine — and this almost certainly stems from the Internet of old — that you need to figure out who to contact about a domain name issue or discover certain parameters that help to control how a domain name runs its synchronisation of data between its name servers. You can discover much of this (not always entirely accurately because there can be other factors at play) by querying the start of authority (SOA) of a domain name.
Here is a “short” example, which I’ll explain in a second with its output following:
# dig +short @8.8.4.4 chrisbinnie.tld soa
toma550561.mars.orderbox-dns.com. transfer.active-domain.com. 2014102717 7200 7200 172800 38400
Let’s compare that slightly unusual numerical output to a default display of a SOA query using the dig utility in Figure 4.
To achieve a reasonable amount of detail but in a sensible way, the command line I used was:
# dig +multiline @8.8.8.8 chrisbinnie.tld SOA
The +multiline option tries its best to offer a formatted layout coupled with helpful comments. In the case of the SOA, I’m sure that you’ll agree it makes sense of an otherwise difficult to read output under the AUTHORITY SECTION.
I, for one, think that’s much less cryptic. The “serial” number in an SOA is a simple measure of when a change to the domain name was last made. Request For Comments (RFCs), which are technical specifications for the Internet, most likely recommend the serial takes the form of a date format shown backward as seen in our example.
Apparently (but this may not be the case), that RFC 1035 holds fort for SOA recommendations, which can be found here https://www.ietf.org/rfc/rfc1035.txt if you would like some enlightening, bedtime reading.
Other name servers simply increment a long number such as 1000003 each time there’s a change. This process admittedly doesn’t help with when an update was made, but at least it lets you know which version of a zone file you are looking at. This is important because when sharing updates between many name servers, it’s imperative that they answer with the most up-to-date version of the DNS and do not respond with stale, potentially damaging information.
In case you’re wondering, we’re seeing the “root-servers.net” and “verisign-grs.com” domain names being mentioned because the domain name “chrisbinnie.tld” doesn’t exist (I’m just using it as an example). So Figure 4 is showing the SOA for “a.root-servers.net” instead, which is the first link in the chain for our non-existent DNS lookup.
The “refresh” field looks at how soon secondary name servers are to come back for new information (secondaries and tertiaries are name servers serving the same information for resilience in addition to the primary). Usually this value sits at 24 hours but it’s shorter for a root server. The “retry” is how quickly to try a “refresh” that failed again. On a name server that isn’t a root server, you would expect this to be 7200 seconds (two hours).
The “expire” field lets secondary name servers know when the answers it has been serving should be considered stale (or, in other words, how long the retrieved information remains valid).
Finally, the “minimum” field shows secondaries (also called “slaves”) how long the received information should be cached before checking again. This has been called the setting with the greatest importance thanks to the fact that, with frequent changes to your DNS, you need to keep secondaries frequently updated.
The tricky balance, however, is that if you don’t make frequent DNS updates, keeping this entry set to a matter of days is best to keep your DNS server load down. The rule of thumb is that to speed up a visitor’s connection time, you really don’t want to enforce a DNS lookup unless you’re making frequent changes. On today’s Internet, this is less critical because name server traffic is relatively cheap thanks to its tiny packet size and the efficiency of modern name servers. It’s still a design variable to consider however.
When You’re Ready
And, at the risk of sounding melodramatic, when it comes to DNS, every millisecond really does count.
Another quick note about Figure 4 is that “a.root-servers.net” is the authoritative name of the name server for that domain name’s zone. And, separately, the “nstld.verisign-grs.com” entry is the contact method of the domain name administrator, which I mentioned earlier. Although it’s a strange format if you haven’t seen it before — to avoid the use of the @ symbol I assume — this field is actually translated as “nstld@verisign-grs.com” into a functioning email address.
Finally, the “1799” at the start of that line is the Time To Live — which means how many seconds (30 minutes in this case, minus a second) connecting client software should hold onto the retrieved data before asking for it again, in the event that it’s changed in the meantime.
In the fourth and final part of this series, I’ll take a quick look look at some security options and wrap up with more examples that I have found very useful.
Chris Binnie is a Technical Consultant with 20 years of Linux experience and a writer for Linux Magazine and Admin Magazine. His new book Linux Server Security: Hack and Defend teaches you how to launch sophisticated attacks, make your servers invisible and crack complex passwords.
Learn more about network and system management in the Essentials of System Administration training course from The Linux Foundation.
