The DNS Protocol - Part 4: DNS Response Message Format
The previous article covered the DNS Query message formats. In the article we analysed them in great detail and showed how various options are selected by the host using the Flags/Parameters field. This article moves one more step ahead by covering the DNS response received from the previously generated DNS queries. DNS responses, in the case of a recursive DNS query, come directly from the DNS server that received our initial DNS query, while in the case of a non-recursive DNS query, the response arrives from the last DNS server the client (PC) queries in order to get the required DNS information.
DNS Analysis - Server Response
Here is the response (highlighted section in the screenshot below) to the previous DNS query sent to DNS server with IP address 139.130.4.4:
Something worth paying attention to is the time it took to receive and answer to our DNS query, which was only 0.991 seconds!
There are a lot of factors that contribute to this fairly fast reponse: The UDP transport protocol , which does not require any 3-way handshake, the load of the initial DNS server queried, the load of the other DNS servers that had to be ask, the connection speeds of everyone (our workstation, DNS servers, etc), and the traffic load between all paths our packets have taken during this DNS query/response!
Analyzing a DNS Packet
Following is the Ethernet II packet that runs on the local network. The structure is the same as our previous DNS query packet, but varies in size:
Now, to make the analysis of the DNS Section easier we have also included the DNS Query (left) and DNS Response (right). This allows us to easily compare both DNS query and response packets:
By comparing the two packets, we can see that there are fields in the DNS Response packet (marked with green arrows) that didn't exist in the Query. Let's see again what each field means and anaylse them again as we did in the previous page.
The DNS Section in a response packet is considerably larger and complex than that of a query packet. For this reason we are going to analyse it in parts rather than all together. The query had only one section that required in-depth analysis whereas the response has three since the first one is the original query sent:
Here is the section of a DNS response:
You can clearly see that everything after the block labeled "DNS Query Section" is new. We are going to focus on these 3 new blocks, which are part of the DNS Response Section, as the rest has been covered in the previous article.
DNS Response Section
The diagram below shows you the contents of the 3 new blocks (sections) we are looking at and they are:
- Answers
- Authoritative Nameservers
- Additional Records
What we need to need understand is that each of these three sections have identical fields. Even though the information they contain might seem a bit different, the fields are exactly the same and we will see this shortly.
In the picture above, we have only expanded the first part of the Answer section which is underlined in green so you can compare the fields with the ones contained in the left hand picture.
This picture below shows the expanded version from the first part of both Answers & Authoritative sections. We have already marked and labeled the fields to prove to you that they are all identical and vary only in the information they contain:
Looking carefully at both Answers & Authoritative sections, we notice that the Resource Data field is first, where according to the analysis of the sections in the picture above (left side), you would expect it last.
The actual position of the field is last, but it's presented first by the packet analyser to make the presented data more user friendly.
This is also the reason the first line of each part in each section is used to provide a quick summary of the information captured.
For example, looking at line 1 in the Answers Section (underlined in green), we get a summary of the data that will follow: www.firewall.cx, type INET, cname firewall.cx.
This proves that the fields in all of these 3 sections contained in the DNS Response Section are identical, but contain different values/data.
Looking at each section (coloured area), one can notice that there are actually two answers which appear as a hierachical tree with the boxed '+' symbol next to them.
A question often asked is why are there two answers for each section and could there be more or less answers?
The answer is simple and logical, there are as many answers as needed, depending on the way the domain has been setup. For example, Firewall.cx currently has two nameservers configured domain, which explains the two answers for each section. If we had three nameservers configured, then we would get three answers per section.
To help make this clear, we also captured a DNS Response packet from a DNS query for the domain ibm.com:
As it is evident, our query for IBM.COM gave us a response which has 4 answers per section!
Again, each answer in every section has identical fields, but different data/values.
You might have noticed a pattern here as well. In every DNS Response you will find the same number of answers per section.
For example, the screenshot on the left shows us 4 answers for the Answers, Authoritative and Additional records sections and this is no coincidence.
The Type field will help us understand why. Let's take a look at it.
The Type Field
The Type field determines the type of information we require about a domain.
The table below contains the most frequently requested Type of DNS information:
Type
|
Meaning
|
Contents
|
A
|
Host Address
|
32-Bit IP Address of host or domain
|
CNAME
|
Canonical Name (Alias)
|
Canonical domain name for and alias e.g www
|
HINFO
|
CPU & OS
|
Name of CPU and Operating System
|
MINFO
|
Mailbox
|
Info about a mailbox or mail list
|
MX
|
Mail Exchange
|
16-bit preference and name of the host that acts as a mail exchange server for a domain e.g mail.firewall.cx
|
NS
|
Name Server
|
Authoritative name server for the domain
|
PTR
|
Pointer
|
Symbolic link for a domain. e.g net.firewall.cx points to www.firewall.cx
|
SOA
|
Start Of Authority
|
Multiple fields that specify which parts of the naming hiererchy a server implements
|
TXT
|
Arbitrary Text
|
Uninterpreted string of ASCII text
|
To give a simple example, when we have a Type=A , we are given the IP Address of the domain or host (look at Answers section below), whereas a Type=NS means we are given the Authoritative Name Servers that are responsible for the domain (look at Authoritative Name Servers section below).
The screenshot below, was taken from our first example (query for firewall.cx) and we can see why the Type field is responsible for the data we receive about the domain:
As we can see, the Type field (red circle) in the first answer of the Authoritative Name Servers section is set to NS, which means this part contains information about the Authoritative name servers of the queried domain.
Going to the first answer of the Additional records, we can see that the Type field here is set to A, which means the data contained in this part is an IP address for the particular host.
When requesting the name servers for a domain, it also also essential their IP address is also provided, so that the client can construct a DNS query and send it to the name servers for that domain.
In this article we analysed the DNS response message format by looking into the details of a DNS response packet. We also covered the different DNS type field messages and explained the contents of the DNS Response message.
Back to the DNS Protocol Section
Type
|
Meaning
|
Contents
|
A
|
Host Address
|
32-Bit IP Address of host or domain
|
CNAME
|
Canonical Name (Alias)
|
Canonical domain name for and alias e.g www
|
HINFO
|
CPU & OS
|
Name of CPU and Operating System
|
MINFO
|
Mailbox
|
Info about a mailbox or mail list
|
MX
|
Mail Exchange
|
16-bit preference and name of the host that acts as a mail exchange server for a domain e.g mail.firewall.cx
|
NS
|
Name Server
|
Authoritative name server for the domain
|
PTR
|
Pointer
|
Symbolic link for a domain. e.g net.firewall.cx points to www.firewall.cx
|
SOA
|
Start Of Authority
|
Multiple fields that specify which parts of the naming hiererchy a server implements
|
TXT
|
Arbitrary Text
|
Uninterpreted string of ASCII text
|
Your IP address:
3.135.220.208
Wi-Fi Key Generator
Follow Firewall.cx
Cisco Password Crack
Decrypt Cisco Type-7 Passwords on the fly!