## Query a DNS server ##

[Author](authors.html): Cezary Morga cm@therek.net FreeBSD

[Reviewer](technical_reviewers.html): Mark Foster mark@foster.cc FreeBSD

[Reviewer](technical_reviewers.html): Sean Swayze swayze@pcsage.biz FreeBSD/OpenBSD

----



### Concept ###

Understand basic DNS theory, including types
of resource records, types of DNS servers, reverse lookups and zone
transfers. Be able to query a DNS server for
a particular type of resource record, understand which servers are
authoritative for a zone and determine if a DNS server is willing
to do a zone transfer.


### Introduction ###

The Domain Name System (DNS) stores information mainly for mapping
Internet host names to IP addresses and vice versa, as well as mail
routing information.  It can also store many other types of information
not covered here, utilized by different Internet applications.

The DNS system stores data in a tree-like hierachy starting from a root
node, through subnodes to host node.  Every node of the tree is called
a _domain_ and is given a label.  Every domain except the root is also
a _subdomain_.  The _domain name_ of the node is the concatenation
of all the labels on the path from the node to the root node separated
by dots.  It is written starting from the host node on left, with the
root node located on right, ie. `mail.example.com` where `mail` is a host
node and `example` is a subdomain of a top level domain `com`.

Everytime we're buying a domain, we're actualy buying a subdomain of one
of the global domains like:

* generic top level domains **gTLD** (ie. com, org, net) or
* country code top level domains **ccTLD** (ie. uk, de, pl, fr).

It may even be some second level domain like co.uk, org.pl, net.de.

For administrative purposes, the name space in the DNS system is partitioned
into areas called _zones_, each starting at a node and extending down
to the leaf nodes or to nodes where other zones start.  The data for each
zone is stored in a _name server_, which answers queries about the given
zone.

A zone consists of those parts of the domain tree for which a name
server has complete information and over which it has authority.
It contains all domain names from a certain point downward in the domain
tree except those which are delegated to other zones.  A delegation point
is marked by one or more `NS` records in the parent zone, which should
be matched by equivalent `NS` records at the root of the delegated zone.

#### Resource Records ####

The data associated with each domain name is stored in the form of resource
records (RR). The most commonly met types of RRs in IPv4 networks are:

* **A** - a host IP address located in the `IN` class.
* **CNAME** - a canonical name identifier for creating aliases.
* **MX** - a mail exchange identifier for given domain.
* **NS** - the authoritative name server for the domain.
* **PTR** - a pointer to another part of the domain name space.
* **SOA** - identifies the start of a zone of authority.

#### Authoritative Name Servers ####

Each zone is served by at least one authoritative name server, which
contains the complete data for the zone.  Most zones have at least
two authoritative servers to make the DNS system immune to server
and network failures.

Responses from the authoritative servers have the "authoritative
answer" (AA) bit set in the response packets.

The authoritative server where the master copy of the zone data
is maintained is called the _primary master server_.  It holds
zones configured manually by an administrator. The other
authoritative servers known as the _slave servers_ or _secondary
servers_ load the zone contents from another server using
a replication process known as a _zone transfer_.

#### Caching Name Servers ####

To improve performance, _recursive servers_ cache the results of the
lookups they perform on behalf of DNS clients.  This may be a query
of a web browser as well as of a **host(1)** command.  The terms
_recursive server_ and _caching server_ are often used synonymously,
and for needs of this document they'll be treated as synonymous.

### Examples ###

(**Note:** Basic information on reverse DNS queries is covered
in section [[Determine_who_is_responsible_for_a_DNS_zone]])

In BSD systems there are three basic DNS query tools: **host(1)**,
**dig(1)** and **nslookup(1)**.

#### host(1) ####

Performing general DNS lookup with **host(1)** is pretty
straighforward:

""$ **host google.com**
""google.com has address 64.233.167.99
""google.com has address 64.233.187.99
""google.com has address 72.14.207.99
""google.com mail is handled by 10 smtp1.google.com.
""google.com mail is handled by 10 smtp2.google.com.
""google.com mail is handled by 10 smtp3.google.com.
""google.com mail is handled by 10 smtp4.google.com.

Sometimes it is required to check what information on given domain
can be retrieved from some other name server. This can be done
by specifying queried DNS server's name or IP address after the
domain name we're gathering information on.

