Networking
22 June 2011 0 Comments

The DNS Protocol Explained

The DNS Protocol

The Domain Name System protocol translates domain names into IP addresses (Wikibooks page). When a client wants to open a webpage at www.google.com, a query is sent to a DNS server (a.k.a. name server) to fetch the corresponding IP address. The IP returned by the name server is used to contact the Google web server – the server that hosts the actual website contents. In this post we explain the DNS protocol and the packets involved.

It is necessary to translate a name to an IP address before establishing a connection.

Usually, a client will know the IP address of one or more DNS servers after the DHCP boot process is completed. In order to resolve a hostname, a DNS query packet is sent. All DNS traffic between clients and name servers is encapsulated in UDP, and name servers always run on UDP port 53.

Note
With Wireshark, you can look at DNS traffic by using udp.port == 53 in the display filter.

DNS Packet Structure

The structure of DNS packets looks like this:

The DNS packet format.

The flags field (16 bits) has the following structure:

    a)  The first (0th)bit indicates query(0) or response(1)
    b) Next three bits (1-4) indicates ‘Standard Query (0)’,
       ‘Inverse Query (1)’ and ‘Server Status Request (2)’.
    c) The 5th bit field indicates Authoritative answer. The
       name server is authoritative for the domain in the
       question section.
    d) The 6th bit field is set if message was truncated. With
       UDP this means that the total size of the reply exceeded
       512 bytes and only the first 512 bytes of reply were
       returned.
    e) The 7th bit field indicates Recursion Desired. This bit
       can be set in a query and is returned in the response.
    f) The 8th bit field indicates Recursion Available or not.
    g) The next 3 bits (9-11) have to be 0.
    h) The next 4 bits (12-15) give a return code where
       0 signifies No Error and 3 signifies Name Error.

Query Packet

When a client sends a query to a name server, the Resource Record fields are empty. The Number of Questions field contains the amount of entries in the Questions field, usually 1. Each question consists of:

  • Name: A string containing the Internet address being queried
  • Class: The query class, normally the value 1 for Internet (“IN”).
  • Type: The record type to be queried, the most common types are:
Type Value
(decimal)		 Description
A 1 Query for the IPv4 address of a domain
AAAA 28 Query for the IPv6 address of a domain
CNAME 5 Check if the looked up domain is an alias
MX 15 Query for the mail exchanger (mail server) of a domain
NS 2 Query for the name servers responsible for a domain

Response Packet

A response sent by a name server to a client will contain the original questions in the Questions fields. Additionally the Resource Record fields contain one or more entries. A resource record entry has the following structure:

The format of entries in Resource Record fields. The Name and Resource Data fields are of variable length.

  • Name: Contains the object, domain or zone name that is the subject of the resource record.
  • Type: One of the available record types.
  • Class: Again, this is normally 1 .
  • TTL: Specifies the number of seconds that the record should be retained in the cache of the device reading the record.
  • RData Length: Indicates the size of the RData field, in bytes.
  • Resource Data: The data portion of the resource record.

The Answer Resource Records section of the DNS packet contains the most interesting resource records: the answer(s) to the query. For example, a query of type A for the domain tech-juice.org returns the following response packet:

The DNS response to a type A (IPv4 address) query for the domain tech-juice.org. The screenshot was taken using Wireshark.

As you can see, the Answers section contains the answer to our query: the IPv4 address of tech-juice.org. The Authoritative nameservers section contains two entries describing the nameservers responsible for the art0.org domain, and these entries are mirrored in the Additional records section to provide their IPs.

The Name Server

A client that wants to translate a name to an IP address sends a question to the name server(s) on its network. The name server provides an answer to the question, but it might have to contact several other servers to obtain the answer. A lot goes on behind the scenes that the client is blissfully unaware of. A typical scenario where a client looks up abc.company.com looks like this:

Translation of a domain name abc.company.com to IP address.

  1. The client formulates a question and sends it to the name server, expecting an unambiguous answer. The name server will first search its cache (5), and immediately answer the client if the answer is found.
  2. If the name server does not know the answer itself, it contacts the root name server. The root name server finds out that it does not know the IP for abc.company.com, but it contains an NS type resource record delegating the .com domain to a subordinate name server. So it returns the IP’s for the authoritative name servers for the .com Top Level Domain (TLD).
  3. The name server contacts the authoritative server for the .com domain, which contains an NS type resource record for the company.com domain. It will receive the IP addresses for the authoritative servers for the company.com domain.
  4. Then, the authoritative name server for the company.com domain is contacted, again asking for the IP of abc.company.com. This server then solves the query (or not), and transmits the result back to the name server. Finally, the name server sends the answer to the client.
  5. The name server also caches the information it obtains during the lookup process for future reference.

    This process is called iterative lookup, and it the most common approach for name servers that serve clients.

    DNS Tools on Windows and Linux

    Often the DNS client also contains a cache. This avoids having to repeatedly send queries each time a website is contacted. The image below illustrates the Windows DNS cache:

    To view the DNS cache, the ipconfig /displaydns command is used.

    C:>ipconfig /displaydns
 
Windows IP Configuration
 
    docs.google.com
    ----------------------------------------
    Record Name . . . . . : docs.google.com
    Record Type . . . . . : 1
    Time To Live  . . . . : 86398
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 74.125.77.101
 
    Record Name . . . . . : docs.google.com
    Record Type . . . . . : 1
    Time To Live  . . . . : 86398
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 74.125.77.102
 
    Record Name . . . . . : docs.google.com
    Record Type . . . . . : 1
    Time To Live  . . . . : 86398
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 74.125.77.100

    To clear the DNS cache, the ipconfig /flushdns command is used. Note that this will clear the cache, and then repopulate it with entries from your C:\Windows\System32\drivers\etc\hosts file. If your DNS cache isn’t completely empty after flushing it, this is probably the reason.

    C:>ipconfig /flushdns
 
Windows IP Configuration
 
Successfully flushed the DNS Resolver Cache.

    Most Linux distributions – including Ubuntu – do not provide a local DNS cache by default. *gasp*
    If you are a serious Linux user, chances are you will benefit from installing your own DNS caching daemon. Decent implementations are dnsmasq and nscd:

    sudo apt-get install nscd
sudo /etc/init.d/nscd restart

    Then to clear the DNS cache use:

    sudo /etc/init.d/nscd restart
Tags: a, AAAA, class, dns, domain name system, MX, port 53, question, resource record, , udp,