DNS tree explanations and demonstrations

Accessing your favorite website is a simple enough task: just go to your browser and it takes care of everything. This usually takes less than 3 seconds. At first glance, this may seem simple, but in reality there are more complex steps involved in finding the right server and IP address to access our site.

These more complex actions are in fact DNS resolutions performed on a server for a given domain. In order to obtain error-free information, it is essential to query the authoritative DNS for the domain you are looking for. This is why the requester will scan the DNS tree to find authoritative DNS servers.

In this article, we’ll explain each stage of the DNS tree: it represents the hierarchy of the domain name system, starting from the root servers.

Understanding the DNS protocol

When we make a DNS resolution request, there are various elements to consider in the DNS question and response.
A request is made up of various elements, and we’ll look at 2 sections in the message sent and received.

1- Flags :

They are part of the Header section, which is structured on 12 bytes and can include up to 13 flags, each coded on a certain number of bits. We will focus on the following 4 flags:

• RD: if the bit is set to 1, recursion is requested.
• AA: if the bit is set to 1, the server being queried is an authority on the domain being searched.
• TC: if the bit is set to 1, the message received is truncated and an EDNS request must be used to receive the full message.
• RCODE: Between 0 and 65534. Only values between 0 and 5 really matter to us:

– 0 : No error
– 1: Invalid query format (EDNS required)
– 2 : Server not responding
– 3: The domain does not exist
– 4 : The name server does not support this type of request
– 5 : server refuses to answer

Note that we’ll be using the DIG command to perform the demonstrations. As a result, the term RCODE does not appear. This is replaced by “status” followed not by the bit but by the name of the error, or “NOERROR” if there is none.

2 – Types of answers :

The answer section is divided into 3 parts. Unlike the Header, where flags must be transmitted to send a correct message, parts of the response section can be empty if there is no response to give or if the request is truncated (TC to 1). Here are the different types of answers:

Answer: The server is the authority and answers what we’re looking for.
Authority: The server is not an authority on the domain, but refers us to the server or servers that can help us move forward with DNS resolution.
Additional: This section contains additional elements such as IP addresses for servers.

You can find the different parameters that a DNS query can have at this address: https: //www.iana.org/assignments/dns-parameters/dns-parameters.xhtml

Demonstration and tree tour

Now that you know a little more about the DNS protocol, let’s take a step-by-step tour down the DNS tree to find the authoritative servers for the altospam.com domain.

Step 1:

The purpose of this step is to retrieve the root server names.
Using the DIG command :

dig NS .

We obtain the following answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19633
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;. IN NS

;; ANSWER SECTION:
. 446196 IN NS a.root-servers.net.
. 446196 IN NS b.root-servers.net.
. 446196 IN NS c.root-servers.net.
. 446196 IN NS d.root-servers.net.
. 446196 IN NS e.root-servers.net.
. 446196 IN NS f.root-servers.net.
. 446196 IN NS g.root-servers.net.
. 446196 IN NS h.root-servers.net.
. 446196 IN NS i.root-servers.net.
. 446196 IN NS j.root-servers.net.
. 446196 IN NS k.root-servers.net.
. 446196 IN NS l.root-servers.net.
. 446196 IN NS m.root-servers.net.

At this stage, we have the list of root servers, 13 in all, each bearing a letter from “A” to “M”, followed by “.root-servers.net”. In reality, there aren’t 13 servers, but many more! In fact, there are 11 organizations worldwide that manage these “servers”: 8 are American, 2 are European and one is Japanese. These organizations have spread their servers over more than 189 sites today, and each site hosts hundreds of machines. So we don’t know the actual number of root servers, the aim is to have 100% availability at all times.

Step 2:

From now on, we’ll use non-recursive queries, meaning that we don’t want the queried server to resolve the tree for us. The request’s RD flag must have a bit set to 0. On DIG, this is the “+norecurse” option. When using DIG, RD no longer appears in the flags if it is set to 0. We’re now going to query a random root server to find out which servers have authority over altospam.com. Using the DIG command :

dig +norecurse NS altospam.com @e.root-servers.net

We obtain the following answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26357
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;altospam.com. IN NS

;; AUTHORITY SECTION:
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.

;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
b.gtld-servers.net. 172800 IN A 192.33.14.30
[…]
l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30
m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30

The response returned is of Authority type: we didn’t get any authoritative server on our domain, but on the “.com” top-level domain. The response also contains IPv4 and IPv6 addresses in the Additional section. Note that DIG allows you to query the server name directly, but it is preferable to use its IP if there is no GLUE record.

What does GLUE mean? Quite simply, it’s the IP address of a name server. This record becomes mandatory when the name server is a sub-domain of the domain you’re looking for. Take the following example: If ns1.domain.tld is a DNS server for domain.tld, then since ns1.domain.tld is contained within domain.tld, to avoid circular references, you’ll need to create a GLUE with the DNS for .tld, i.e. send them the ip of ns1. domain.tld.

Further information and an explanatory video can be found on the AFNIC website https://www.afnic.fr/ext/dns/html/cours245.html#619

With this in mind, we’ll use the IPv4 and IPv6 addresses provided in Additional. If none is provided, we’ll use an IP obtained by a new DNS request.

