DNS Root Servers: The most critical infrastructure on the internet

All System administrators have their own favorite topics, which they enjoy working with. Its always a nice thing to have a favorite topic of yours because that helps to understand that particular thing in a little more detail, simply because you
are interested. Learning more about a topic that we like is always easier, because its much easier to stick with that topic
and persevere for a long time because we love doing that.

In this article/blog post, i will be discussing an evergreen interesting topic of mine with you guys. Slashroot always welcomes your comments and suggestions because that will help us and others reading the article. In this post we will be discussing "DNS ROOT SERVERS", during the entire discussion we will uncover some of the famous myths that exists in  technology circles even today. If you find any mistake or wrong information in this post, please let us know, so that we can correct it from time to time.

DNS root servers are the most critical component for a successful working of internet. This is majorly due to following reasons.
 

• DNS root server's are the first step in resolving any domain name.
• If something happens to them at large, the whole of internet will be affected

Folks in technical industry do forget the last . (DOT) in an FQDN because DNS server software's did not make it mandatory to include the last . in an FQDN (for example www.google.com. ).

Its always a good thing to find out how large and critical infrastructures work together, because understanding them will always increase your interest to learn things and its internal working. Here in this article i will be sharing my findings on DNS root server's, some of the widely accepted myths about them, and who manages this critical thing for us normal people. Some of the major things that we will be discussing in this article is mentioned below.

1. Why are there only 13 DNS root servers (or is it a completely wrong information)
2. Where are these servers located, are all of them located in United States
3. Which organizations are responsible for handling and managing them
4. Who allocates the TLD names (names such as COM, ORG, NET etc)
5. When will we get more TLD names like something new .SOFTWARE, .DOCTOR, .Anything.
6. Does my country have a DNS root server, that's functional?

DNS was made, just because we humans are not capable enough to remember numbers, or i must say we can remember names better than numbers. But computer's and network addresses are always numbers. So there must be some technology in between that will sit and translate names to number's. But as i just said, computers are named only in number's, and even if there is a computer that will sit and translate you or give you the number associated with a name, you first need to know the number of that particular computer that will help you translate names to numbers.

And there is no solution other than at least remembering the number of that particular computer who will do the job of translation for you. That initial number that every DNS software needs to know are referred to as DNS root servers. In fact these root servers never does the complete job of translation, but its only a starting point of the entire translation procedure.

         www. example.com.

Although we humans will read it like www dot example dot com. The computer(your local DNS server) that will initiate the job of translation will start reading it from right to left rather than left to right. It will be something like dot com example www(yeah i understand that's gibrish but that's how it works). If you are a system administrator, then the below articles about DNS might prove helpful to you.

Read: How DNS resolution works

Read:  Difference between Iterative and recursive DNS queries

Read: Dns Zone file and its contents

Read: Zone transfer and its security

