What are root name servers?

Netnod’s Lars-Johan Liman answers frequently asked questions about Internet’s root servers functions. Read here to better understand how they function.

So, what if a root server operator starts behaving badly?

In theory, a rogue root server operator could pose more problems than a defunct operator, in the sense that an inconsistent fault can be harder to solve than a total failure. But, practically, now that the root zone file is DNSSEC-signed, the scope for improper behaviour is greatly limited.

For example, if your computer uses Google’s DNS servers (8.8.8.8 and 8.8.4.4) and you open your bank’s website, you naturally expect that when you enter its familiar URL, you’ll be sent to the bank’s website.

Don’t fall for websites that suddenly pop up with flashing warnings telling you your computer has been infected with a virus, and that you must purchase some software to get rid of it. They’re always scams.

A DNS server is a computer server that contains a database of public IP addresses and their associated hostnames, and in most cases serves to resolve, or translate, those names to IP addresses as requested. DNS servers run special software and communicate with each other using special protocols.

You may see a DNS server referred to by other names, such as a name server or nameserver, and a domain name system server.

Earlier we learned about IP addresses that enable every machine to connect with other machines. But as we know humans are more comfortable with names than numbers. It’s easier to remember a name like google.com than something like 122.250.192.232.

This brings us to Domain Name System (DNS) which is a hierarchical and decentralized naming system used for translating human-readable domain names to IP addresses.

Root name servers are the servers at the root of the Domain Name System (DNS) hierarchy.

The authoritative name servers that the resolvers use to find top level Domains (like .se) are the root name servers.

The root zone

The root servers contain the information that makes up the root zone, which is the global list of top level domains. The root zone contains:

•    generic top level domains – such as .com, .net, and .org

•    country code top level domains – two-letter codes for each country, such as .se for Sweden or .no for Norway

•    internationalized top level domains – generally equivalents of country code top level domain names written in the countries’ local character sets

For each of those top level domains, the root zone contains the numeric addresses of name servers which serve the top level domain’s contents, and the root servers respond with these addresses when asked about a top level domain.

Who operates them?

The root servers are operated by 12 different organizations:

• A VeriSign Global Registry Services
• B University of Southern California, Information Sciences Institute
• C Cogent Communications
• D University of Maryland
• E NASA Ames Research Center
• F Internet Systems Consortium, Inc.
• G US DoD Network Information Center
• H US Army Research Lab
• I Netnod
• J VeriSign Global Registry Services
• K RIPE NCC
• L ICANN
• M WIDE Project

Many of these organizations have been operating root servers since the creation of the DNS. The list shows the Internet’s early roots as a US-based research and military network.

Where they are?

There are more than 1,300 root server instances around the world, on all six populated continents. They are reachable using 13 numeric IP addresses – one per operating organisation, except for Verisign, which operates two root servers. Most of those addresses are assigned to multiple servers around the world, so DNS queries sent to those addresses get fast responses from local servers. This was not always the case. Before 2004, there were root server instances in only 13 locations – one per IP address – and all but three were in the United States. However, significant efforts by several of the root server operators, including Netnod, have expanded the global root server footprint since then.

Because there are only 13 root server IP addresses, only 13 root servers can be seen from any single location at any given time. Different servers (using the same IP addresses) will be seen from different locations.

Who is responsible for them?

Each operating organization is solely responsible for the root server IP address (or addresses) it operates. The operating organization determines how many locations that IP address will be served from, what those locations are, what hardware and software will be installed in each location, and how that hardware and software will be maintained. Some operators operate only a single location, while others operate many (one operator is responsible for almost 100). Each organization secures its own operating funds.

Where does the root zone come from?

The root zone comes from the Internet Assigned Numbers Authority (IANA), which is part of the Internet Corporation for Assigned Names and Numbers (ICANN). It is signed using DNSSEC signatures to ensure authenticity, and issued to the root server operators to publish to their root servers. The root server operators publish the root zone as written, and have no authority to alter the content.

How do resolvers find root servers?

