In the first article in this series, I provided an introduction to the powerful dig utility and its uses in performing DNS lookups. For those who haven’t used the command before, these articles will give a useful overview of its features and capabilities. This time, I’ll explain how dig syntax differs from other packages and offer some time-saving examples.
To TCP or Not to TCP
Many name servers on the Internet today do use UDP on occasion, especially for larger packet sizes (e.g., for IPv6 or DNSSec). TCP responses are also made available on some name servers, however. And, if my memory serves, one of the first times I ever used the dig utility was to query a TCP name server. The format might look something like this if you needed to use such a command, by querying a popular DNS Resolver “8.8.8.8”:
# dig +tcp @8.8.8.8 chrisbinnie-linux.tld
Get the Syntax Right
Although the for dig syntax is a little different from other DNS lookup packages, there’s a very simple “+” or “no” structure to the options that it offers, which I particularly like.
For example, if you wanted to perform UDP lookups only, then you would simply add “no” to the beginning of the TCP parameter, as follows:
# dig +notcp @8.8.8.8 chrisbinnie.tld
It’s very simple; I’m sure that you’ll agree.
Additionally, there are a significant number of features available with the dig utility. Let’s look at the displaying of Time To Live (TTL) settings on a DNS record — in other words, the countdown until a record should be refreshed to prevent it from going stale. This command can be entered as “+[no]ttlid” options. An example of this option in use might be:
# dig +ttlid chrisbinnie.tld
The standard output from the dig utility is very verbose and — certainly in comparison to “host” — I find it a little unwieldy. I will start off by looking at the “short” output version of the dig utility. The output is shown below as an example IP address “1.2.3.4”.
# dig chrisbinnie.tld +nocomment +nostats +short 1.2.3.4
Without the “+short” addition, we see the following:
# dig chrisbinnie.tld +nocomment +nostats ; <<>> DiG 9.8.1-P1 <<>> chrisbinnie.tld +nocomment +nostats ;; global options: +cmd ;chrisbinnie.tld. IN A chrisbinnie.tld. 37765 IN A 1.2.3.4
We can now do exactly the same but include the default comments and statistics parameters. You can see the default output offers significantly more detail:
# dig chrisbinnie.tld ; <<>> DiG 9.8.1-P1 <<>> chrisbinnie.tld ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58982 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;chrisbinnie.tld. IN A ;; ANSWER SECTION: chrisbinnie.tld. 35636 IN A 1.2.3.4 ;; Query time: 15 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Nov 8 20:22:27 2014 ;; MSG SIZE rcvd: 44
I hope the majority of the answer’s output here is self-explanatory. The question and answer sections are really very close to a DNS query-and-response’s model. It’s important to note the section stating the server which was used (under “SERVER” we see “localhost” because we didn’t query a name server directly with the “@server” parameter). There is mention of the standard DNS port following that output under “#53”. Also the “Query time” section can offer insight into server load issues and connectivity bottlenecks.
Fill Your Boots
One time-saving feature that would undoubtedly help if used within scripts is being able to ingest a potentially lengthy list of hostnames to query from a text file. We can use the “-f” switch to activate the reading of a file.
# dig -f file_full_of_hostnames
You can simply list a new hostname to query on each line of a file in a list and then run a command over it as above.
Respect My Authority!
If, for example, you wanted to check all of the name servers responsible, authoritatively, for a domain name, then you could swiftly achieve this with a command like this:
# dig ultradns.com NS +noall +answer ultradns.com. 236 IN NS pdns196.ultradns.org. ultradns.com. 236 IN NS pdns196.ultradns.com. ultradns.com. 236 IN NS pdns196.ultradns.info. ultradns.com. 236 IN NS pdns196.ultradns.net. ultradns.com. 236 IN NS pdns196.ultradns.biz. ultradns.com. 236 IN NS pdns196.ultradns.co.uk.
For simplicity, I have pruned the output a little ,but you can see that the domain name that we queried has a healthy geographical coverage when it comes to its authoritative name servers. This is by design, to provide optimal levels of resilience.
The Future Has A Number Six
We couldn’t possibly expect IPv6 to be ignored by the superb dig utility, even though the excellent DNS tool heralds from a time well before IPv6 was popularly used. However, because it’s part of one of the most widely used DNS servers on the planet — namely BIND — we can safely say that IPv6 functionality will be present in the dig utility.
This example of querying IPv6 is relatively intuitive. To check an “AAAA” record, you would do the following:
# dig google.com AAAA +short 2a00:1450:400c:c00::71
Next Time
In part three of this series, I’ll take a closer look at favorite dig utility feature — the “trace” option.
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.
