Softpanorama May the source be with you, but remember the KISS principle ;-)	Home	Switchboard	Unix Administration	Red Hat	TCP/IP Networks	Neoliberalism	Toxic Managers
	(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix

dig - DNS lookup utility

News

DiG HOWTO: How to use dig to query DNS name servers by Paul Heinlein

August 31, 2004 Most recent revision: May 11, 2006
dig is a command-line tool for querying DNS name servers for information about host addresses, mail exchanges, name servers, and related information. The dig(1) man page is somewhat lacking when it comes to examples, a shortcoming this article tries to remedy.

The source code for dig is part of the larger ISC BIND distribution. Compiling and installing BIND are topics outside the scope of this document, but on Linux systems dig is usually part of a common package: bind-tools (Gentoo), bind-utils (Red Hat, Fedora), or dnsutils (Debian).

If you’re looking for information on configuring the BIND name server, you might find my article BIND for the Small LAN more to your taste.

Understanding the default output

The most typical, simplest query is for a single host. By default, however, dig is pretty verbose. You probably don’t need all the information in the default output, but it’s probably worth knowing what it is. Below is an annotated query.
dig www.isc.org
That’s the command-line invocation of dig I used.
; <<>> DiG 9.2.3 <<>> www.isc.org
;; global options:  printcmd
The opening section of dig’s output tells us a little about itself (version 9.2.3) and the global options that are set (in this case, printcmd). This part of the output can be quelled by using the +nocmd option, but only if it’s the very first argument on the command line (even preceeding the host you’re querying).
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43071
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
Here, dig tells us some technical details about the answer received from the DNS server. This section of the output can be toggled using the +[no]comments option—but beware that disabling the comments also turns off many section headers.
;; QUESTION SECTION:
;www.isc.org.                   IN      A
In the question section, dig reminds us of our query. The default query is for an Internet address (A). You can turn this output on or off using the +[no]question option.
;; ANSWER SECTION:
www.isc.org.            600     IN      A       204.152.184.88
Finally, we get our answer: the address of www.isc.org is 204.152.184.88. I don’t know why you’d ever want to turn off the answer, but you can toggle this section of the output using the +[no]answer option.
;; AUTHORITY SECTION:
isc.org.                2351    IN      NS      ns-int.isc.org.
isc.org.                2351    IN      NS      ns1.gnac.com.
isc.org.                2351    IN      NS      ns-ext.isc.org.
The authority section tells us what DNS servers can provide an authoritative answer to our query. In this example, isc.org has three name servers. You can toggle this section of the output using the +[no]authority option.
;; ADDITIONAL SECTION:
ns1.gnac.com.           171551  IN      A       209.182.216.75
ns-int.isc.org.         2351    IN      A       204.152.184.65
ns-int.isc.org.         2351    IN      AAAA    2001:4f8:0:2::15
The additional section typically includes the IP addresses of the DNS servers listed in the authority section. This section of the output can be toggled with the +[no]additional option.
;; Query time: 2046 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug 27 08:22:26 2004
;; MSG SIZE  rcvd: 173
The final section of the default output contains statistics about the query; it can be toggled with the +[no]stats option.

What can I discover?

dig will let you perform any valid DNS query, the most common of which are A (the IP address), TXT (text annotations), MX (mail exchanges), NS name servers, or the omnibus ANY.
# get the address(es) for yahoo.com
dig yahoo.com A +noall +answer

# get a list of yahoo's mail servers
dig yahoo.com MX +noall +answer

# get a list of DNS servers authoritative for yahoo.com
dig yahoo.com NS +noall +answer

# get all of the above
dig yahoo.com ANY +noall +answer
More obscurely, for the present anyway, you can also poll for a host’s IPv6 address using the AAAA option.
dig www.isc.org AAAA +short
If the domain you want to query allows DNS transfers, you can get those, too. The reality of life on the Internet, however, is that very few domains allow unrestricted transfers these days.
dig yourdomain.com AXFR
How do I …

When all you want is a quick answer, the +short option is your friend:
$ dig www.isc.org +short
204.152.184.88
Note that a short answer is different from only an answer. The way to get a detailed answer, but without any auxiliary information, is to turn off all the results (+noall) and then turn on only those sections you want.

Here’s a short answer followed by only an answer; the latter includes all the configuration information, including time-to-live (TTL) data, displayed in a format compatible with BIND configuration files.
$ dig fsf.org mx +short
20 mx20.gnu.org.
30 mx30.gnu.org.
10 mx10.gnu.org.

$ dig +nocmd fsf.org mx +noall +answer
fsf.org.                3583    IN      MX      30 mx30.gnu.org.
fsf.org.                3583    IN      MX      10 mx10.gnu.org.
fsf.org.                3583    IN      MX      20 mx20.gnu.org.
According to its man page, the +multiline option will give you an answer with “the SOA records in a verbose multi-line format with human-readable comments.” In general, the answers retrieved using the +multiline option will appear more like BIND config files than they will without it.
$ dig +nocmd ogi.edu any +multiline +noall +answer
ogi.edu.   14267 IN A 129.95.59.31
ogi.edu.   14267 IN MX 5 cse.ogi.edu.
ogi.edu.   14267 IN MX 15 hermes.admin.ogi.edu.
ogi.edu.   14267 IN SOA zeal.admin.ogi.edu. hostmaster.admin.ogi.edu. (
                   200408230  ; serial
                   14400      ; refresh (4 hours)
                   900        ; retry (15 minutes)
                   3600000    ; expire (5 weeks 6 days 16 hours)
                   14400      ; minimum (4 hours)
                   )
ogi.edu.   14267 IN NS zeal.admin.ogi.edu.
ogi.edu.   14267 IN NS cse.ogi.edu.
ogi.edu.   14267 IN NS fork.admin.ogi.edu.
Use the -x option to lookup the main hostname associated with an IP address.
dig -x 204.152.184.167 +short mx-1.isc.org.
In a loop, this is a slick way to map the names in a given subnet:
#!/bin/bash
NET=18.7.22
for n in $(seq 1 254); do
  ADDR=${NET}.${n}
  echo -e "${ADDR}\t$(dig -x ${ADDR} +short)"
done
Just specify it on the command line:
dig @ns1.google.com www.google.com
The host utility will automatically use the search list in your /etc/resolv.conf file.
$ host www
www.madboa.com has address 65.102.49.170
By default, however, dig doesn’t—which may produce some unexpected results. If you want to use local hostnames instead of fully qualified domain names, use the +search option.
dig www +search
If you want to look up a large number of hostnames, you can put them in a file (one name per line) and use the -f option to query each one in turn.
# do full lookups for a number of hostnames
dig -f /path/to/host-list.txt

# the same, with more focused output
dig -f /path/to/host-list.txt +noall +answer
As far as I can tell, dig versions up to and including 9.2.3 are unable to do reverse lookups using the -f option.

Verifying DNS mappings

An improperly configured DNS setup can be really annoying. You want to make sure that your mappings work both ways:

Each hostname should resolve to an address, and that address ought to resolve back to the proper hostname.

If an address on your subnet(s) has been assigned a reverse pointer to a hostname, that hostname ought to point back to the original address.

There are exceptions to those two rules, of course. A CNAME will resolve to another hostname first, and only then to an address. Sometimes multiple hostnames will point to the same address, but that address will have only one reverse pointer.

Still, it’s good to know that your basic mappings work as expected.

You can script such a test if you build a file containing your known hostnames. The example script below is pretty simple; it will break if fed a CNAME, and it’ll report a failure somewhere if multiple hostnames point to the same address. Let’s assume the file containing your hostnames is named named-hosts.
#!/bin/bash
#
# test DNS forward- and reverse-mapping
#

# edit this variable to reflect local class C subnet(s)
NETS="192.168.1 192.168.2"

# Test name to address to name validity
echo
echo -e "\tname -> address -> name"
echo '----------------------------------'
while read H; do
  ADDR=$(dig $H +short)
  if test -n "$ADDR"; then
    HOST=$(dig -x $ADDR +short)
    if test "$H" = "$HOST"; then
      echo -e "ok\t$H -> $ADDR -> $HOST"
    elif test -n "$HOST"; then
      echo -e "fail\t$H -> $ADDR -> $HOST"
    else
      echo -e "fail\t$H -> $ADDR -> [unassigned]"
    fi
  else
    echo -e "fail\t$H -> [unassigned]"
  fi
done < named-hosts

# Test address to name to address validity
echo
echo -e "\taddress -> name -> address"
echo '-------------------------------------'
for NET in $NETS; do
  for n in $(seq 1 254); do
    A=${NET}.${n}
    HOST=$(dig -x $A +short)
    if test -n "$HOST"; then
      ADDR=$(dig $HOST +short)
      if test "$A" = "$ADDR"; then
        echo -e "ok\t$A -> $HOST -> $ADDR"
      elif test -n "$ADDR"; then
        echo -e "fail\t$A -> $HOST -> $ADDR"
      else
        echo -e "fail\t$A -> $HOST -> [unassigned]"
      fi
    fi
  done
done
dig fun
Roll your own named.root file
Any DNS server connected to the Internet is likely to have a copy of the InterNIC’s named.root file that lists the root name servers for the entire Internet. You can always download that file in the boring way from the InterNIC’s ftp server. Or, in a true build-it-yourself fashion, you can build it with dig.
# compare with ftp://ftp.internic.net/domain/named.root
dig +nocmd . NS +noall +answer +additional
Your TTL values might be a little on the short side, but otherwise, it’s as up-to-date a list as you’ll find!

Tracing dig’s path. Perhaps you’re a devotee of traceroute and like to watch how to get from point A to point B. You can do a similar thing with dig’s +trace option.
dig gentoo.de +trace
You’ll see dig head to the root name servers, then to the servers responsible for all the *.de domains, and finally to the name servers responsible for gentoo.de.
Grabbing SOA information. As a DNS administrator, I sometimes make changes and want to see if any of my name servers are still pushing the old data. The +nssearch provides a clear accounting of your public servers.
# the unvarnished truth
dig cse.ogi.edu +nssearch

# the same, displaying only serial number and hostname
dig cse.ogi.edu +nssearch | cut -d' ' -f4,11
Interpreting TTL numbers

I love Google for many reasons, one of which is that it provides referrer strings in my web logs that make it easy to figure out what sort of queries lead people to pages on this site.

Somewhat unexpectedly, I’ve seen a lot of queries asking for information about TTL (time-to-live) numbers. I would have never guessed that TTL would be a topic of interest, but you learn something new every day. So, by popular demand, here’s a brief intro to TTL.

If you ask your local DNS server for an Internet address, the server figures out where to find an authoritative answer and then asks for it. Once the server receives an answer, it will keep the answer in a local cache so that if you ask for the same address again a short time later, it can give you the answer quickly rather than searching the Internet for it all over again.

When domain administrators configure their DNS records, they decide how long the records should remain in remote caches. This is the TTL number (usually expressed in number of seconds).

Typically, a remote server will only cache those records for the length of time specified by the TTL. After that, the remote server will flush its local cache and ask again for an authoritative answer.

When you use dig to query a DNS server concerning a certain record, the server will tell dig the time (in seconds) that record will remain in cache.

For example, as of this writing, the TTL for the MX records for the gmail.com domain is 300 seconds. The gmail.com admins are asking that remote servers cache their MX records for no more than five minutes. So when you first ask for that record set, dig will report a TTL of 300.
$ dig +nocmd gmail.com MX +noall +answer
gmail.com.        300     IN      MX      20 gsmtp57.google.com.
gmail.com.        300     IN      MX      10 gsmtp171.google.com.
If you ask a few seconds later, you’ll see the TTL number reduced by approximately the number of seconds you waited to ask again.
$ dig +nocmd gmail.com MX +noall +answer
gmail.com.        280     IN      MX      10 gsmtp171.google.com.
gmail.com.        280     IN      MX      20 gsmtp57.google.com.
If your timing is good, you can catch the record at the very end of its life.
$ dig +nocmd gmail.com MX +noall +answer
gmail.com.        1       IN      MX      10 gsmtp171.google.com.
gmail.com.        1       IN      MX      20 gsmtp57.google.com.
After that, the DNS server you’re querying will “forget” the answer to that question, so the whole cycle will start over again (in this example, at 300 seconds) the next time you perform that query.

NEWS CONTENTS

200102 : How to check your DNS records with dig by Gary Sims ( How to check your DNS records with dig, )

Old News

How to check your DNS records with dig By Gary Sims

To query DNS and see the records which it holds, you can use a tool called dig. Dig queries DNS servers directly and it comes as standard with all the major Linux distributions. Dig is a very useful tool for webmasters and site administrators to verify and troubleshoot DNS problems.

To check the record for your domain run dig with your domain name as the parameter. For example:
	dig www.hungrypenguin.net
This will cause dig to lookup the A record for the domain name www.hungrypenguin.net. To do this dig will look in your /etc/resolv.conf file and query the DNS servers listed there. The response from the DNS server is what is displayed:
; <<>> DiG 9.2.4 <<>> www.hungrypenguin.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28017
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.hungrypenguin.net.         IN      A

;; ANSWER SECTION:
www.hungrypenguin.net.  75583   IN      A       67.15.117.250

;; AUTHORITY SECTION:
hungrypenguin.net.      75583   IN      NS      ns2.hosteurope.com.
hungrypenguin.net.      75583   IN      NS      ns.hosteurope.com.

;; ADDITIONAL SECTION:
ns.hosteurope.com.      158892  IN      A       212.67.202.2
ns2.hosteurope.com.     158892  IN      A       212.67.203.246

;; Query time: 2474 msec
;; SERVER: 193.231.237.2#53(193.231.237.2)
;; WHEN: Tue Apr  5 16:10:48 2005
;; MSG SIZE  rcvd: 136
The first thing to note is that lines beginning with ; are comments which do not make up part of the actual answer received from the DNS server, however they do reflect some of the low level protocol used in making the query.

The first two lines tell us the version of dig (9.2.4), the command line parameters (www.hungrypenguin.net ) and the query options (printcmd). The printcmd options means that the command section (the name given to these first two line) is printed. You can turn it off by using the option +nocmd.

Next dig shows the header of the response it received from the DNS server. Here it reports that an answer was obtained from the query response (opcode: QUERY) and that the response contains 1 answer, 2 pieces of information in the authority section and a further 2 in the additional section. The flags are used to note certain things about the DNS server and its response. For example, the RA flag shows that recursive queries are available.

Next comes the question section, this simply tells us the query, which in this case is a query for the A record of www.hungrypenguin.net. The IN means this is an Internet lookup (in the Internet class).

Now for the answer. The answer section tells us that www.hungrypenguin.net has the IP address 67.15.117.250.

Along with the IP address the DNS record contains some more useful information. In the authority section there is a list of name servers which are responsible for the domain name, those which can always give an authoritative answer. Here we find two name servers listed. These are in fact the name servers of the company with which the domain was registered. To save an extra lookup the IP addresses of those name servers are listed in the additional section.

Lastly there are some stats about the query. These stats can be turned off using the +nostats option.

By default dig is quite verbose. One way to cut down the output is to use the +short option:
	dig www.hungrypenguin.net +short
Which will drastically cut the output to just:
	67.15.117.250
However for diagnosing DNS problems fuller output is needed. A happy medium can be found by putting the following lines into .digrc in your home directory:
+nocmd
+nostats
+noquestion
Querying different types of DNS records

By default dig looks for the A record of the domain specified. However, as mentioned earlier, there are many types of domain records. Along with the A record another important one is the MX record. The Mail eXchange record tells mail servers how to route the email. You can examine your MX records using dig like this:
	dig hungrypenguin.net MX
The first thing to note is that the dig is for hungrypenguin.net and not www.hungrypenguin.net. This is because normally when you send email to someone, you send it to the domain and not to one of the subdomains like www or ftp. The webmasters email address at hungrypenguin is [email protected] not [email protected].

The salient part of the response is:
;; ANSWER SECTION:
hungrypenguin.net.      86400   IN      MX      10 mx0.123-reg.co.uk.
hungrypenguin.net.      86400   IN      MX      20 mx1.123-reg.co.uk.
This tells us that there is a mail server called mx0.123-reg.co.uk which will handle the email for the hungrypenguin.net domain. There is also a backup server (mx1) which handle the mail if mx0 is unavailable for any reason. The 10 and the 20 are the preference values for the domain. The lower values are preferred over the higher ones.

Querying other DNS servers

As mentioned earlier by default dig will query the DNS servers listed in your /etc/resolv.conf. These are normally the DNS servers of your ISP. However it can also be very useful to query other DNS servers, particularly the authoritative DNS server.

If you need to modify your DNS records, for example when migrating your website from one hosting provider to another, it is essential to ensure that your DNS records are updated correctly. The problem with DNS updates is that they can take up to 48 hours to propagate through the Internet. For a successful migration it is important to know that your DNS records are correct now rather than waiting 48 hours to discover that they contain an error!

Earlier we saw that ns.hosteurope.com is the authoritative (responsible) name server for the hungrypenguin.net domain. That information came from my ISP's DNS server. To use a different name server call dig with the first parameter as @nameserver. For example we can query ns.hosteurope.com directly like this:
	
dig @ns.hosteurope.com www.hungrypenguin.net 
This will return a response directly from the name server which has responsibility for the hungrypenguin domain. One way to verify the authority of theanswer is to look for the aa flag in the header.

Reference

dig [@server] [-b address] [-c class] [-f filename] [-k filename] [-p port#] [-t type] [-x addr] [-y name:key] [-4] [-6] [name] [type] [class] [queryopt...]

dig [-h]
dig [global-queryopt...] [query...]

dig (domain information groper) is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried. Most DNS administrators use dig to troubleshoot DNS problems because of its flexibility, ease of use and clarity of output. Other lookup tools tend to have less functionality than dig.

Although dig is normally used with command-line arguments, it also has a batch mode of operation for reading lookup requests from a file. A brief summary of its command-line arguments and options is printed when the -h option is given. Unlike earlier versions, the BIND9 implementation of dig allows multiple lookups to be issued from the command line.

Unless it is told to query a specific name server, dig will try each of the servers listed in /etc/resolv.conf.

When no command line arguments or options are given, will perform an NS query for "." (the root).

It is possible to set per-user defaults for dig via ${HOME}/.digrc. This file is read and any options in it are applied before the command line arguments.

Simple Usage

A typical invocation of dig looks like:

where:
server: is the name or IP address of the name server to query. This can be an IPv4 address in dotted-decimal notation or an IPv6 address in colon-delimited notation. When the supplied server argument is a hostname, dig resolves that name before querying that name server. If no server argument is provided, dig consults /etc/resolv.conf and queries the name servers listed there. The reply from the name server that responds is displayed.
name: is the name of the resource record that is to be looked up.
type: indicates what type of query is required - ANY, A, MX, SIG, etc. type can be any valid query type. If no type argument is supplied, dig will perform a lookup for an A record.

Options

The -b option sets the source IP address of the query to address. This must be a valid address on one of the host's network interfaces or "0.0.0.0" or "::". An optional port may be specified by appending "#<port>"

The default query class (IN for internet) is overridden by the -c option. class is any valid class, such as HS for Hesiod records or CH for CHAOSNET records.

The -f option makes dig operate in batch mode by reading a list of lookup requests to process from the file filename. The file contains a number of queries, one per line. Each entry in the file should be organised in the same way they would be presented as queries to dig using the command-line interface.

If a non-standard port number is to be queried, the -p option is used. port# is the port number that dig will send its queries instead of the standard DNS port number 53. This option would be used to test a name server that has been configured to listen for queries on a non-standard port number.

The -4 option forces dig to only use IPv4 query transport. The -6 option forces dig to only use IPv6 query transport.

The -t option sets the query type to type. It can be any valid query type which is supported in BIND9. The default query type "A", unless the -x option is supplied to indicate a reverse lookup. A zone transfer can be requested by specifying a type of AXFR. When an incremental zone transfer (IXFR) is required, type is set to ixfr=N. The incremental zone transfer will contain the changes made to the zone since the serial number in the zone's SOA record was N.

Reverse lookups - mapping addresses to names - are simplified by the -x option. addr is an IPv4 address in dotted-decimal notation, or a colon-delimited IPv6 address. When this option is used, there is no need to provide the name, class and type arguments. dig automatically performs a lookup for a name like 11.12.13.10.in-addr.arpa and sets the query type and class to PTR and IN respectively. By default, IPv6 addresses are looked up using nibble format under the IP6.ARPA domain. To use the older RFC1886 method using the IP6.INT domain specify the -i option. Bit string labels (RFC2874) are now experimental and are not attempted.

To sign the DNS queries sent by dig and their responses using transaction signatures (TSIG), specify a TSIG key file using the -k option. You can also specify the TSIG key itself on the command line using the -y option; name is the name of the TSIG key and key is the actual key. The key is a base-64 encoded string, typically generated by dnssec-keygen(8). Caution should be taken when using the -y option on multi-user systems as the key can be visible in the output from ps(1 ) or in the shell's history file. When using TSIG authentication with dig, the name server that is queried needs to know the key and algorithm that is being used. In BIND, this is done by providing appropriate key and server statements in named.conf.

Query Options

dig provides a number of query options which affect the way in which lookups are made and the results displayed. Some of these set or reset flag bits in the query header, some determine which sections of the answer get printed, and others determine the timeout and retry strategies.

Each query option is identified by a keyword preceded by a plus sign (+). Some keywords set or reset an option. These may be preceded by the string no to negate the meaning of that keyword. Other keywords assign values to options like the timeout interval. They have the form +keyword=value. The query options are:

+[no]tcp

Use [do not use] TCP when querying name servers. The default behaviour is to use UDP unless an AXFR or IXFR query is requested, in which case a TCP connection is used.

+[no]vc

Use [do not use] TCP when querying name servers. This alternate syntax to +[no]tcp is provided for backwards compatibility. The "vc" stands for "virtual circuit".

+[no]ignore

Ignore truncation in UDP responses instead of retrying with TCP. By default, TCP retries are performed.

+domain=somename

Set the search list to contain the single domain somename, as if specified in a domain directive in /etc/resolv.conf, and enable search list processing as if the +search option were given.

+[no]search

Use [do not use] the search list defined by the searchlist or domain directive in resolv.conf (if any). The search list is not used by default.

+[no]defname

Deprecated, treated as a synonym for +[no]search

+[no]aaonly

Sets the "aa" flag in the query.

+[no]aaflag

A synonym for +[no]aaonly.

+[no]adflag

Set [do not set] the AD (authentic data) bit in the query. The AD bit currently has a standard meaning only in responses, not in queries, but the ability to set the bit in the query is provided for completeness.

+[no]cdflag

Set [do not set] the CD (checking disabled) bit in the query. This requests the server to not perform DNSSEC validation of responses.

+[no]cl

Display [do not display] the CLASS when printing the record.

+[no]ttlid

Display [do not display] the TTL when printing the record.

+[no]recurse

Toggle the setting of the RD (recursion desired) bit in the query. This bit is set by default, which means dig normally sends recursive queries. Recursion is automatically disabled when the +nssearch or +trace query options are used.

+[no]nssearch

When this option is set, dig attempts to find the authoritative name servers for the zone containing the name being looked up and display the SOA record that each name server has for the zone.

+[no]trace

Toggle tracing of the delegation path from the root name servers for the name being looked up. Tracing is disabled by default. When tracing is enabled, dig makes iterative queries to resolve the name being looked up. It will follow referrals from the root servers, showing the answer from each server that was used to resolve the lookup.

+[no]cmd

toggles the printing of the initial comment in the output identifying the version of dig and the query options that have been applied. This comment is printed by default.

+[no]short

Provide a terse answer. The default is to print the answer in a verbose form.

+[no]identify

Show [or do not show] the IP address and port number that supplied the answer when the +short option is enabled. If short form answers are requested, the default is not to show the source address and port number of the server that provided the answer.

+[no]comments

Toggle the display of comment lines in the output. The default is to print comments.

+[no]stats

This query option toggles the printing of statistics: when the query was made, the size of the reply and so on. The default behaviour is to print the query statistics.

+[no]qr

Print [do not print] the query as it is sent. By default, the query is not printed.

+[no]question

Print [do not print] the question section of a query when an answer is returned. The default is to print the question section as a comment.

+[no]answer

Display [do not display] the answer section of a reply. The default is to display it.

+[no]authority

Display [do not display] the authority section of a reply. The default is to display it.

+[no]additional

Display [do not display] the additional section of a reply. The default is to display it.

+[no]all

Set or clear all display flags.

+time=T

Sets the timeout for a query to T seconds. The default time out is 5 seconds. An attempt to set T to less than 1 will result in a query timeout of 1 second being applied.

+tries=T

Sets the number of times to try UDP queries to server to T instead of the default, 3. If T is less than or equal to zero, the number of tries is silently rounded up to 1.

+retry=T

Sets the number of times to retry UDP queries to server to T instead of the default, 2. Unlike +tries, this does not include the initial query.

+ndots=D

Set the number of dots that have to appear in name to D for it to be considered absolute. The default value is that defined using the ndots statement in /etc/resolv.conf, or 1 if no ndots statement is present. Names with fewer dots are interpreted as relative names and will be searched for in the domains listed in the search or domain directive in /etc/resolv.conf.

+bufsize=B

Set the UDP message buffer size advertised using EDNS0 to B bytes. The maximum and minimum sizes of this buffer are 65535 and 0 respectively. Values outside this range are rounded up or down appropriately.

+[no]multiline

Print records like the SOA records in a verbose multi-line format with human-readable comments. The default is to print each record on a single line, to facilitate machine parsing of the dig output.

+[no]fail

Do not try the next server if you receive a SERVFAIL. The default is to not try the next server which is the reverse of normal stub resolver behaviour.

+[no]besteffort

Attempt to display the contents of messages which are malformed. The default is to not display malformed answers.

+[no]dnssec

Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO) in the OPT record in the additional section of the query.

+[no]sigchase

Chase DNSSEC signature chains. Requires dig be compiled with -DDIG_SIGCHASE.

+trusted-key=####

Specifies a file containing trusted keys to be used with +sigchase. Each DNSKEY record must be on its own line.
If not specified dig will look for /etc/trusted-key.key then trusted-key.key in the current directory.

Requires dig be compiled with -DDIG_SIGCHASE.

+[no]topdown

When chasing DNSSEC signature chains perform a top down validation. Requires dig be compiled with -DDIG_SIGCHASE.

Multiple Queries

The BIND 9 implementation of dig supports specifying multiple queries on the command line (in addition to supporting the -f batch file option). Each of those queries can be supplied with its own set of flags, options and query options.

In this case, each query argument represent an individual query in the command-line syntax described above. Each consists of any of the standard options and flags, the name to be looked up, an optional query type and class and any query options that should be applied to that query.

A global set of query options, which should be applied to all queries, can also be supplied. These global query options must precede the first tuple of name, class, type, options, flags, and query options supplied on the command line. Any global query options (except the +[no]cmd option) can be overridden by a query-specific set of query options. For example:
dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
shows how dig could be used from the command line to make three lookups: an ANY query for www.isc.org, a reverse lookup of 127.0.0.1 and a query for the NS records of isc.org. A global query option of +qr is applied, so that dig shows the initial query it made for each lookup. The final query has a local query option of +noqr which means that dig will not print the initial query when it looks up the NS records for isc.org.

Files

/etc/resolv.conf

${HOME}/.digrc

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019