Trace the Internet

I am sure, Network Engineers would be very familiar with this term so does the crime investigating officer and both would agree trace leads to nabbing the crime and criminals. Of course, both these professions have different definitions of crime and the criminal.

Most Network/System engineers use the traceroute command to know all in-transit hops from the source host to the destination host. But here we are not talking about traceroute. We are talking about DNS trace.

Before explaining the DNS trace, it would be ideal to reimagine the Public DNS Infrastructure with the below diagram.

To know more about Public DNS Infrastructure Refer to Public DNS Infrastructure.

Kindly be mindful of the different constituents where they are placed, and the arrows with the number sequences on them to understand the flow of a DNS Query.

Kindly note the movie begins from a user machine with a simple DNS query for an internet domain (example.com) and it ends on the same user machine. What goes beyond is phenomenal and captured below through the trace. Let’s play

Time to run a DNS Trace

Let’s resolve a website example.com to see how the DNS resolves it.

In Linux command used it dig +trace example.com@8.8.4.4

In Windows same results can be achieved with nslookup -debug example.com 8.8.4.4

The tool used – digwebinterface

dig +trace example.com@8.8.4.4

.			12775	IN	NS	g.root-servers.net.
.			12775	IN	NS	j.root-servers.net.
.			12775	IN	NS	e.root-servers.net.
.			12775	IN	NS	l.root-servers.net.
.			12775	IN	NS	d.root-servers.net.
.			12775	IN	NS	a.root-servers.net.
.			12775	IN	NS	b.root-servers.net.
.			12775	IN	NS	i.root-servers.net.
.			12775	IN	NS	m.root-servers.net.
.			12775	IN	NS	h.root-servers.net.
.			12775	IN	NS	c.root-servers.net.
.			12775	IN	NS	k.root-servers.net.
.			12775	IN	NS	f.root-servers.net.
;; Received 228 bytes from 8.8.4.4#53(8.8.4.4) in 36 ms

com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.
;; Received 489 bytes from 198.97.190.53#53(198.97.190.53) in 154 ms

example.com.		172800	IN	NS	a.iana-servers.net.
example.com.		172800	IN	NS	b.iana-servers.net.
;; Received 77 bytes from 192.48.79.30#53(192.48.79.30) in 25 ms

example.com.		86400	IN	A	93.184.216.34
;; Received 45 bytes from 199.43.135.53#53(199.43.135.53) in 18 ms

1. The user types “example.com” into their web browser and hits enter.
2. The browser sends an Iterative DNS query to the local DNS resolver on the user’s device.
3. The local DNS resolver forwards the query to the recursive DNS resolver of the user’s ISP or On-Prem DNS Server.
4. The recursive DNS resolver sends a recursive query to the root DNS server, asking for the IP address of the TLD DNS server for the “.com” TLD.
5. The root DNS server responds with the IP address of the TLD DNS server for the “.com” TLD.
6. The recursive DNS resolver sends a query to the TLD DNS server for the “.com” TLD, asking for the IP address of the authoritative DNS server for “example.com”.
7. The TLD DNS server responds with the IP address of the authoritative DNS server for “example.com”.
8. The recursive DNS resolver sends a query to the authoritative DNS server for “example.com”, asking for the IP address associated with the domain name.
9. The authoritative DNS server responds with the IP address of the web server hosting “example.com”.
10. The recursive DNS resolver sends the IP address back to the local DNS resolver on the user’s device.
11. The local DNS resolver sends the IP address back to the user’s web browser.
12. The user’s web browser uses the IP address to connect to the web server hosting “example.com” and displays the website to the user.

If you follow the Public DNS Infrastructure and compare it with the above Trace for resolving A record for ‘example.com’. Trace Path is

Your Machine ——> sends an Iterative Query ——> Your On-prem/ISP DNS Server

Your Local DNS Server keeps rotating the Recursive query to First Root Name Server, then to TLD Name Server and then requested domain (example.com) Name Servers to find the query.

Iterative and recursive queries are two different ways of resolving domain name system (DNS) queries. Let us understand what they are in the next section –

Iterative Query vs Recursive Query

An iterative query is a type of DNS query in which the DNS client asks a DNS server to provide the best answer it can, based on its locally cached data or its zone data, without referring the query to another server. If the server does not have the requested information, it will return a referral to the client, telling it which other DNS server to query.

In contrast, a recursive query is a type of DNS query in which the DNS client asks a DNS server to provide a complete answer to the query. If the server does not have the requested information, it will query other DNS servers on behalf of the client until it can provide a complete answer.

In other words, iterative queries put the burden of finding the answer on the client making the request, while recursive queries put the burden on the DNS server handling the request.

In terms of performance, iterative queries tend to be faster than recursive queries because they require fewer network round trips. However, recursive queries provide more complete and accurate results, since they will continue to query DNS servers until they find a complete answer.