Since root servers are at the root of the DNS hierarchy, it isn’t possible to walk through the DNS hierarchy to find them: the resolvers wouldn’t know where to look. Instead, there is a list of well-known and rarely changed root server IP addresses, and every DNS resolver has that list of IP addresses included with the software. If a root server does need to change addresses – something that has happened multiple times over the years – this does not present a significant problem. Older resolvers continue to work by using the other 12 root server addresses, and their list gets updated when their software is updated.

Fault tolerance

More information

You can also read these excellent guides on the root server system: 

•    Root Server Technical Operations Association 

•    Internet Society Briefings on the root servers

Since 2000, Netnod has operated i.root-servers.net, one of the Internet’s 13 root name servers and the first to be located outside of the United States. The root name servers, identified by letters A through M, provide the entry points to the Domain Name System (DNS) and are a critical part of the Internet’s infrastructure. In this Q&A, Netnod’s Lars-Johan Liman explains how Netnod meets the challenges of operating such a crucial part of the Internet’s infrastructure.

1. How important are the root servers for the Internet?

Access to the information in the root zone is paramount to reach basically any service on the Internet. The root servers provide the easiest and most accessible way to retrieve that information. The entire Internet has come to depend on their service, and therefore they are of utmost importance for smooth operation of the Internet as a whole.

2. How does Netnod ensure the stability of the root service it provides

Ensuring the stability and accuracy of the root service is one of our most important goals. There are several components to this, including server stability, service reachability, software diversity, policy stability, and financial stability. I will make some brief comments on each of these:

•  
• we maintain thousands of peering relationships, where we exchange traffic with Internet service providers. If one route fails, the traffic will find other ways to reach our servers.
   
• our software experts are comfortable working with several variants of software to provide the same service. Should one specific software component fail, we can quickly replace it with another.
   
• Netnod’s staff actively participates in all relevant fora for DNS provisioning, and often take on positions of influence and responsibility. You will find the names of former and current Netnod employees as Chairs of working groups in the IETF and within ICANN, and also in leading positions in, for example, the Internet Engineering Steering Group (IESG) and the Internet Architecture Board (IAB). No relevant DNS meeting passes without Netnod’s presence. Through this engagement, Netnod is always aware of what’s going on, how to adapt to it, and when we need to step up and show the path forward.
   
• operating a root server requires neutrality and independence. As there is no source of income that comes from providing the root service, it needs to be subsidised from other sources. Netnod has chosen to provide a separate set of DNS services from the same service platform as the root service. These services, which are commercial and which we sell primarily to top-level domains, generate the income needed to provide a stable and well-functioning platform. This design gives us two benefits:
  1. We have a source of income that finances the root service in a way that actually relates to it. The TLDs depend heavily on the root, as the root servers are the ones to refer DNS clients to the TLD servers. This gives us the necessary income.
  2. By using money from a service with a multitude of customers, we ensure that no single customer is able to exert undue influence over our root service through a dominating position on our balance sheet. This allows us to maintain our neutrality and independence.

3. What role do the root server operators have in decisions on how the root server system operates?

The root server operators work independently of each other and of any parent organisation. Each organisation that provides root service decides for itself on the technical platform from which to provide the service. The service is governed by technical specifications in a few documents (some from the IETF, and some from ICANN). The service must adhere to these specifications, but as long as it does, the root operator is relatively free to decide its setup. The result is that the root operator provides a box which receives the root zone file on one side, and provides DNS service on the other. The root zone file is given – and identical for all root servers – and the service is prescribed in the documents. The flexibility sits inside the box.

The root operators are in close contact with each other, and maintain close cooperation and very good relationships. This ensures that we all agree on interpretation of the specifications, and it also helps us to maintain the diversity of the system by avoiding the use of identical designs.

4. What are some of the operational challenges in operating a root server?

Oh, there are lots! To pick just a few:

