GoDaddy Hosts DNS B Root Instances
About this Blog Post
This blog explains the DNS Root Servers and how GoDaddy is contributing by hosting B Root instances. It also provides a background of the Domain Name System (DNS) as a hierarchy. Lastly, this blog discusses the root of that hierarchy to help provide context for the various root server identities and independent operations, and to give a frame of reference for the discussion about the B Root servers.
What is the Domain Name System?
The Domain Name System (DNS) is both a protocol, and a distributed database of information concerning hosts and services on the public Internet. DNS has scaled extremely well, handling the growth of the Internet for the last 35 years.
The database side of DNS is a hierarchical system, forming a decentralized database of Internet information. Conceptually, it forms a tree with a single root, where every node below the root has a label with only local significance.
When a particular node is operated by a different entity than the node above it in the hierarchy, the two nodes form a “parent-child” relationship. The parent provides information about the name and location (IP address) of the child, which indicates that the child is the “source of truth” for that branch of the DNS tree. There is no functional limitation (beyond a maximum size of a DNS name) on the number of levels in this hierarchy. The parent and child each have their own address, and being independent is what makes the DNS database decentralized. This independence also improves scalability, by placing most of the important information at the “leaf” nodes of the DNS tree, and facilitating both horizontal and vertical scaling approaches (adding levels, and adding capacity at each level on each independent “branch” of the DNS tree.)
DNS was originally specified in the standards published by the IETF, as RFC882 and RFC883, and later updated as RFC1033, RFC1034, and RFC1035.
How does DNS resolution actually work?
Client systems make use of intermediaries known as “resolvers”, which do the bulk of the “look-up” work in DNS, and which implement caching to avoid duplication of look-ups. The actual data in the DNS is hosted on what are known as “authoritative” servers. Since the name space for DNS is hierarchical, each level of the hierarchy only needs to serve/maintain information about the next level down in the “tree” of names.
When any application wants to connect to a host, such as www.example.com, it asks the local operating system to look up that name. The local system then sends a request to (one of) the configured DNS resolver(s) and waits for the response, which will be an IP address that will be used to access the desired resource. The resolver checks its cache for helpful answers, and whenever it does not find the information it needs, talks to the corresponding authoritative DNS servers to get what it requires. If the resolver can’t find cached answers, it needs to “walk down” the DNS tree, starting at the “root” of the tree.
What are the Root Servers?
If a resolver wants to find the DNS data for www.example.com, but does not have any relevant cached data, it starts with the “root” servers, who tell it where to find the “com” top-level domain servers.
The root servers are a set of 13 identities that can each be reached on an IPv4 and an IPv6 address. DNS servers are necessary for resolvers to “boot-strap” the entire resolution process.
The IP addresses are generally hard-coded into the DNS resolver software, and refreshed whenever these servers start up.
What is B Root?
The servers are named according to an alphabetic letter in the range “a” through “m”. These names are in the “root-servers.net” zone, and thus are “a.root-servers.net”, “b.root-servers.net”, etc.
The performance of only 13 actual servers for a global Internet would obviously be very limited, and potentially exposed to Denial of Service (DoS) attacks, as well as having challenges supporting an ever-growing Internet. The operators of these root servers have solved these issues by deploying their servers in a large number of locations, and in many of these as “clusters” of servers, all while using their single respective IPv4 and IPv6 address. The term for this technique is “anycast”. The network on which each root server operates, is announced independently from each location. Third party networks select the topologically closest instance from all available sites, which provides several benefits:
- The closest server will have the shortest round-trip time (generally speaking)
- Each location’s collective load is generally consistent, allowing each operator to grow their capacity in a predictable, organic fashion
- DoS attacks which originate regionally, do not affect other locations
- Server and site redudancy is handled automatically by network routing protocols
- Availability and performance are both maximized
- No central orchestration is required – each site is independent, and selection between sites is done by third parties, not the operators themselves.
Why does GoDaddy host B Root instances?
As stated in the Memorandum of Agreement (MOA), “In recognition that GoDaddy and USC/ISI have a common interest in improving public Internet infrastructure, they mutually propose to host instances of B-Root in GoDaddy’s networking facilities.”
Why Does DNS Need So Many Root Servers?
There are several reasons that the DNS root is operated by several organizations.
The first reason is trust. The organizations themselves are independent, meaning they are not directly or indirectly affiliated. This improves the trust in the root system itself since it is not possible for any single organization to alter the contents of the root zone unilaterally. Any tampering by one of the operators would be visible to any third party by comparing the contents against any of the other operator’s instances.
The second reason is reliability. Errors in operation that impact all of the instances of one operator’s root servers, are unable to cause problems to the other operators’ systems. This functional independence is a critical part of the design of the root of the DNS.
The third reason is availability. As long as a single instance of one of the root operators’ servers is reachable and able to provide responses, the root zone itself is available. While each operator works to maximize its own availability, the combination of all of the operators’ instances, provides an extremely robust system as a whole.
Things That Work Better With Lots Of Root Servers
Each root server operator is independent. Thus, each makes its own decisions on how many instances to deploy, what capacity to provide, and where to put their systems. The benefit to resolvers is that with 13 different root servers to choose from, there is a very good chance that one or more will be close by. This improves performance, including delay (round trip time) and capacity (by avoiding more expensive and potentially more congested long-haul network links).
Root server instances that are geographically diverse, also improve availability in the cases of major network outages, such as those caused by natural disasters. If the long-haul capacity for an entire region is all disrupted simultanously, the presence of in-region root servers ensures the impact to local domains is minimized.
The more servers there are, and the more capacity on aggregate for each there is, the harder it is for attackers to succeed in disrupting DNS as a whole. It would be necessary to disrupt every instance reachable from any particular location to prevent the root servers from being able to provide service. Since the service provided by each is identical, the availability of even one server is sufficient to survive such a DoS attack.
The analogies that come closest to describing the benefits of this redundancy and independence, are those for safety devices. For example, in an automobile, there are a number of systems that are considered safety-critical, where their failure could put the occupants at risk of harm. Generally speaking, there are safety-specific components that provide protection in case of system failures, which are themselves backed up by other safety systems. Only if all of those systems fail simultaneously is harm to the occupant a likely outcome. For collisions, there are any number of such systems: steering wheels, brakes, intelligent self-braking, crumple zones, seat belts, air bags, collapsible steering wheels, safety glass, crash cages, and more. Any single one of those can be a life-saving device, even if ALL of the other systems failed.
Another analogy would be for large cruise ships, where a number of safety devices are provided, normally with each dedicated to one person or to a small number of passengers. Those include life jackets, rescue rings (life rings), life boats, inflatable emergency lifeboats, etc. If someone were to maliciously tamper with these, the impact to any single passenger would depend on whether THEIR life jacket, and THEIR life boat, and so on, were affected. If not, the passenger would be safe from harm in the event of a catastrophic accident.
The root server system works the same way. The geographic redundancy provided by “anycast” ensures that the impact of single outages to a single root server are localized. The diversity among root server instances works orthogonally, whereby only if all local instances of all root servers were impacted, would a particular set of users even notice a problem. In addition to all of those redundancies, the DNS system makes heavy use of caching, so that the vast majority of DNS queries are answered from caches, and temporary availability impacts are further minimized.
Conclusion
The DNS Root servers are critical Internet infrastructure, and operating them correctly is an important community service.
By hosting several B Root Server instances, GoDaddy is committing to improving this service, for the benefit of itself, its own customers, and the greater Internet community.
The actual operation of B Root Servers is by USC/ISI, an independent organization, where GoDaddy is a hands-off partner providing the infrastructure to be operated independently by the team managing the B Root service.
About the Author
Brian Dickson is a member of the DNS team at GoDaddy. This team is responsible for all internal and exteral DNS, including our DNS product (hosted authoritative DNS services), our corporate DNS domains (authoritative), and internal DNS resolution.
