dig - send domain name query packets to name servers


dig [server] domain [<query-type>] [<query-class>]


The dig(1) (domain information groper) utility is a flexible command-line tool that can be used to gather information from Domain Name System (DNS) servers. The dig(1) utility has two modes: simple interactive mode for a single query, and batch mode, which executes a query for each in a list of several query lines. All query options are accessible from the command line.

The usual simple use of dig(1) will take the form:

dig server domain query-type query-class
Can be either a domain name or a dot-notation Internet address. If this optional field is omitted, dig(1) will attempt to use the default name server for your computer.

If a domain name is specified, this will be resolved using the DNS resolver (that is, BIND). If your system does not support DNS, you may be required to specify a dot-notation address. Alternatively, if there is a server at your disposal somewhere, you need only ensure that /etc/resolv.conf be present and indicate where the default name servers reside, so that server itself can be resolved. See resolver(1)(5) for information on /etc/resolv.conf.


The domain name for which you are requesting information. See the -x option (documented in the OTHER OPTIONS subsection of this topic) for a convenient way to specify inverse address query.
The type of information (DNS query type) that you are requesting. If omitted, the default is a (T_A = address.) The following types are recognized:
a T_A Network address
Any T_ANY All/any information about specified domain
mx T_MX Mail exchanger for the domain
ns T_NS Name servers
soa T_SOA Zone of authority record
hinfo T_HINFO Host information
axfr T_AXFR Zone transfer (must ask an authoritative server)
txt T_TXT Arbitrary number of strings

See RFC 1035 for the complete list.

The network class requested in the query. If omitted, the default is in (C_IN = Internet.) The following classes are recognized:
in C_IN Internet class domain
any C_ANY All/any class information

See RFC 1035 for the complete list.

Note that "Any" can be used to specify a class, a type of query, or both. The dig(1) utility will parse the first occurrence of "any" to mean query-type=T_ANY. To specify query-class=C_ANY, either specify "any" twice, or set query-class using the -c option (as described later).


% ignored-comment
The percent sign (%) includes an argument that is simply not parsed. This may be useful if you are running dig(1) in batch mode. Instead of resolving every @server-domain-name in a list of queries, you can avoid the difficulties of doing so, and still have the domain name on the command line as a reference. An example follows:
dig @ %venera.isi.edu mx isi.edu
The hyphen (-) specifies an option that affects the operation of dig(1). The following options are currently available (although they are not guaranteed to be useful):
-x dot-notation-address
Convenient form to specify inverse address mapping. Instead of using:
you can use:
dig -x
-f file
File for dig(1) batch mode. The file contains a list of query specifications (dig(1) command lines) that are to be executed successively. Lines beginning with ;, #, or \n are ignored. Other options can still appear on the command line, and will be in effect for each batch query.
-T time
Time, in seconds, between the start of successive queries when running in batch mode. Use it to keep two or more batch dig(1) commands running more or less synchronously. Default is zero.
-p port
Port number. Query a name server listening to a nonstandard port number. Default is 53.
-P [ping-string]
After query returns, execute a ping(1) command for response-time comparison. This rather unelegantly makes a call to the shell. The last three lines of statistics are printed for the command:
ping -s server_name 56 3

If the optional ping_string is present, it replaces ping -s in the shell command.

-t query-type
Specify type of query. Can specify either an integer value to be included in the type field, or use the abbreviated mnemonic as discussed previously (that is, mx = T_MX).
-c query-class
Specify class of query. Can specify either an integer value to be included in the class field, or use the abbreviated mnemonic as discussed previously (that is, in = C_IN).
This flag specifies that the dig(1) environment (defaults, print options, and so on), after all of the arguments are parsed, should be saved to a file to become the default environment. Useful if you do not like the standard set of defaults and do not want to include a large number of options each time dig(1) is used. The environment consists of resolver state variable flags, time-out, and retries, as well as the flags detailing dig(1) output (described later). If the shell environment variable LOCALDEF is set to the name of a file, this is where the default dig(1) environment is saved. If not, the file DiG.env is created in the current working directory.

LOCALDEF is specific to the dig(1) resolver and will not affect operation of the standard resolver library.

Each time dig(1) is executed, it looks for ./DiG.env or the file specified by the shell environment variable LOCALDEF. If such a file exists and is readable, the environment is restored from this file before any arguments are parsed.

This flag only affects batch-query runs. When -envset is specified on a line in a dig(1) batch file, the dig(1) environment after the arguments are parsed becomes the default environment for the duration of the batch file, or until the next line which specifies -envset.
-stick | -nostick
This flag only affects batch query runs. It specifies that the dig(1) environment (as read initially or set by -envset switch) is to be restored before each query (line) in a dig(1) batch file. The default -nostick means that the dig(1) environment does not stick, hence options specified on a single line in a dig(1) batch file will remain in effect for subsequent lines (that is, they are not restored to the sticky default).
The plus sign (+) is used to specify an option to be changed in the query packet, or to change dig(1) output specifics. Many of these are the same parameters accepted by nslookup(1). If an option requires a parameter, the form is as follows:

Most keywords can be abbreviated. Parsing of the + options is very simplistic a value must not be separated from its keyword by white space. The following keywords are currently available:

Keyword Abbreviation Meaning [default]
[no]debug (deb) Turn on/off debugging mode [deb]
[no]defname (def) Use/do not use default domain name [def]
[no]aaonly (aa) Authoritative query only flag [noaa]
[no]ttlid (tt) Print TTLs [tt]
[no]author (au) Print authoritative section [au]

The retry(1) and time(1) options affect the retransmission strategy used by the resolver library when sending datagram queries. The algorithm is as follows:

for i = 0 to retry - 1
 g  for j = 1 to num_servers
	 wait((time * (2**i)) / num_servers)
 g  end

Note that dig(1) always uses a value of 1 for num_servers.)


The dig(1) utility once required a slightly modified version of the BIND resolver(1) library. As of BIND 4.9, BIND's resolver has been augmented to work properly with dig.(1) Essentially, dig(1) is a straight-forward (albeit not pretty) effort to parse arguments and set appropriate parameters. The dig(1) utility uses resolver(1) routines as well as accessing the _res structure.


File to use in place of Pa /etc/resolv.conf
Default environment file

See also the explanation of the -envsav, -envset, and -[no]stick options, above.


Initial domain name and name server addresses
Default save file for default options


RFC 1035


Steve Hotz hotz@isi.edu


The dig(1) utility uses functions from nslookup(1) authored by Andrew Cherenson.


The dig(1) utility has a serious case of "creeping featurism" -- the result of considering several potential uses during it's development. It would probably benefit from a rigorous review. Similarly, the print flags and granularity of the items they specify make evident their rather ad hoc genesis.

The dig(1) utility does not consistently exit nicely (with appropriate status) when a problem occurs somewhere in the resolver (Most of the common exit cases are handled.) This is particularly annoying when running in batch mode. If it exits abnormally (and this is not detected), the entire batch aborts; when such an event is trapped, dig(1) simply continues with the next query.