• To deploy servers: we have hundreds of servers operating in all corners of the Internet – some in cities you probably haven’t heard of. This involves a lot of  logistics: finding hosts, shipping servers to far away locations, and having remote hands, whom you have never met, help you mount and install the servers. I also know more about customs declaration forms than my computer science teacher in college could have ever dreamed!
• To constantly configure and provision the servers with correct DNS information, and make them collect and report accurate statistics for what’s going on over long-distance Internet connections and in a timely fashion.
• To make sure that the software we use actually provides the expected service. Sometimes the root service manages to break software in spectacular ways never expected by the vendors!
• To defend against various types of attacks – volumetric DDoS attacks, or attacks aiming at different types of vulnerabilities.
• To provide everyone in the Internet community across the public and private sector with a clear understanding of how the root server system works. Our goal is to ensure that any decisions that may impact the running of the root service are based on facts and not misconceptions. 
   

5. What are your plans for improving the root service that you provide?

One obvious way to improve is to deploy more servers. We plan to deploy more servers in Africa and Asia to improve our footprint. We also strive to develop our technical platform to make it cheaper and easier to deploy. The cheaper we can make it, the more servers we can buy for the money we have, and the more servers we can deploy. Developing the way the servers interact with their network neighbours is another way to enhance the service. If we can make it easier to deploy servers, we might be able to put servers in different types of network environments than the ones we currently interact with. Working with the other root server operators to improve the transparency and accountability of the system as a whole is another line of engagement. Netnod staff are also key contributors to the work inside ICANN that strives to develop the root server governance model.

If you are interested in becoming an I-root site host, please see the detailed requirements
You can see Lars-Johan’s recent webinar about Netnod’s I-root service

DNS Root Sever

A DNS (Domain Name System) Root Server, or root name server, is at the very highest level of the DNS hierarchy and essentially manages domain names for the entire Internet.

What is a DNS root server?

Root DNS servers are the servers that literally run DNS for the entire Internet. If we look at the picture above, we see that the root server is actually even above the Top-Level Domain (TLD) servers. These root servers contain the root zone, which is essentially a list of all the Top-Level domains such as generic TLDs like .com and .net or country code TLDs (ccTLDs) like .is or .us.

The root zone is managed by IANA (Internet Assigned Numbers Authority) which is a part of ICANN (Internet Corporation for Assigned Names and Numbers). Root servers serve out this root zone.

As shown in the picture, DNS is hierarchical. IANA manages the root zone as well as the various non-sponsored Top-Level Domains. From there, individuals, groups, or companies may lease the use of domain names from a domain name registrar. These domain names are registered with authoritative servers within the hierarchy. If a domain name has not been cached by the client’s DNS server, that DNS server will go all the way to the root server to find the IP address assigned to a particular domain name within a URL.

What are the root servers?

The root servers are the entry points to the Domain Name System (DNS), the distributed database which Internet applications use to look up the numerical IP addresses associated with text-based domain names. 

Do all root server operators have multiple servers?

Most do, but not all. It’s entirely up to each operator whether to use anycast or not. Currently, there is only one instance of B, whereas there are 145 instances of L. Netnod operates 41 instances of I (i.root-servers.net).

How DNS Servers Resolve a DNS Query

When you enter a website address into your browsers address bar, a DNS server goes to work to find the address that you want to visit. It does this by sending a DNS query to several servers, each of which translates a different part of the domain name you entered. The different servers queried are:

• A DNS Resolver: Receives the request to resolve the domain name with the IP address. This server does the grunt work in figuring out where the site you want to go actually resides on the internet.
• A Root Server: The root server receives the first request, and returns a result to let the DNS resolver know what the address of the Top Level Domain (TLD) server that stores the information about the site. A top level domain is the equivalent of the .com or .net portion of the domain name you entered into the address bar.
• A TLD Server: The DNS resolver then queries this server, which will return the Authoritative Name Server where the site is actually returned.
• An Authoritative Name Server: Finally, the DNS resolver queries this server to learn the actual IP address of the website you’re trying to deliver.

Once the IP address is returned, the website you wanted to visit is then displayed in your web browser.

It sounds like a lot of back and forth, and it is, but it all happens very quickly with little delay in returning the site you want to visit.

The process described above happens the first time you visit a site. If you visit the same site again, before the cache on your web browser is cleared, there’s no need to go through all these steps. Instead, the web browser will pull the information from the cache to serve the website to your browser ever faster.