""$ **host google.com 192.168.86.1**
""Using domain server:
""Name: 192.168.86.1
""Address: 192.168.86.1#53
""Aliases:

""google.com has address 72.14.207.99
""google.com has address 64.233.167.99
""google.com has address 64.233.187.99
""google.com mail is handled by 10 smtp2.google.com.
""google.com mail is handled by 10 smtp3.google.com.
""google.com mail is handled by 10 smtp4.google.com.
""google.com mail is handled by 10 smtp1.google.com.

Of course, information on IP addresses and mail exchange servers
is not always what we're looking for. Thus, querying for given
resource record is also available -- with the **-t** flag.

""$ **host -t SOA google.com**
""google.com has SOA record ns1.google.com. dns-admin.google.com. 2007010801 7200 1800 1209600 300

Finally, we'd like to get as much information as possible.

""$ **host -a google.com ns2.google.com**
""Trying "google.com"
""Using domain server:
""Name: ns2.google.com
""Address: 216.239.34.10#53
""Aliases:

"";; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44983
"";; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 4, ADDITIONAL: 8

"";; QUESTION SECTION:
"";google.com.                    IN      ANY

"";; ANSWER SECTION:
""google.com.             300     IN      A       72.14.207.99
""google.com.             300     IN      A       64.233.187.99
""google.com.             300     IN      A       64.233.167.99
""google.com.             300     IN      TXT     "v=spf1 ptr ?all"
""google.com.             10800   IN      MX      10 smtp1.google.com.
""google.com.             10800   IN      MX      10 smtp2.google.com.
""google.com.             10800   IN      MX      10 smtp3.google.com.
""google.com.             10800   IN      MX      10 smtp4.google.com.
""google.com.             345600  IN      NS      ns1.google.com.
""google.com.             345600  IN      NS      ns2.google.com.
""google.com.             345600  IN      NS      ns3.google.com.
""google.com.             345600  IN      NS      ns4.google.com.
""google.com.             86400   IN      SOA     ns1.google.com. dns-admin.google.com. 2007010801 7200 1800 ""1209600 300

"";; AUTHORITY SECTION:
""google.com.             345600  IN      NS      ns1.google.com.
""google.com.             345600  IN      NS      ns2.google.com.
""google.com.             345600  IN      NS      ns3.google.com.
""google.com.             345600  IN      NS      ns4.google.com.

"";; ADDITIONAL SECTION:
""smtp1.google.com.       3600    IN      A       216.239.57.25
""smtp2.google.com.       3600    IN      A       64.233.167.25
""smtp3.google.com.       3600    IN      A       64.233.183.25
""smtp4.google.com.       3600    IN      A       72.14.215.25
""ns1.google.com.         345600  IN      A       216.239.32.10
""ns2.google.com.         345600  IN      A       216.239.34.10
""ns3.google.com.         345600  IN      A       216.239.36.10
""ns4.google.com.         345600  IN      A       216.239.38.10

""Received 494 bytes from 216.239.34.10#53 in 100 ms

Please notice the presence of AA bit in response packet:

"";; flags: qr **aa** rd; QUERY: 1, ANSWER: 13, AUTHORITY: 4, ADDITIONAL: 8

The **host(1)** utility -- as simple as it may seem -- allows
also preforming a zone transfer using AXFR query.

""$ **host -t AXFR google.com ns2.google.com**
""Trying "google.com"
""Using domain server:
""Name: ns2.google.com
""Address: 216.239.34.10#53
""Aliases:

""Host google.com not found: 5(REFUSED)
""; Transfer failed.

As we can see, queried name server refused a zone transfer which marks
potentially well configured DNS server.

#### dig(1) ####

The **domain information groper** utility is a very flexible, and probably most
popular tool for performing DNS queries. It supports many different query options
that can be passed as an execution flags, altough this book describes only
basic functions.

Most basic DNS query performed using **dig(1)** returns quite a lot information
on given domain. A queried DNS name or an IP address may be given as an
additional parameter.
 
