This is the BSDA Study Guide Book written via a
wiki collaboration.
This is a work in progress. You may contribute to or discuss this specific page at http://bsdwiki.reedmedia.net/wiki/Query_a_DNS_server.html.
Query a DNS server
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.
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
Practice Exercises
- Check the result of host(1) command along with flags: -d, -v, -C, and -l.
- See the result of dig(1) query for resource record any.
- See the impact on query results of reordering dig(1) flags and parameters.
- Read the nslookup(1) manual page and try an interactive mode query.
More information
dig(1), host(1), nslookup(1)
|