Introduction
This section will help you understand how the DNS queries work on the Internet and your home network. There are two ways to use the domain name system in order to resolve a host or domain name to an IP Address and we're going to look at them here. There is also a detailed example later on this page to help you understand it better.
Queries and Resolution
As mentioned in the introduction section, there are two ways for a client to use the domain name system to obtain an answer.
One of these involves the client contacting the name servers (this is also called a non Recursive query) one at a time until it finds the authority server that contains the information it requires, while the other way is to ask the name server system to perform the complete translation (this is also called a Recursive query), in which case the client will send the query and get a response that contains the IP Address of the domain it's looking for.
It's really exciting to see how DNS queries work. While analysing with you the packets that are sent and received from the DNS server, I'm going to show you how the client chooses the method by which it wants its query to be resolved, so you will truly understand how these cool features work ! The DNS Query/Response Message Format pages contain all this packet analysis information, so let's continue and prepare for it !
Our Example DNS Resolution
We will now look at what happens when your workstation requests a domain to be resolved. The example that follows will show you the whole procedure step by step, so make sure you take your time to read it and understand it !
When someone wants to visit the Cisco website (www.cisco.com), they go to their web browser and type "http://www.cisco.com" or just "www.cisco.com" and, after a few seconds, the website is displayed. But what happens in the background after they type the address and hit enter is pretty much unknown to most users. That's what we are going to find out now !
The picture below shows us what would happen in the above example: (for simplicity we are not illustrating both Primary and Secondary DNS servers, only the Primary)
Explanation:
1. You open your web browser and enter www.cisco.com in the address field. At that point, the computer doesn't know the IP address for www.cisco.com, so it sends a DNS query to your ISP's DNS server (It's querying the ISP's DNS because this has been set through the dial-up properties; if you're on a permanent connection then it's set through your network card's TCP/IP properties).
2. Your ISP's DNS server doesn't know the IP for www.cisco.com, so it will ask one of the ROOT DNS servers.
3. The ROOT DNS server checks its database and finds that the Primary DNS for Cisco.com is 198.133.219.25. It replies to your ISP's server with that answer.
4. Your ISP's DNS server now knows where to contact Cisco's DNS server and find out if www.cisco.com exists and its IP. Your ISP's DNS server sends a recursive query to Cisco.com's DNS server and asks for an IP address for www.cisco.com.
5. Cisco's DNS server checks its database and finds an entry for "www.cisco.com". This entry has an IP address of 198.133.219.25. In other words, the webserver is running on the same physical server as the DNS ! If it wasn't running on the same server, then it would have a different IP. (Just a note, you can actually make it look like it's on the same physical server, but actually run the web server on a different box. This is achieved by using some neat tricks like port forwarding)
6. Your ISP's DNS server now knows the IP address for www.cisco.com and sends the result to your computer.
7. Your computer now knows who it needs to contact to get to the website. So it sends an http request directly to Cisco's webserver and downloads the webpage.
I hope you didn't find it too hard to follow. Remember that this query is the most common type. The other type of query (non recursive) follows the same procedure, the difference is that the client does all the running around trying to find the authoritative DNS server for the desired domain, I like to think of it as "self service" :)
| DNS Response Message Format |
Introduction
The previous page delt with the DNS Query message formats. We analysed them in great detail and showed how various options are selected by the host using the Flags/Parameters field.
On this page we will see and analyse the responses we get from the generated queries. These responses, in the case of a recursive query, come directly from the DNS server to which we sent the query and, in the case of a non-recursive query, will come from the last DNS server the client contacts in order to get the required information.
Lastly, keep in mind that this page is the continuation of the previous page, so it's important to understand the previous material ! If you have any doubts, read the previous section again.
Now that we have all that out of the way ....let's grab a few DNS responses and get our hands dirty :)
DNS Analysis - Server Response
Here is the response (highlighted) to the previous DNS query sent to an Australian DNS server (139.130.4.4), where I asked for the resolution of www.firewall.cx:
Something worth paying attention to is the time this query took to come back to my Linux file server. The time taken, from the moment the packet was sent from the Linux file server, until it received the answer, was only 0.991 seconds !
During this short period of time the packet travelled from Greece to Australia, reached the DNS server, which sent its queries to other DNS servers until it found the answer and then generated a DNS response that was sent back to Greece where my home network is !
There are a lot of factors that contribute to this fairly fast reponse. The transport protocol UDP, which does not require any 3-way handshake, the load of the DNS server to which I sent the query, the load of DNS servers it then had to ask, the speed at which all these servers and myself are connected to the Internet and the general load between the routers that my packet had to travel in order to get to its various destinations !
As you can clearly see, there is a lot happening for just one DNS query and response. Try to consider what happenes when you have 20,000,000 DNS queries happening at once on the Internet and you have a good idea on how well this protocol and the underlying technology have been designed !
Following is the Ethernet II packet that runs on the local network. The structure is the same, but varies in size, regardless of whether it's a DNS Query or Response:
Now, to make the analysis of the DNS Section easier I have also included the DNS Query (left hand side) and DNS Response (right hand side). This allows you to compare what we sent and what we received :
By comparing the two packets, you 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 more complex than that of a query. 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 DNS Section of a DNS response:
You can clearly see that everything after the light green 3D 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 page.
DNS Response Section
The analysis of this section won't be too difficult because the format that is followed in each 3D block of our DNS Response Section is identical. For this reason, I have not analysed all 3 3D blocks, but only a few to help you get the idea.
The diagram below shows you the contents of the 3 3D blocks (sections) we are looking at: Answers Section, Authoritative Name Servers Section and the Additional Records Sections:
What we need to need understand is that each one 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, I 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 next picture shows you the expanded version from the first part of the Answers and Authoritative sections. I have already marked and labeled the fields to prove to you that they are all identical and vary only in the information they contain:
If you look carefully you will notice that the Resource Data field is presented first, where according to the analysis of the sections in the picture above (left side), you would expect it last.
The truth is that it is last, but it's presented first just because the packet sniffer likes to make the data more readable and less confusing.
This is also the reason the first line of each part in each section is used to give you a quick summary of the information captured.
For example, looking at line 1, part 1 in the Answers Section(underlined in green), you get a summary of what's to follow: www.firewall.cx, type INET, cname firewall.
This proves that the fields in all of these 3 sections contained in the DNS Response Section are identical, but contain different values/data.
You also might wonder why there are 2 parts in each section ?
Could there be more or less parts, depending on the domain name or is there always 2 parts in each section ?
The answer is simple and logical, there are as many parts as needed, depending always on the domain setup. For example, if I had more than two name servers for the Firewall.cx domain, you would see more than two parts in the Authoritative nameserver section and the other sections.
Our example has only 2 parts per section whereas the one we see below has a lot more :
This DNS Response Section is based on a query generated for the IBM.COM domain:
As you can see, our query for IBM.COM gave us a response which has 4 parts per section !
Again, each part 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 parts per section.
For example, the picture on the left shows us 4 parts for theAnswers, Authoritative and Additional records sections and this is no coincidence.
The reason this is no coincidence - between the 3 sections (Answers, Authoritative and Additional records) is the Type field, explained below.
The Type Field
The Type field determines the type or part of information we require about a domain. To give you the simplest example, when we have a Type=A , we are given the IP Address of the domain or host (look at Answers section above), whereas a Type=NS means we are given the Authoritative Name Servers that are responsible for the domain (look at Authoritative Name Servers section above).
Looking at the picture below, which is from our first example (query for firewall.cx) we can see exactly how the Type field is responsible for the data we receive about a domain:
As you can see, the Type field (red circle) in the first part of theAuthoritative 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 part 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 a particular host.
So where is the logic to all this ?
Well, if you were told which servers are authoritative for a domain (Authoritative Name Server Section), it would be useless unless their IP Addresses (Additional Records Section) were also provided.
This is the reason in this example we have been told about the Name Servers for the firewall.cx domain (Authoritative Name Server Section), but also given their IP Address (Additional Records Section).
The same rule and logic explains why there are 2 parts for all three sections of this example.
Let's have a look at the different values the Type field can have, this will also give you an insight into the information we can request and receive about any domain:
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 |
The above values the Type field can take are contained within the DNS database, which is covered next.
This completes our discussion on the DNS Response message format .
No comments:
Post a Comment