What is the advantage of having a root server nearby?

Certain DNS activities may get a moderate performance boost if a root server is installed nearby. But remember, these are only a small subset of all online activities, and most of the heavy lifting in DNS takes place in local caches. Furthermore, despite the outraged comments you can find in countless ill-informed online discussions, a local root server does not give its host country any special preference in DNS policy making. The real benefit of installing more root servers in more places is that it makes the DNS overall more robust and resilient.

Reverse DNS

A reverse DNS lookup is a DNS query for the domain name associated with a given IP address. This accomplishes the opposite of the more commonly used forward DNS lookup, in which the DNS system is queried to return an IP address. The process of reverse resolving an IP address uses PTR records. If the server does not have a PTR record, it cannot resolve a reverse lookup.

Reverse lookups are commonly used by email servers. Email servers check and see if an email message came from a valid server before bringing it onto their network. Many email servers will reject messages from any server that does not support reverse lookups or from a server that is highly unlikely to be legitimate.

Note: Reverse DNS lookups are not universally adopted as they are not critical to the normal function of the internet.

Does all Internet traffic go through the root servers?

No. By design, the DNS uses local caching, so other parts of the DNS system query the root servers only periodically to update their caches. Anyway, this process is only about translating a domain name to an address. Once that’s done the routing system – which is totally separate – does the rest.

But do the root server operators have a say in which new TLDs get added?

The root server operators have no more influence on new TLDs than any other member of the global Internet community. As providers of essential DNS infrastructure, the root server operators – as members of the Root Server System Advisory Committee (RSSAC) – can and do give specialist advice to the ICANN Board about the technical implications of policy developments, but they have no special voice about the specifics of any proposed new TLD.

Are there any parts of the world that do not yet have good service?

It would be misleading to say that any country or region is underserved by the DNS. That said, there are few instances of the root servers in central and northern Africa, western China, and Russia. In general though, the number of root servers says more about physical infrastructure and national regulatory policies in the area than it does about the willingness of operators to set up new sites. Several operators – including Netnod – are always happy to discuss new sites when the local conditions are right.

I want to learn more!

Daniel Karrenberg of the RIPE NCC (the operator of the K root server) has written an excellent document, “The Internet Domain Name System Explained for Non-Experts”, which is available on the Internet Society site (link below). Karrenberg’s document is from some time ago and so some details are now out of date. However, it still provides a clearly explained and useful overview of the DNS and root server system.

• The Internet Domain Name System Explained for Non-Experts

Other good starting points:

• IANA’s Root Zone Management Overview page

• ICANN’s RSSAC page

• Root Server Technical Operations site

Query Types

There are three types of queries in a DNS system:

Recursive

In a recursive query, a DNS client requires that a DNS server (typically a DNS recursive resolver) will respond to the client with either the requested resource record or an error message if the resolver can’t find the record.

Iterative

In an iterative query, a DNS client provides a hostname, and the DNS Resolver returns the best answer it can. If the DNS resolver has the relevant DNS records in its cache, it returns them. If not, it refers the DNS client to the Root Server or another Authoritative Name Server that is nearest to the required DNS zone. The DNS client must then repeat the query directly against the DNS server it was referred.

Non-recursive

A non-recursive query is a query in which the DNS Resolver already knows the answer. It either immediately returns a DNS record because it already stores it in a local cache, or queries a DNS Name Server which is authoritative for the record, meaning it definitely holds the correct IP for that hostname. In both cases, there is no need for additional rounds of queries (like in recursive or iterative queries). Rather, a response is immediately returned to the client.

How to Obtain Internet Server Information

The nslookup command is used to query your DNS server on Windows PCs.

nslookup lifewire.com

This command should return something like this:

Name: lifewire.com
Addresses: 151.101.2.114 
 151.101.66.114
 151.101.130.114
 151.101.194.114

In the example above, the nslookup command tells you the IP address, or several IP addresses in this case, that the lifewire.com address translates to.

The Purpose of DNS Servers

