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.
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.
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 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.
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:
|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|
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:
- 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 www.tech-juice.org returns the following response packet:
As you can see, the Answers section contains the answer to our query: the IPv4 address of www.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:
- 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.
- 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).
- 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.
- 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.
- 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 . . . : 188.8.131.52 Record Name . . . . . : docs.google.com Record Type . . . . . : 1 Time To Live . . . . : 86398 Data Length . . . . . : 4 Section . . . . . . . : Answer A (Host) Record . . . : 184.108.40.206 Record Name . . . . . : docs.google.com Record Type . . . . . : 1 Time To Live . . . . : 86398 Data Length . . . . . : 4 Section . . . . . . . : Answer A (Host) Record . . . : 220.127.116.11
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