BSDwiki/ Query a DNS server

Query a DNS server

Author: Cezary Morga cm@therek.net FreeBSD

Reviewer: Mark Foster mark@foster.cc FreeBSD

Reviewer: 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.

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

  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)