Taming DNS in Wireshark. Part 2

In the previous article, we started looking at using the Wireshark packet analyzer to work with DNS. In this article we will continue our discussion of this topic and talk about DNS recursion. Here the principle of packet exchange will be a little more complicated, because in addition to the exchange of DNS packets between the client and the server, there will also be an exchange with an authoritative DNS server.

The domain name resolution system has a hierarchical structure and all DNS servers must be able to communicate with each other to receive answers to queries sent by clients. And it is quite obvious that the local DNS server cannot know information about hosts in all domain zones. Then the recursive DNS server comes into play.

To put it simply

A recursive DNS server sits between the authoritative DNS server (that is, the one responsible directly for specific DNS zones) and the end users who initiate DNS queries. Thus, every time a user wants to visit and explore a particular website, he enters the domain name, for example, into the address bar of the browser. From there, the recursive DNS server receives the request and begins looking up the IP address (IPv4 or IPv6) corresponding to the domain name. Soon after the required IP address is found, the DNS response is returned to the user's device and provides the necessary information. The browser on the user's device can then connect and load the desired website.

In fact, a recursive DNS server is, as a rule, the same DNS that we can see in our network connection settings.

So, what happens when our DNS is unable to find the requested resource in its cache?

When one DNS server needs to find an IP address, it queries the authoritative DNS server on behalf of the client making the initial request, essentially acting as the client. And this process is called recursion.

An authoritative DNS returns the searched IP address to the server that requested it, which then forwards this data to the client.

Let's look at a traffic dump that contains a recursive DNS query. On the client side we will see only two packages.

The first packet contains the initial request sent by the DNS client located at 172.16.0.8 to the DNS server located at 172.16.0.102.

If you expand the DNS protocol portion of this package, you will see that this is a standard Type A record query for the DNS name of the publisher www.nostarch.com.

Next, let's expand the Flags section, where it states that recursion is required.

For the client, everything looks similar to a simple DNS request – we sent two packets, in the first we made a request to the DNS server and in the response from the server we received the necessary information about the IP address of the publisher. Since there are no errors, the client ends up with a Type A resource record associated with the domain name www.nostarch.com.

But in fact, the process of resolving a domain name was somewhat more complicated and the response to the request was obtained through recursion. And in order to make sure of this, let’s consider the network traffic intercepted on the local DNS server when the request was initiated.

Here we already see four packages, of which the first and last are already familiar to us. The first is a request from the client to the DNS server, and the last is the response actually received by the client. After receiving the first packet, DNS server received the query, checked its local database and cache, and found that it did not know the answer to the query, which IP address corresponds to the DNS name www.nostarch.com. But since the original packet had the Recursion Desired flag, the DNS server contacted another DNS server with the corresponding request, as follows from the contents of the second packet.

In the second packet, DNS server, located at 172.16.0.102, sends a new request to the server located at 4.2.2.10. The first one is configured to forward queries that it cannot resolve on its own to an upstream DNS server. This request mirrors the original request, essentially turning the DNS server sending it into a client. At the same time, you can tell that this is a new request because the Transaction ID here is different from the ID number in the previous capture file.

As soon as this packet is received by the server located at address 4.2.2.1, the local DNS server will receive a response from it. Having received this response, the local DNS server will send a fourth packet to the DNS client with the requested information.

This example demonstrates only one level of recursion, but it can occur multiple times for a single DNS query. And although this received a response from DNS server located at 4.2.2.1, this server could recursively forward the request to another server to find the answer to the request. A simple query can spread around the world before the correct answer can be found.

To analyze and troubleshoot recursive DNS queries using Wireshark, you need to intercept traffic on the side of the DNS server to which the client initially sends its request.

Conclusion

In this article, we looked at how recursive queries work in DNS and how to analyze such queries using Wireshark. This tool can be very useful in solving problems with the DNS protocol.

And you can learn more practical tools within online courses from OTUS. You can view the full catalog of courses link.