DNS analysis in a nutshell

The DNS or the Domain Name System is considered the Internet’s phonebook, it’s a place that stores the domain settings in terms of records, here you can manage how a domain will behave in terms of IP resolution, aliases, email servers, and more advanced features.

If you are not familiar with the DNS you can see them in action when you are accessing a service. Most of the time, a recursive request (Reverse DNS lookup) is made because rarely do you type an IP address in your browser search bar.

It’s easier to write davidlares.com than typing 76.76.21.21

At this point, many events are executed internally just to figure out how to access a specific server on the Internet. The browser must find which is the IP address of a resource and then perform a proper HTTP request.

The DNS resolution can be present in many places. Here’s how the browser resolves your request.

First, the browser checks if the IP address corresponding to that specific domain is stored in the local cache.

Secondly, the browser checks if the IP address corresponding to that specific domain is stored in the systems hosts table in case there’s a static mapping.

Please refer to this resource that lists the location of that host's table in your OS.

If nothing is found, it generates a recursive request to the local DNS server, and if again nothing is found, the request goes to a root server that redirects the request to a higher server recursively until finding a response.

When a response is found, is temporarily cached in every DNS server instance that interacted in the request process. This also happens for all possible DNS records, such as: AAAA, CNAME, NS, MX, TXT and others.

The process explained above is just an example of a simple web request. But is more complex than that, in terms of security the DNS traffic travels in a text-plain form.

The DNS traffic uses the UDP protocol in the transport layer of the OSI model but is found as DNS traffic in the application layer, accessible through port 53. Since it’s UDP there’s no session, so, that layer is not considered and the packets are independent.

A quick hands-on demo

Please download, install and open Wireshark.

1. Select your desired instance
2. In the filter bar set up a DNS filtering: add dns as the criteria. Something like this

Analyzing the packet details section you will find that there’s a User Datagram Protocol section.

UDP packet information

And above, you can find the Ipv4 find the communication details. Below, the DNS query details.

Another way to solve get to know the DNS records is by performing a nslookup command execution. You can perform a:

nslookup gmail.com or:

nslookup
> gmail.com

or:

nslookup
> set type=MX gmail.com

What can conclude from this?

If for any reason a DNS server is exposed to the internet, is very easy to watch traffic tables, leading to whatever possible attack or record injection (DNS poisoning).

Securing a DNS server is required, they are not designed for secure connections.

Happy coding :)