The DNS server sits in the space between humans and computers to help facilitate their communication.

It’s easier to remember a domain or hostname like lifewire.com than it is to remember the site’s IP address numbers 151.101.2.114. So when you access a website, like Lifewire, all you have to type is the URL https://www.lifewire.com.

However, computers and network devices don’t work well with domain names when trying to locate each other on the internet. It’s far more efficient and precise to use an IP address, which is the numerical representation of what server in the network (internet) the website resides on.

Subdomains

A subdomain is an additional part of our main domain name. It is commonly used to logically separate a website into sections. We can create multiple subdomains or child domains on the main domain.

For example, blog.example.com where blog is the subdomain, example is the primary domain and .com is the top-level domain (TLD). Similar examples can be support.example.com or careers.example.com.

Protecting Yourself From DNS Attacks

There are two things you should do to avoid becoming a victim of a DNS settings attack. The first is to install antivirus software so that malicious programs are caught before they can do any damage.

The second is to pay close attention to the appearance of important websites you visit regularly. If you visit one and the site looks off in some way—maybe the images are all different or the site’s colors have changed, or menus don’t look right, or you find misspellings (hackers can be dreadful spellers)—or you get an «invalid certificate» message in your browser, it might be a sign that you’re on a faked website.

How DNS Redirection Can Be Positively Used

• How do I find the best DNS server for my area?

  To test different DNS servers, use a benchmarking tool like GRC DNS Benchmark for Windows and Linux or Namebench for Mac. In some situations, you can significantly increase your internet speed by switching DNS servers.

• How do I fix the ‘DNS Server Not Responding’ error?

  If you see the DNS Server Not Responding error, clear the DNS cache and run Windows Network Troubleshooter. If you recently installed antivirus software, temporarily disable it to see if that helps. If that doesn’t solve the problem, try switching DNS servers.

• How do I clear the DNS cache on Windows?

  Open Command Prompt and enter ipconfig /flushdns to clear the DNS cache. You can clear the cache in Microsoft PowerShell with the Clear-DnsClientCache command.

• Why are there only 13 DNS root name servers?

  DNS uses 13 root name servers due to the limitations of Internet Protocol version 4 (IPv4). The number 13 was chosen as a compromise between network reliability and performance.

Thanks for letting us know!

Get the Latest Tech News Delivered Every Day

Server types

Now, let’s look at the four key groups of servers that make up the DNS infrastructure.

DNS Resolver

DNS root server

A root server accepts a recursive resolver’s query which includes a domain name, and the root nameserver responds by directing the recursive resolver to a TLD nameserver, based on the extension of that domain (.com, .net, .org, etc.). The root nameservers are overseen by a nonprofit called the Internet Corporation for Assigned Names and Numbers (ICANN).

There are 13 DNS root nameservers known to every recursive resolver. Note that while there are 13 root nameservers, that doesn’t mean that there are only 13 machines in the root nameserver system. There are 13 types of root nameservers, but there are multiple copies of each one all over the world, which use Anycast routing to provide speedy responses.

TLD nameserver

Management of TLD nameservers is handled by the Internet Assigned Numbers Authority (IANA), which is a branch of ICANN. The IANA breaks up the TLD servers into two main groups:

• Generic top-level domains: These are domains like .com, .org, .net, .edu, and .gov.
• Country code top-level domains: These include any domains that are specific to a country or state. Examples include .uk, .us, .ru, and .jp.

Authoritative DNS server

The authoritative nameserver is usually the resolver’s last step in the journey for an IP address. The authoritative nameserver contains information specific to the domain name it serves (e.g. google.com) and it can provide a recursive resolver with the IP address of that server found in the DNS A record, or if the domain has a CNAME record (alias) it will provide the recursive resolver with an alias domain, at which point the recursive resolver will have to perform a whole new DNS lookup to procure a record from an authoritative nameserver (often an A record containing an IP address). If it cannot find the domain, returns the NXDOMAIN message.

How DNS works