Step 3:

This is the last step in the DNS tree, and we’re going to randomly query one of the servers managing the .COM using an IPv4 obtained in the Additionnal section of step 2. Using the DIG :

dig +norecurse NS altospam.com @192.48.79.30

The IP 192.48.79.30 is that of the j.gtld-servers.net server.

We obtain the following answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37590
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;altospam.com. IN NS

;; AUTHORITY SECTION:
altospam.com. 172800 IN NS ns-725.awsdns-26.net.
altospam.com. 172800 IN NS ns-343.awsdns-42.com.
altospam.com. 172800 IN NS ns-1607.awsdns-08.co.uk.
altospam.com. 172800 IN NS ns-1454.awsdns-53.org.

;; ADDITIONAL SECTION:
ns-725.awsdns-26.net. 172800 IN A 205.251.194.213
ns-343.awsdns-42.com. 172800 IN A 205.251.193.87

All .COM NS servers give us the same result: 4 servers in the Authority section. These are the AWS Route 53 servers that manage our domain. These are the servers that make up our SLIST (the name used in RFC N° 1035), i.e. the name servers that have authority over the domain we’re looking for and that we’ll need to query when we want to know the MX, A, TXT records…

SLIST checks

The aim of this point is to check that there is consistency between the DNS responses in our SLIST, as a diagnostic tool would do, but this step is not normally performed by a standard query engine. It’s not enough to retrieve these 4 servers, we need to check that these DNS are correctly configured for the altospam.com domain. We need to make sure that they respond to us in UDP (or TCP) on port 53, that they are synchronized with the right information and that they return this list of servers when queried. We will therefore query these 4 servers with their IPv4 :

dig +norecurse NS altospam.com @205.251.194.213

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42511
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;altospam.com. IN NS

;; ANSWER SECTION:
altospam.com. 172800 IN NS ns-1454.awsdns-53.org.
altospam.com. 172800 IN NS ns-1607.awsdns-08.co.uk.
altospam.com. 172800 IN NS ns-343.awsdns-42.com.
altospam.com. 172800 IN NS ns-725.awsdns-26.net.

The first thing we see is that we get an Answer response and the 4 servers in our SLIST. Next, check the SOA returned by each server. The information must be identical, especially the Serial. By making a :

dig +norecurse SOA altospam.com @205.251.194.213

We obtain the following answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18579
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;altospam.com. IN SOA

;; ANSWER SECTION:
altospam.com. 172800 IN SOA ns-1454.awsdns-53.org. awsdns-hostmaster.amazon.com. 2014070403 7200 900 1209600 86400

All servers respond to the same SOA. These allow us to obtain the master DNS server authoritative on the domain: ns-1454.awsdns-53.org. This is where the 3 other secondary servers will retrieve their DNS information. This means that it’s extremely important to have at least 2 DNS servers for a domain in order to increase the rate of availability, as recommended by RFC 2182 in section 5. In addition, for each server, its IP(s) must be on different address classes and preferably on different AS (https://fr.wikipedia.org/wiki/Autonomous_System).

In our example, the servers ns-1454.awsdns-53.org (205.251.197.174), ns-1607.awsdns-08.co.uk (205.251.198.71), ns-343.awsdns-42.com (205.251.193.87) and ns-725.awsdns-26.net (205.251.194.213) all have IPs on different C classes.

No DNS for the desired domain

It’s possible that the domain you’re looking for doesn’t have a DNS, as in the case of fr.wikipedia.org. The wikipedia.org domain has 3 authoritative DNS servers, so we’ll use ns0.wikipedia.org for our tests. By dig :

dig +norecurse NS fr.wikipedia.org @ns0.wikimedia.org

We obtain the following answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60224
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1024
;; QUESTION SECTION:
;fr.wikipedia.org. IN NS

;; AUTHORITY SECTION:
wikipedia.org. 3600 IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2017080414 43200 7200 1209600 3600

The SOA for the wikipedia.org domain is returned, which means that the sub-domain doesn’t have its own DNS and that we need to query the ns0.wikimedia.org server to get our answers. Let’s try it out:

 dig +norecurse A fr.wikipedia.org @ns0.wikimedia.org

We obtain the following answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26696
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1024
;; QUESTION SECTION:
;fr.wikipedia.org. IN A

;; ANSWER SECTION:
fr.wikipedia.org. 600 IN A 91.198.174.192

;; ADDITIONAL SECTION:
fr.wikipedia.org. 600 IN AAAA 2620:0:862:ed1a::1

The ns0.wikimedia.org server is indeed an authority on fr.wikipedia.org and gives us an Answer response, as well as an Additional.

Conclusion

Finally, it doesn’t take long to find a domain’s DNS when it’s correctly configured. It’s extremely important to refer to authoritative DNS for the domain you’re looking for, rather than recursively querying DNS and getting a cache response. The latter may not be up to date, resulting in out-of-date information. Another important point is to check that all DNS servers in the zone are synchronized and returning the same information. If this is not the case, it will become impossible to know which server is responding to the right information. If you have 2 DNS servers for your domain and they return 2 different pieces of information, you’ll get an error every other time.