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 post, Netnod Senior Systems Specialist Lars-Johan Liman explains the challenges of operating one of these servers.
The importance of root servers
The root servers provide access to the DNS root zone, which is the entry point to the entire DNS system. That means that a root server can always direct a client to the next step in the resolution process by referring it to a server at a lower level in the DNS tree; or, in many cases, authoritatively declare that the domain name a user entered doesn’t exist.
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 the smooth operation of the Internet as a whole.
Ensuring the stability of the root service
Ensuring the stability and accuracy of the root service is one of Netnod’s 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:
- Server stability: We use the anycast technology, which allows a large number of servers, connected at various points on the global Internet, to share the same IP address. The routing system on the Internet will ‘automagically’ lead DNS traffic from a client to the nearest of our servers. If one of our servers breaks, we can easily remove it from the network, and the routing system will ‘heal’ by itself, redirecting the same traffic to another one of our sites. We also use dual systems in all critical parts of the provisioning process.
- Service reachability: 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.
- Software diversity: 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.
- Policy stability: Netnod’s staff actively participate in all relevant forums 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.
- Financial stability: 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 subsidized 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:
- 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.
- 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.
The roles of root server operators
The root server operators work independently of each other and of any parent organization. Each organization 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 that receives the root zone file on one side, and provides DNS service on the other. The root zone file is given — and is identical for all root servers — and the service is prescribed in the documents. The flexibility sits inside the box.
Since all root operators have their own designs, there is a fair bit of diversity between them, and this is good: should one design turn out to be flawed and not function well, there are 11 other designs that maintain service while the flawed one is being mended. [Note: The careful reader may wonder why there are 13 root name servers, and only 12 operators. This is explained by the historic fact that one specific operator operates two servers — A and J.].
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.
The challenges in operating a root server
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 distant locations, and having remote hands, who 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.
Improving the root service
One obvious way to improve the root service 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.
This post was first published as a Q&A on the Netnod blog.
Lars-Johan Liman is Senior Systems Specialist and leader of Netnod’s root-server efforts.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.