""$ **dig @ns4.google.com google.com**
""
""; <<>> DiG 9.3.3 <<>> google.com @ns4.google.com
""; (1 server found)
"";; global options:  printcmd
"";; Got answer:
"";; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40993
"";; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4
""
"";; QUESTION SECTION:
"";google.com.                    IN      A
""
"";; ANSWER SECTION:
""google.com.             300     IN      A       64.233.187.99
""google.com.             300     IN      A       64.233.167.99
""google.com.             300     IN      A       72.14.207.99
""
"";; AUTHORITY SECTION:
""google.com.             345600  IN      NS      ns1.google.com.
""google.com.             345600  IN      NS      ns2.google.com.
""google.com.             345600  IN      NS      ns3.google.com.
""google.com.             345600  IN      NS      ns4.google.com.
""
"";; ADDITIONAL SECTION:
""ns1.google.com.         345600  IN      A       216.239.32.10
""ns2.google.com.         345600  IN      A       216.239.34.10
""ns3.google.com.         345600  IN      A       216.239.36.10
""ns4.google.com.         345600  IN      A       216.239.38.10
""
"";; Query time: 359 msec
"";; SERVER: 216.239.38.10#53(216.239.38.10)
"";; WHEN: Sun Feb 11 00:32:13 2007
"";; MSG SIZE  rcvd: 212

Once again, please notice the presence of AA bit in response.

When performing a DNS lookup for given resource record, the queried resource
may be added with or without **-t** flag. The default query type is "A", unless the
**-x** option is supplied to indicate a reverse lookup, which is explained in another
section.

""$ **dig @ns2.google.com google.com -t MX**
""
""; <<>> DiG 9.3.3 <<>> google.com -t MX @ns2.google.com
""; (1 server found)
"";; global options:  printcmd
"";; Got answer:
"";; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57975
"";; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 8
""
"";; QUESTION SECTION:
"";google.com.                    IN      MX
""
"";; ANSWER SECTION:
""google.com.             10800   IN      MX      10 smtp2.google.com.
""google.com.             10800   IN      MX      10 smtp3.google.com.
""google.com.             10800   IN      MX      10 smtp4.google.com.
""google.com.             10800   IN      MX      10 smtp1.google.com.
""
"";; AUTHORITY SECTION:
""google.com.             345600  IN      NS      ns1.google.com.
""google.com.             345600  IN      NS      ns2.google.com.
""google.com.             345600  IN      NS      ns3.google.com.
""google.com.             345600  IN      NS      ns4.google.com.
""
"";; ADDITIONAL SECTION:
""smtp2.google.com.       3600    IN      A       64.233.167.25
""smtp3.google.com.       3600    IN      A       64.233.183.25
""smtp4.google.com.       3600    IN      A       72.14.215.25
""smtp1.google.com.       3600    IN      A       216.239.57.25
""ns1.google.com.         345600  IN      A       216.239.32.10
""ns2.google.com.         345600  IN      A       216.239.34.10
""ns3.google.com.         345600  IN      A       216.239.36.10
""ns4.google.com.         345600  IN      A       216.239.38.10
""
"";; Query time: 185 msec
"";; SERVER: 216.239.34.10#53(216.239.34.10)
"";; WHEN: Sun Feb 11 00:39:46 2007
"";; MSG SIZE  rcvd: 316

Similar as with **host(1)** the AXFR resource record query may
be used to try to perform a domain transfer.

""$ **dig google.com AXFR**
""
""; <<>> DiG 9.3.3 <<>> AXFR google.com
"";; global options:  printcmd
""; Transfer failed.</code>

Once again, the server is secured against unauthorized zone transfers.

#### nslookup(1) ####

The **nslookup(1)** utility has two work modes: interactive and non-interactive.
Interactive mode is entered when no command line arguments are given
or when the first argument is a hyphen "-" and the second argument is the
DNS server's name.

Non-interactive mode require passing as a parameters: domain name
(first argument) and queried name server (second argument).

""$ **nslookup google.com ns3.google.com**
""Server:        ns3.google.com
""Address:        216.239.36.10#53
""
""Name:  google.com
""Address: 64.233.167.99
""Name:  google.com
""Address: 72.14.207.99
""Name:  google.com
""Address: 64.233.187.99</code>

### Practice Exercises ###

1. Check the result of **host(1)** command along with flags: **-d**, **-v**, **-C**, and **-l**.
2. See the result of **dig(1)** query for resource record **any**.
3. See the impact on query results of reordering **dig(1)** flags and parameters.
4. Read the **nslookup(1)** manual page and try an interactive mode query.

### More information ###

dig(1), host(1), nslookup(1)


