Dig

Dig is a powerful tool, as you have already learned in Chapters 1, "DNS Concepts," and 2, "DNS in Practice." The following is the most general command-line syntax for Dig:

 dig [@server] domain [<query-type>] [<query-class>] [+<query-option>]          [-<dig-option>] [%comment]

Behind this inoffensive command line, Dig hides more options than you can shake a stick at.

Dig requires that you think about what kind of record you want retrieved and that you stop to think about the correct name to look up. A tool such as host will gladly look up 192.168.55.3 for you, understanding that you want the PTR record of 3.55.168.192.in-addr.arpa. Dig will not, and its default record type is A. In addition, dig -h will print usage information. Dig is documented extensively in its man page, but let's examine each command-line term here:

• @server This is optional. If unspecified, the server in /etc/resolv.conf is used. This is either the server's address or name. If DNS is not working on your host, it might be because a name can't be resolved, so you might have to provide an address. The server also might be specified in the LOCALRES environment variable, which is Dig specific and will not be picked up by any other software.

• domain This is the domain name you want to look up. Dig obeys the domain and search directives in /etc/resolv.conf. It also obeys the convention that names ending in a period (.) are FQDNs and won't be subject to the search and domain directives. See the -x option for a convenient way to specify reverse queries.

• query-type The type of the record you want. See the following section, "Query Type," for a list of available types.

• query-class The class of record you want. in, which stands for Internet, is the default and what you want in most cases. any is a special value and acts as a class wildcard. See RFC 1035 for a list of classes.

• +query-option This affects the contents or processing of queries in Dig or in the nameserver. See the section "Query Options" for a list of available keywords.

• -dig-option These options change Dig's behavior. See the section "Dig Options" for a list of options.

• %comment All command-line words starting with the percent sign (%) are ignored. This is meant to be used as documentation. In the following example, @ provides the numerical address of the nameserver and the comment tells which nameserver it is:

  dig @192.168.55.2 %ns.penguin.bv mail.herring.bv. A

Query Type

The query type is the type of record you want. If omitted, it is set to a, which causes you to get an A record back (if any of them match the domain name). The following are some of the record types:

• A Network address.

• MX Mail exchanger.

• NS Nameserver.

• SOA Start of Authority.

• HINFO Host information.

• AXFR Zone transfer. Zone transfers require that you query an authoritative server. You must locate this by looking up NS records for the zone. Some authoritative servers will deny zone transfer if you're requesting it from an unauthorized location. See Chapter 8, "Security Concerns," for more information.

• TXT The TXT record.

• SRV Service. This is a relatively new record type, but it's very useful. It is used heavily by Windows 2000 to locate services within domains. This record is also flexible enough to replace the MX and NS records. If you're designing a new protocol, consider using this record.

For a complete list of record types, see Chapter 13, "Resource Records."

Query Options

Query options affect the processing of queries in nameservers and in Dig. Their format is as follows:

 +keyword[=value]

Table 5.1 shows the keywords available and their values.

Table 5.1. Keywords for Query Options