1. A client types example.com into a web browser, the query travels to the internet and is received by a DNS resolver.
2. The resolver then recursively queries a DNS root nameserver.
3. The root server responds to the resolver with the address of a Top Level Domain (TLD).
4. The resolver then makes a request to the .com TLD.
5. The TLD server then responds with the IP address of the domain’s nameserver, example.com.
6. Lastly, the recursive resolver sends a query to the domain’s nameserver.
7. The IP address for example.com is then returned to the resolver from the nameserver.
8. The DNS resolver then responds to the web browser with the IP address of the domain requested initially.

Once the IP address has been resolved, the client should be able to request content from the resolved IP address. For example, the resolved IP may return a webpage to be rendered in the browser

Examples

These are some widely used managed DNS solutions:

This article is part of my open source System Design Course available on Github.

Records Types

DNS records (aka zone files) are instructions that live in authoritative DNS servers and provide information about a domain including what IP address is associated with that domain and how to handle requests for that domain.

These records consist of a series of text files written in what is known as DNS syntax. DNS syntax is just a string of characters used as commands that tell the DNS server what to do. All DNS records also have a «TTL», which stands for time-to-live, and indicates how often a DNS server will refresh that record.

There are more record types but for now, let’s look at some of the most commonly used ones:

• A (Address record): This is the record that holds the IP address of a domain.
• AAAA (IP Version 6 Address record): The record that contains the IPv6 address for a domain (as opposed to A records, which stores the IPv4 address).
• CNAME (Canonical Name record): Forwards one domain or subdomain to another domain, does NOT provide an IP address.
• MX (Mail exchanger record): Directs mail to an email server.
• TXT (Text Record): This record lets an admin store text notes in the record. These records are often used for email security.
• NS (Name Server records): Stores the name server for a DNS entry.
• SOA (Start of Authority): Stores admin information about a domain.
• SRV (Service Location record): Specifies a port for specific services.
• PTR (Reverse-lookup Pointer records): Provides a domain name in reverse lookups.
• CERT (Certificate record): Stores public key certificates.

Who are the root server operators?

They are a diverse group of organisations from the private enterprise, non-profit, education, and military sectors. Each of these operators assumed their role in the early days of the DNS (with the exception of the C-root, which passed to the company that acquired the network of the original operator). They are:

• A VeriSign Global Registry Services
• B University of Southern California, Information Sciences Institute
• C Cogent Communications
• D University of Maryland
• E NASA Ames Research Center
• F Internet Systems Consortium, Inc.
• G US DoD Network Information Center
• H US Army Research Lab
• I Netnod
• J VeriSign Global Registry Services
• K RIPE NCC
• L ICANN
• M WIDE Project

How do root servers work?

Root servers contain the root zone, as discussed above. WIthin this root zone are the records which help answer the client queries. You can actually see a full list of these records, kept by IANA here.

Without the root DNS servers, the Internet would no longer function. The diagram below shows that every time a client makes a query, unless that information has already been cached, it will start with the root servers. Simply put, every time you enter a URL in your browser, a root server will be integral to you getting to your destination.

What if a root server operator stops operating?

The question of succession is an open and important issue. For example, in 2002 Cogent took over the responsibility for the C-root server when it bought up the assets of the previous operator, PSINet. Despite that, there remains no defined process for how to replace an existing operator with a new one, and it’s a question that the community does need to consider. But it is worth noting that, from a technical perspective, the disappearance of an entire operator is not a particularly big deal. For example, if F were to be completely turned off today, there would still be more than 300 other servers to carry the load.

Is it true that there are only 13 root servers?

No, not for a long time. The size of UDP data packets means that there’s only room to include the IP addresses of 13 root servers in a single packet. Originally that meant a limit of 13 root server machines, and it gives us the root server names A-M. But thanks to the anycasting technique, each root server address can be mirrored on multiple physical servers in multiple diverse locations. By early August 2014, there were 372 root servers spread across the globe. You can check the up-to-date numbers and locations here: http://www.root-servers.org.

Primary and Secondary DNS Servers

In most cases, a primary and a secondary DNS server are configured on your router or computer when you connect to your internet service provider. There are two DNS servers in case one of them happens to fail, in which case the second is used to resolve hostnames you enter.

