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 fun­da­men­tal column of the internet, and essential for name res­o­lu­tion in the DNS where the domain name (e.g. ‘www.ionos.com’) is trans­lat­ed into an IP address. This is a necessary process given that IP addresses are the only possible means for con­tact­ing the server of an online service and obtaining the required data from this.

De­f­i­n­i­tion: root server

A root name server (also called a DNS root server or a root server for short) is re­spon­si­ble for fun­da­men­tal functions when it comes to trans­lat­ing 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 res­o­lu­tion itself and instead informs the re­quest­ing client about which other name server (DNS server) it can obtain further in­for­ma­tion 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 in­dis­pens­able when it comes to name res­o­lu­tion. 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 reg­is­ter­ing and naming web addresses.

Tip

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 un­der­stand the root server’s mechanics, it helps to first know a thing or two about the fun­da­men­tal process of name res­o­lu­tion in the DNS. In addition to an in­di­vid­ual 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.com’ in your browser, the website’s al­phanu­mer­ic name first has to be trans­lat­ed into the IUP address so that the browser can then present the page.

The process of name res­o­lu­tion

The primary role of Domain Name Systems is to translate domain names into IP addresses (also called ‘forward lookup’). The process of online name res­o­lu­tion creates a hi­er­ar­chi­cal­ly organized process. However, before the DNS can be assigned to carry out name res­o­lu­tion, 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 res­o­lu­tion 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.

  1. After you’ve initiated the calling-up process in your client, your computer’s local DNS resolver is assigned the task of name res­o­lu­tion. A resolver is a module that acts as an interface between an ap­pli­ca­tion 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 res­o­lu­tion 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 res­o­lu­tion.
     
  2. If there’s no record for the requested website in the host file, then the DNS revolver’s ap­pli­ca­tion or operating system checks your client’s cache (buffer storage) on the domain name. If the requested website or another site reg­is­tered of the same internet presence (.e.g ‘hosting.ionos.com/dig­i­tal­guide) has already been booked and the in­for­ma­tion on this is still available in the cache, then the IP address is taken from this same location.
     
  3. 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.
     
  4. 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 in­for­ma­tion.
     
  5. If this doesn’t lead to any result, the provider’s DNS server then turns to a root server and requests ad­di­tion­al in­for­ma­tion 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 in­for­ma­tion on which top-level domain name servers (TLD name servers) are re­spon­si­ble for further an­nounce­ments for a certain TLD is stored on the DNS root server in the root zone file. For the domain name ‘www.ionos.com’, the root server was sent to the Verisign’s TLD name server, as this or­ga­ni­za­tion is re­spon­si­ble for all websites with this TLD.
     
  6. Next, the provider name server sends a request to the TLD name server and doesn’t receive any de­fin­i­tive answer. It is instead forwarded once again: the TLD name server’s sole function involves for­ward­ing. They let re­quest­ing servers know which one of the au­thor­i­ta­tive DNS servers the desired domain name is stored on.
     
  7. At this step, the provider name server turns to the au­thor­i­ta­tive server that’s re­spon­si­ble for the domain name and finally receives the desired IP address.
     
  8. 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 trans­ferred to your browser so that it can make a request to the website, load it, and display it.

When it comes to name res­o­lu­tion, many different name servers can be used. However, root name­servers play an important role within this process.: they depict the highest level instance within the name res­o­lu­tion — in case a domain name cannot be trans­lat­ed 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 res­o­lu­tion is always suc­cess­ful in the pre­vi­ous­ly-mentioned step, the necessary in­for­ma­tion 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 re­spon­si­bil­i­ty (Internet Cor­po­ra­tion for Assigned Names and Numbers). These are, however, operated by different in­sti­tu­tions that ensure that data exchange in the root zone always remains correct, available, and secure. In addition to their in­di­vid­ual operators, this overview also displays the in­di­vid­ual 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 Com­mu­ni­ca­tions
D 199.7.91.13 2001:500:2d::d Uni­ver­si­ty 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 Au­to­nom­i­ca
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 re­spon­si­ble for the domain name is changed. Changing the root zone file is a rel­a­tive­ly complex process: as soon as an ap­pli­ca­tion for an update is reg­is­tered, this is then checked by the IANA (Internet Assigned Numbers Authority; a division of ICANN). If every­thing appears to be correct then the US De­part­ment of Commerce has to approve of the ap­pli­ca­tion given that ICANN is con­trac­tu­al­ly obliged to this entity. Only then is the changed im­ple­ment­ed 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 con­front­ed 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 co­op­er­a­tion 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 through­out the world that are re­spon­si­ble 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 re­li­a­bil­i­ty 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 tech­nol­o­gy first made this rel­a­tive­ly de­cen­tral­ized request pro­cess­ing in the root zone possible. The worldwide dis­tri­b­u­tion of servers fur­ther­more makes for shorter access times when it comes to pro­cess­ing 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 ca­pac­i­ties during normal operation: only a third of the available computing resources are used by servers. This helps ensure that name res­o­lu­tion can still be carried out when multiple DNS root servers ex­pe­ri­ence 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, ad­dress­ing internet services is no longer feasible.

Dif­fer­ence 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 web­host­ing 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 dif­fer­ences between these two server forms can be found at the end of the article; this topic, however, is not covered in this entry.

Go to Main Menu