So the translating computer will begin its job from right to left, with dot com example www.  The first dot, indicates root servers. DNS server computer/software must know the number(numerical IP address) of them, because they are the starting point, as i told before in the job of the entire translation procedure. There are 13 IP addresses/number of these DOT server's that every DNS software's already know by default. Read carefully..i said 13 IP addresses and not 13 servers. (Don't even think that there are 13 DNS root servers. Its a big technical joke..:) ). Now you might be thinking that why that number is 13 and not not more.

The main reason is because when you plan a big architecture like DNS root server's, you need to go into several depths to analyse performance issues. So as i said there are 13 IP addresses. If you are a networking guy or a system administrator, you might already know that UDP is better than TCP where performance is the requirement. And due to performance issues, a UDP packet used for DNS is limited to 512 bytes, if your payload goes above 512 bytes, then TCP will be used.

TCP involves very high overhead, because it includes multiple steps and procedures to establish a TCP connection, that can slow the entire process.

Read: Why is TCP slow compared to UDP

1. TCP (Transmission Control Protocol)
2. UDP (User Data gram Protocol)

The first one is better suited for reliability and the second one is suited for performance. Things like DNS should never be slow, hence it by default works on UDP. And a single UDP packet should contain all this 13 IP addresses along with other UDP protocol information (416 bytes of 13 ip addresses and remaining protocol information of UDP). Yeah sure you can easily have 30 or 40 DNS root server IP addresses, but you will not be able to send all of them in one UDP packet (you will have to send them in multiple packets, that will reduce the performance). Hence for performance and low network overhead the root servers are limited to 13 IP addresses.

As i told before there are many more servers but are accessed by 13 ip addresses, globally. Multiple server instances will be handling a single IP DNS root server, and is also geographically distributed. Geographical distribution of DNS servers is very important because this will localize the servers, so for example, if am in india its faster for me to reach a DNS root server near me rather than reaching a root server located in US.

But yeah in the beginning all of them were located in US. But recent improvements have made them available in different countries and continents. According to Wikipedia, there are more than 370 root servers distributed in different continets. Below shown is a map of DNS root server locations. I have took the below map from google maps created by paf.
 

View Root Servers in the World in a larger map

Zoom inside the above shown DNS root server map, that shows geographical locations of the servers. Click on each location it will tell you the name of that particular server. Oh yeah the 13 root servers are named from A to M. They are named like a.root-servers.net to m.root-servers.net.

I was amazed to know the fact that even India had 3 DNS root servers. One in Bangalore, Chennai, and New Delhi.

There are multiple servers for one server for example a.root-servers.net is handled by many servers at different places. You might be thinking how is this being handled with 13 ip addresses.

Now there is a technology called as Anycasting that plays a major role in achieving this distributed architecture of DNS root servers. In simple terms anycasting is a technology that makes multiple servers, in fact many servers in different locations to share a single IP address. Which means, many servers will be available at that one address. Whenever a request is send to an anycast IP address, then networking routers will route that request to the nearest server possible. This means if i want to reach f.root-servers.net from India the nearest possible location is Chennai (which is shown in the map), rather than reaching some other location in the world. This is the reason why DNS root servers rely heavily on IP anycasting technology.

Some advantages of anycasting are mentioned below.

• High speed and low latency
• Anycasting is Resilient. Because even if the f.root-serves.net in Chennai goes down, the network will take me to the next nearest location in the map.
• Strong protection against biggest DDOS attacks.

I recommend reading the below article to grab some more info about anycasting.

Read: What is Anycast And How does it work?

You might be thinking who handles and manages these 13 DNS root servers. There are 13 organizations that manages these different servers distributed in different locations geographically. They are mentioned below.

There are 12 organizations that handles and manages DNS root servers. It should have been 13 organizations, but Verisign handles 2 DNS root servers ( when i say two servers, never think that they are two physical server instances...two is logical). But yeah as i told there are 13 root servers with 13 different IP addresses. You might think that these IP addresses never change, yeah correct in ideal cases these IP addresses will not change. However it can be changed without impacting anything, provided you are changing a couple of them (which happened multiple times in the past decade.). As i have previously told every DNS server will have these 13 IP addresses inbuilt into them, so they can run without any problem even though the new IP address is not updated (because the change of ip address will only happen to hardly one among them, which can be manually updated by you, or will get updated in the next release cycle of your DNS server software)

The best example of DNS root server anycasting can be proved by taking the example of j.root-servers.net, which is handled by Verisign, Inc. That single j.root-servers.net is having 70 servers in different locations, and all of those 70 servers are queried with a single IP address with the help of anycasting (query goes to the nearest server possible)

DNS root server's has a DNS root zone file. This DNS root zone file contains the names and IP addresses of all TLD's. Now TLD stands for Top level Domain. Which are some of the well know names that we know and use in our day to day lives. Some of the common TLD's are COM, NET, ORG, MIL, GOV, EDU etc.

ROOT ZONE DATABASE

The above link of root zone database, from IANA, contains the entire list of TLD's and organizations that manages them, or say authoritative for these TLD's. The DNS root zone contains the IP address of the servers that manages these TLD's (The total number of TLD is pretty large, coz of country code TLD's. Each country has its own specific TLD's. For example .US, .IN, .UK, .SE etc)

Still there is a main confusion. As there are 12 different organizations that manages these root servers. How is the root zone file updated, who authorizes the updates and who initially takes care of the modification/update. The management part of DNS root zone is shown below.

1. ICANN controls the content of the root zone file
2. US Department of Commerce approves the changes that needs to be done on the root zone
3. Verisign Inc( who handles two DNS root server's ) modifies the zone and distributes the updates to other DNS root servers.

If you interested in having a look at DNS root zone file, that contains all the DNS servers responsible for all TLD's like COM, ORG, EDU etc, then you can have a look at the below link, which contains the latest root zone file updates. The below shown zone file is a sample zone file of a.root-servers.net server, from verisign.

DNS ROOT ZONE FILE (With Latest Updates)

The above link contains the complete list of DNS servers responsible for each TLD's. The file is very latest, and was last updated on 15th of October 2013. The last update time can be verified from the DNS serial number represented as shown below.

.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2013101501 1800 900 604800 86400

The last modification time in the above SOA of a.root-servers.net is mentioned by the number 2013101501 (YYYYMMDDno of times modified on that date)

So as mentioned before in the beginning of this article, the complete name to number translation procedure starts with root servers, for which we took an example of translating www.example.com. (read by DNS servers as DOT COM EXAMPLE WWW). So the initial step is to send a query to the nearest possible DNS root server.

The DNS root server queried will reply back with a referral to DNS servers that handles COM TLD's, which once again is controlled by Verisign Inc. Below shown is a snippet of COM TLD server's which i took from the root zone file link.

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.

172800 shown in the above snippet is the TTL value. COM TLD servers comes among the highly used TLD's on the internet. Hence keeping a TTL value of 172800 (48 hours) is quite normal. Keeping higher TTL values will reduce the number of queries to the server. Because most of the DNS server's used by ISP's are caching name servers which will cache the result for 48 hours.

Now these TLD name servers will reply back with a list of name servers that are responsible for example domain. Now the final step in our translation procedure is to send a DNS query asking the IP address for the host WWW, to the name servers returned by the COM TLD servers (authoritative name servers for example.com domain, which will be managed by the owner.).

During the Domain registration process, the registrar will send the NS record (DNS server's responsible for the domain you registered), to that particular TLD registry operator (for example Verisign if you are registering a COM domain name). This NS record that's present in TLD name servers are sometimes referred to as glue records.

Recently ICANN opened bidding and applications for inclusion of new TLD names that will be available in the coming days. Similar to COM, ORG, EDU we will be having a lot of new TLD's for anything you can imagine of.

For example .APP, .SOFTWARE, .CLOUD, .FASHION, and much more...The entire list of applicants that bidded for the new TLD's can be viewed by the below ICANN link.

New ICANN TLD application list

These applicants if approved by ICANN will become responsible for their respective TLD's and their name servers. So in the near future we will be having a lot of new names to register (The company for which i was working previously, also bidded for several new TLD names. Its called Radix registry)

Before completing this article, let me give you a proof of what i told about why there are only 13 root servers. For understanding this let's run a DIG dns query command with trace option, and see what's the result.

[root@localhost ~]$ dig +trace google.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.5 <<>> +trace google.com
;; global options: +cmd
.                       168909  IN      NS      f.root-servers.net.
.                       168909  IN      NS      e.root-servers.net.
.                       168909  IN      NS      a.root-servers.net.
.                       168909  IN      NS      j.root-servers.net.
.                       168909  IN      NS      k.root-servers.net.
.                       168909  IN      NS      b.root-servers.net.
.                       168909  IN      NS      c.root-servers.net.
.                       168909  IN      NS      h.root-servers.net.
.                       168909  IN      NS      i.root-servers.net.
.                       168909  IN      NS      d.root-servers.net.
.                       168909  IN      NS      m.root-servers.net.
.                       168909  IN      NS      g.root-servers.net.
.                       168909  IN      NS      l.root-servers.net.
;; Received 512 bytes from 10.1.136.23#53(10.1.136.23) in 360 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 488 bytes from 193.0.14.129#53(193.0.14.129) in 230 ms

google.com.             172800  IN      NS      ns2.google.com.
google.com.             172800  IN      NS      ns1.google.com.
google.com.             172800  IN      NS      ns3.google.com.
google.com.             172800  IN      NS      ns4.google.com.
;; Received 164 bytes from 192.31.80.30#53(192.31.80.30) in 195 ms

google.com.             300     IN      A       74.125.24.113
google.com.             300     IN      A       74.125.24.139
google.com.             300     IN      A       74.125.24.101
google.com.             300     IN      A       74.125.24.100
google.com.             300     IN      A       74.125.24.102
google.com.             300     IN      A       74.125.24.138
;; Received 124 bytes from 216.239.36.10#53(216.239.36.10) in 21 ms

Dig with trace option is used to query DNS for trouble shooting purposes. It can be used to find how the entire DNS address translation is working. The first part of the result shows that my local DNS server gave me the list of 13 DNS root servers to me, and there is an important information given by dig, at the end of the 13 root servers. The information is shown below.

;; Received 512 bytes from 10.1.136.23#53(10.1.136.23) in 360 ms

Saw that? it's saying my local DNS server gave me 512 bytes of UDP packet that contained the address details of 13 root servers. This is the reason, there are only 13 root servers. For performance reasons we need to include all root server addresses inside one single UDP packet.

If you see the subsequent reply given by TLD, and authoritative name servers, its always less than 512 bytes.

Hope this article was helpful for understanding some of the concepts related to DNS root servers.