How many DNS Root Server are there?

There are hundreds of root servers at various locations all over the globe. However, many times, people will believe there are only 13. This was a limitation of IPv4 addresses originally, and we only had one server for each IPv4 address represented in the table below. However, we now have clusters set up to ensure uptime and performance of the Internet, specifically DNS queries. Each of the hosts/IP addresses below actually have a server cluster behind it.

List of Route Servers

Why You Might Change Your DNS Server Settings

Some DNS servers can provide faster access times than others. This is often a function of how close you are to those servers. If your ISP’s DNS servers are closer to you than Google’s, for example, you may find domain names are resolved quicker using the default servers from your ISP than with an external server.

If you experience connection problems where it seems no websites will load, it’s possible there’s an error with the DNS server. If the server isn’t able to find the correct IP address that’s associated with the hostname you enter, the website can’t be located and loaded.

Some people choose to change their DNS servers to ones provided by a company they consider more trustworthy; e.g., one that promises not to track or record the websites you visit.

A computer or device, including smartphones and tablets, connected to your router can use a different set of DNS servers to resolve internet addresses. These will supersede those configured on your router and will be used instead.

OK, but A is the most important root server, isn’t it?

Nope. The lettered names are entirely arbitrary. Every one of the 372 root servers contains and serves exactly the same root zone. That’s the point. And they all get the root zone through a distribution infrastructure that is separate from the named root servers. 

How Root Servers Work

1. The client asks the DNS server that it’s configured to go to for help getting to a particular destination.
2. If the recursive DNS server doesn’t have that information cached it will go to the root server to see which TLD to go to.
3. The recursive DNS server then checks with the appropriate TLD, which directs it to the authoritative name server.
4. The authoritative name server will have the correct IP associated with the domain name and will pass that along to the recursive DNS server.
5. The recursive DNS server will cache that information for a certain period of time, according to the configured TTL (Time-to-Live).
6. The client will now have the information it needs to contact the destination domain name via the IP address.

DNS Root Servers

There are 13 important DNS root servers on the internet that store a complete database of domain names and their associated public IP addresses. These top-tier DNS servers are named A through M for the first 13 letters of the alphabet. Ten of these servers are in the US, one in London, one in Stockholm, and one in Japan.

The Internet Assigned Numbers Authority (IANA) keeps this list of DNS root servers if you’re interested.

Does the root zone contain all the DNS data?

No. The root servers serve the root zone, which contains information about what Top Level Domains (TLDs) exist, and the addresses of the authoritative DNS servers for each TLD. DNS clients and other servers query the root servers for the TLD information, then go to the appropriate server for details of the domains within that TLD.

As a root server operator, can Netnod control the content of the root zone?

No. The content of the root zone is determined as part of the IANA function, subject to ICANN’s policy development processes, and is currently maintained by Verisign. Furthermore, the root zone file is digitally signed (using DNSSEC).

This seems all very reassuring, but how transparent are root server operations?

For anyone’s who’s interested, a lot of public information is available at http://root-servers.org. Furthermore, operators participate in many public conferences and the RSSAC meets during ICANN meetings. Minutes of RSSAC meetings (including teleconferences) are publicly available on the ICANN website. Obviously there are some specific operational details that cannot be made public for security reasons, but apart from that, information about root servers and the DNS is very accessible.

DNS Caching

A DNS cache (sometimes called a DNS resolver cache) is a temporary database, maintained by a computer’s operating system, that contains records of all the recent visits and attempted visits to websites and other internet domains. In other words, a DNS cache is just a memory of recent DNS lookups that our computer can quickly refer to when it’s trying to figure out how to load a website.

The Domain Name System implements a time-to-live (TTL) on every DNS record. TTL specifies the number of seconds the record can be cached by a DNS client or server. When the record is stored in a cache, whatever TTL value came with it gets stored as well. The server continues to update the TTL of the record stored in the cache, counting down every second. When it hits zero, the record is deleted or purged from the cache. At that point, if a query for that record is received, the DNS server has to start the resolution process.