Keyword	Abbrev.	Value	Default	Description
[no]debug	[no]deb	nodeb		Enables and disables debugging output.
[no]d2	nod2			Enables and disables even more debugging output.
[no]recurse	[no]rec	rec		Enables and disables recursive lookup.
[no]defname	[no]def	def		[Don't] use the default domain name.
[no]search	[no]sea	sea		[Don't] use the default search list.
domain	do	<domain>		Sets default domain name.
retry	ret	#	4	Number of retries.[1]
time	ti	#	4	Timeout length in seconds.[1]
[no]ko			noko	[Don't] keep open. koimplies vc.
[no]vc			novc	[Don't] use virtual circuit.
				Uses a TCP connection for the query.
[no]primary	[no]pr		nopr	[Don't] use the primary server.
				Primary is not implemented.
[no]aaonly	[no]aa		noaa	Only authoritative answers wanted.
				aaonlyis not implemented.
[no]cmd			cmd	Echo parsed arguments.
				This is the ; <<>>DiG... line.
[no]stats	[no]st		st	Prints query statistics.
				This is the tail containing the time of query, time used, and so on.
[no]Header	[no]H		H	Prints (basic) reply header information. This is the information starting with ->>HEADER<<-. Note the capital H in the option.
[no]header	[no]he		he	Prints reply flags. This is the line starting with ;;flags:.
[no]ttlid	[no]tt		tt	Prints TTL information.[2]
[no]cl			nocl	Prints class information.[2]
[no]qr			qr	Prints outgoing query.
[no]reply	[no]rep		rep	Prints reply.
[no]ques	[no]qu		qu	Prints the question section.
[no]answer	[no]an		an	Prints the answer section.
[no]author	[no]au		au	Prints the authoritative section.
[no]addit	[no]ad		at	Prints the additional section.
pfdef				Sets print flags to default output.
pfmin				Sets print flags to minimal output.
pfset		#		Sets print flags.
pfand		#		Performs bitwise andon printflags.[3]
pfor		#		Performs bitwise oron printflags.[3]

^[1] The retry and time options affect the resolver's retransmission strategy when sending queries by UDP. It uses an exponential backoff loop; time is the initial timeout; and time doubles for each of the retries.

^[2] As of this writing, the nott and nocl options are nonfunctional.

^[3] These options can only be used meaningfully if you've read the source of Dig. However, I don't recommend that; I would use the regular print options.

Dig Options

The query options are not the end of it; several more Dig options exist:

• -x <dotted.address> This is the fast lane to dotted.address-reversed.in-addr.arpa. In other words, it's a convenience switch for reverse lookups. The default query type is changed from A to ANY.

• -f <file> Batch file. Stuff a file with queries and Dig batch will execute it. See the following section, "Dig Batch Files," for more information.

• -T <time> Time in seconds between the starts of successive queries in a batch. This can be used to keep two batches roughly in synch.

• -p <port> Query a non-standard port. The default is 53.

• -P [<ping-string>] Executes ping for response time comparison. By default, ping -s server_name 56 3 is executed, and on the three last lines, the timing summary is executed.

• -t <query-type> Alternative way of specifying the query type. Here the numerical value is allowed as well as the symbolical ones discussed in the previous bullet and in Chapter 13.

• -c <query-class> Alternative way of specifying the query class. Numerical class as well as symbolic is allowed.

• -k <keydir:keyname> Sign the query with the named TSIG key.

• -envsav Save the parsed settings and options in the file named by the environment variable LOCALDEF; or, if it is undefined, a file called DiG.env in the current working directory. If you dislike Dig's defaults, this is a nearly permanent way of overriding them. Each time Dig is run, this file is loaded, if present. (See also -envset.)

• -envset Used for batches. After the Dig environment has been set up, it becomes the default for all subsequent queries, until -envset occurs again. The options on later lines then modify this default.

• -[no]stick Used for batch runs and makes the Dig environment sticky (or not).

Dig Batch Files

Dig can process queries in batches. After you realize this, some of the options in Dig's feature set make more sense. After a Dig or query option is set, it is persistent, or sticky, and you need a way to reset it. You can use the +ko option to keep a TCP connection open for several queries. The following is an example of a batch file:

 www.penguin.bv. A +pfmin +ko +vc ns.penguin.bv. A

The first line executes the given query. The options given on it are persistent, so +pfmin will be in force for the next query as well. If, sometime later in the batch file, you want to reset the print flags, just specify +pfdef.

The previous batch file results in this output:

 $ dig -f dig-batch ;; res options: init usevc recurs defnam styopn dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19036 ;; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; QUERY SECTION: ;;      www.penguin.bv, type = A, class = IN ;; ANSWER SECTION: www.penguin.bv.         1w2d7h33m20s IN A  192.168.55.3 ;; res options: init usevc recurs defnam styopn dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19039 ;; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; QUERY SECTION: ;;      ns.penguin.bv, type = A, class = IN ;; ANSWER SECTION: ns.penguin.bv.          1w2d7h33m20s IN A  192.168.55.2

As you can see, two queries were sent and answered, with somewhat reduced output for each query. Dig can clearly be used for much more complex batch jobs; this was just an example.

Dig's Output

Not all Dig output is easy to read. Consider the following:

  1 $ dig www.penguin.bv.  2  3 ; <<>> DiG 8.2 <<>> www.penguin.bv.  4 ;; res options: init recurs defnam dnsrch  5 ;; got answer:  6 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4  7 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1  8 ;; QUERY SECTION:  9 ;;      www.penguin.bv, type = A, class = IN 10 11 ;; ANSWER SECTION: 12 www.penguin.bv.         1w2d7h33m20s IN A  192.168.55.3 13 14 ;; AUTHORITY SECTION: 15 penguin.bv.             1w2d7h33m20s IN NS  ns.penguin.bv. 16 penguin.bv.             1w2d7h33m20s IN NS  ns.herring.bv. 17 18 ;; ADDITIONAL SECTION: 19 ns.penguin.bv.          1w2d7h33m20s IN A  192.168.55.2 20 21 ;; Total query time: 7 msec 22 ;; FROM: lookfar to SERVER: default -- 127.0.0.1 23 ;; WHEN: Fri Apr 21 00:04:16 2000 24 ;; MSG SIZE  sent: 32  rcvd: 116

On line 3, Dig repeats the command-line options, parsed and digested. Line 4 summarizes the query options set. By this, you can tell that the previous query is recursive. The names used on this line is the same as on the command line. On line 6 you find the query status, which should read NOERROR. However, if you see SERVFAIL, a problem is indicated.

On line 7 these flags can occur:

Flag	Meaning
qr	This is a query response.
aa	The answer was an authoritative answer. This is valid only for the answer section.
tc	The answer was truncated because it was too long. This should never be set if you use +vc or a TCP connection for the query.
ra	Recursion Available. Denotes whether the server is recursive.
rd	Recursion Desired. Use this when you want recursive answers.

In DNS the structures of queries and answers are more or less the same. Low-level code can tell which is which by the qr flag. The aa flag is set in answers where the contents of the ANSWER SECTION are authoritative, which means that either it was directly out of a zone for which the server was authoritative or a cache server got the answer from such a server on your behalf. Therefore, if the answer is out of a cache, the aa flag is not set. In Chapter 1 you learned that the first Dig query for www.amazon.com has the aa flag set, whereas the second does not. This is because the second query was answered out of the local DNS cache. The tc flag warns queries that a answer that was transported over UDP was truncated. Answers over UDP connections are limited to an MTU usually about 1,500 bytes. If your query has many answers, this might not be enough even if DNS answers are very tightly coded and compressed. In such a case, using a TCP connection and specifying +vc should help.

The ra and rd flags are symmetrical. The rd flag is used by queries to indicate that recursion is desired (that they want the server to do the work for them). Most DNS clients set this flag, but most nameservers don't. The ra flag, on the other hand, indicates whether the server was willing to recurse for you. Root servers are typically not willing to recurse, whereas your local nameserver typically is willing to recurse.

Still using the previous code example, notice that line 7 contains the number of records in each section of the answer one record in the query, one in the answer, two in the authority section, and one in the additional section. On lines 8 19, you first see the query, and then on line 11, you see the contents of the answer, which has three parts. You know the size of each part it consists of from the record counts on line 7. The ANSWER SECTION contains the direct answer to the query you issued. Conversely, the AUTHORITY SECTION contains the NS records of the zone, which tell you which servers are authoritative for it. If you have a caching server, this is good information to have for later. The ADDITIONAL SECTION contains any additional records the nameserver thought might be handy. This almost always contains A records for MX or NS records occurring earlier in the answer.

The STATS SECTION is the last section. It contains information about when the query was sent, from where it was sent, to which server it was sent, and how much time it took to get the answer. This can be indicative of line load, latency, packet loss, and many other things.

Using Dig

But I was supposed to tell you how you use Dig. Of course, you have already seen Dig being wielded in Chapter 1. If you go back and look at the commands in that chapter, you should be able to understand them this time around. Here is a Dig command you would not have been able to come up with based on any documentation I know. I learned it by "word of Usenet":

 $ dig CHAOS version.bind TXT ; <<>> DiG 8.2 <<>> CHAOS version.bind TXT ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;;      version.bind, type = TXT, class = CHAOS ;; ANSWER SECTION: VERSION.BIND.          0S CHAOS TXT    "8.2.2-P5" ;; Total query time: 54 msec ;; FROM: lookfar to SERVER: default -- 127.0.0.1 ;; WHEN: Fri Apr 21 00:30:45 2000 ;; MSG SIZE  sent: 30  rcvd: 63

This code tells you what version of BIND I was running on April 21, 2000. Some DNS servers either do not implement this or have the version string set to wouldn't you like to know or something similar for reasons of security.