What is a root server? Definition and mechanics
IONOS editorial team
As soon as we contact an online service (like a website or an e-mail address), root name servers or (DNS) root servers take on an important role when it comes to locating the services’ address. They’re an important component of the domain name system (DNS), a fundamental column of the internet, and essential for name resolution in the DNS where the domain name (e.g. ‘www.ionos.co.uk’) is translated into an IP address. This is a necessary process given that IP addresses are the only possible means for contacting the server of an online service and obtaining the required data from this.
Definition: root server
A root name server (also called a DNS root server or a root server for short) is responsible for fundamental functions when it comes to translating domain names into IP addresses: it answers client requests in the domain name system’s root zone (the root zone marks the largest layer in the DNS’ name space). Here, the root name server doesn’t execute the name resolution itself and instead informs the requesting client about which other name server (DNS server) it can obtain further information from regarding the desired IP address.
This is carried out via the so-called root zone file, which is an important element of every DNS root server. The file itself only contains a size of roughly 2 MB. However, it contains all the names and IP addresses of all the top-level domains (TLDs). This data belongs to an important function: the root server relies on this file if it names the name server that contains the necessary details of its request.
But even if they only forward requests, root name servers are indispensable when it comes to name resolution. Without them, the DNS would not be able to function in its current form. A root server works on the domain name system’s root and is to some extent plays the most important role when it comes to registering and naming web addresses.
Rent a root server from IONOS and get full root access to VPS, dedicated and cloud.
How root servers work
But just how does a root name server help identify a website’s IP address. In order to understand the root server’s mechanics, it helps to first know a thing or two about the fundamental process of name resolution in the DNS. In addition to an individual internet address (domain name), every internet service features a unique numeric IP address that’s connected to the domain. Following this, the IONOS website was assigned the IPv4 address, ’17.160.72.6’. When you call up ‘www.ionos.co.uk’ in your browser, the website’s alphanumeric name first has to be translated into the IUP address so that the browser can then present the page.
The process of name resolution
The primary role of Domain Name Systems is to translate domain names into IP addresses (also called ‘forward lookup’). The process of online name resolution creates a hierarchically organised process. However, before the DNS can be assigned to carry out name resolution, the applied system general tries to find the needed IP address within its own data.
The number of stations a request passes through and the order in which it passes depends on many different factors. Factors that can influence this process include the user’s operating system or whether or not UDP or NetBIOs over TCP/IP is used as a protocol. The name resolution itself is always processed the same way in the DNS when it runs through different servers. We’ll show you some of the most important phases that this process goes through when searching for a website’s matching IP address and which role the DNS root server plays here.
- After you’ve initiated the calling-up process in your client (like "www.ionos.co.uk"), your computer’s local DNS resolver is assigned the task of name resolution. A resolver is a module that acts as an interface between an application and a DNS server. Firstly, this looks in the hosts file to see whether there’s an entry for the domain name. With the help of this text file, name resolution is able to be carried out directly via one’s own computer — at least this is the case if one manually assigns a hostname to an IP address in advanced. Given that the host file is a relic from the time before domain name systems came about and actually ended up replacing these, most users neither maintain nor use this file, which is why they don’t really help when it comes to name resolution.
- If there’s no record for the requested website in the host file, then the DNS revolver’s application or operating system checks your client’s cache (buffer storage) on the domain name. If the requested website or another site registered of the same internet presence (.e.g ‘hosting.ionos.co.uk/digitalguide) has already been booked and the information on this is still available in the cache, then the IP address is taken from this same location.
- The router name server looks into its own cache to see if the IP address is stored there. However, not all router name servers have a cache. If no cache is available or there’s no IP address available, then the router name server asks the name server of its provider for the websites IP address.
- By running a cross-reference with its data bank, your provider’s DNS server tries to find your domain name’s IP address. Here, different types of name server resolvers are used to gather information.
- If this doesn’t lead to any result, the provider’s DNS server then turns to a root server and requests additional information via the top-level domain of the searched website (the back portion of the domain name is composed of the TLD; examples of this include .com or .de). The information on which top-level domain name servers (TLD name servers) are responsible for further announcements for a certain TLD is stored on the DNS root server in the root zone file. For the domain name ‘www.ionos.co.uk’, the root server was sent to the Verisign’s TLD name server, as this organisation is responsible for all websites with this TLD.
- Next, the provider name server sends a request to the TLD name server and doesn’t receive any definitive answer. It is instead forwarded once again: the TLD name server’s sole function involves forwarding. They let requesting servers know which one of the authoritative DNS servers the desired domain name is stored on.
- At this step, the provider name server turns to the authoritative server that’s responsible for the domain name and finally receives the desired IP address.
- For the last step, the provider name server transfers the IP address to your router’s DNS server, which is then forwarded to your local resolver. From there, the IP address is transferred to your browser so that it can make a request to the website, load it, and display it.
When it comes to name resolution, many different name servers can be used. However, root nameservers play an important role within this process.: they depict the highest level instance within the name resolution — in case a domain name cannot be translated into an IP via a local resolver or a provider’s DNS server, the root server then becomes the starting point for locating the IP address. And even if the name resolution is always successful in the previously-mentioned step, the necessary information from the past is collected by the DNS root server and stored. For this reason, it’s important that the server is always able to carry out and support your service.
Root name server overview
In total, there are 13 main DNS root servers, each of which is named with the letters ‘A’ to ‘M’. They all have a IPv4 address and most have an IPv6 address. Managing the root server is ICANN’s responsibility (Internet Corporation for Assigned Names and Numbers). These are, however, operated by different institutions that ensure that data exchange in the root zone always remains correct, available, and secure. In addition to their individual operators, this overview also displays the individual root name servers.
| DNS-Root-Servers Letters | IPv4 address | IPv6 address | operator |
|---|---|---|---|
| A | 198.41.0.4 | 2001:503:ba3e::2:30 | VeriSign |
| B | 192.228.79.201 | 2001:478:65::53 | USC-ISI |
| C | 192.33.4.12 | 2001:500:2::c | Cogent Communications |
| D | 199.7.91.13 | 2001:500:2d::d | University of Maryland |
| E | 192.203.230.10 | NASA | |
| F | 192.5.5.241 | 2001:500:2f::f | ISC |
| G | 192.112.36.4 | U.S. DoD NIC | |
| H | 128.63.2.53 | 2001:500:1::803f:235 | US Army Research Lab |
| I | 192.36.148.17 | 2001:7FE::53 | Autonomica |
| J | 192.58.128.30 | 2001:503:c27::2:30 | VeriSign |
| K | 193.0.14.129 | 2001:7fd::1 | RIPE NCC |
| L | 199.7.83.42 | 2001:500:3::42 | ICANN |
| M | 202.12.27.33 | 2001:dc3::35 | WIDE Project |
Each of these root name servers contains an identical copy of the root zone file that may need to be updated from time to time—for example when the TLD responsible for the domain name is changed. Changing the root zone file is a relatively complex process: as soon as an application for an update is registered, this is then checked by the IANA (Internet Assigned Numbers Authority; a division of ICANN). If everything appears to be correct then the US Department of Commerce has to approve of the application given that ICANN is contractually obliged to this entity. Only then is the changed implemented in the root zone by VerisSign, which also operates two root servers, in the root zone.
DNS root server’s security measures
Root servers are confronted with a large number of requests day in, day out. A large number of the 13 root name servers isn’t simply answered by the clients’ request alone; this is done in cooperation with other servers as well. However, there are far more than simply 13 different servers that take care of the root zone requests; all in all, there are hundreds of such scattered throughout the world that are responsible for this task. Most of the servers are located in the United States or Europe.
The fact that these servers are so spread out helps with load balancing and hence increases the reliability of root servers: before Anycast came along, there were only the 13 main root name servers that were able to take care of answering requests. Given that 10 of these are located in the United States, Anycast technology first made this relatively decentralised request processing in the root zone possible. The worldwide distribution of servers furthermore makes for shorter access times when it comes to processing requests, given that the server always answers these in the shortest ways.
A further security measure in terms of the limits of the used root name server’s capacities during normal operation: only a third of the available computing resources are used by servers. This helps ensure that name resolution can still be carried out when multiple DNS root servers experience shortages: in such cases, the rest of the active servers take on the requests that were actually meant to be sent to the downed server.
Following this, various DDoS attacks on DNS root servers didn’t have any success in the past, as their security set-ups were just too strong. Those operating the 13 root servers know only too well what their servers mean for the internet: without them, addressing internet services is no longer feasible.
Difference to dedicated root servers
The DNS root servers described in this article refer to the root name server from the Domain Name System. This shouldn’t be confused with dedicated root servers), which can be rented through webhosting providers. Such hosts are often referred to as root servers as they differ from managed servers in that they feature a root access (more details on the differences between these two server forms can be found at the end of the article; this topic, however, is not covered in this entry.
