What is a DNS server?

They form the foundation of the Domain Name System (DNS), often referred to as the “phone book of the internet,” enabling users to access websites by entering domain names into a web browser instead of recalling and entering numerical IP addresses.

DNS comprises two types of DNS servers: recursive DNS servers—also called recursive resolvers, DNS resolvers or DNS recursors—and authoritative name servers, which include root name servers, top-level domain (TLD) name servers and second-level domain name servers.

Recursive DNS servers do the “asking,” locating the DNS records with the information needed to connect a client to a website or resource, and authoritative servers hold these records, and provide the “answers.” Together, these servers are responsible for the DNS resolution process, translating the human-readable domain names into computer-friendly, numerical internet protocol (IP) addresses.

For example, when a user enters a hostname (such as www.example.com) into a web browser, they initiate a DNS query—also called a DNS request—and start the DNS lookup process. The browser sends the query to the configured recursive resolver, which progressively queries authoritative DNS servers to locate the appropriate resource records to address the user’s request.

This process continues until the resolver finds the authoritative name server associated with that domain, along with the A (or AAAA record, for IPv6 addresses) that contains the correct IP address for the domain. The resolver returns the IP address to the browser, and the user is connected to the resource they are looking for.

DNS servers are the essential infrastructure that enables DNS and the internet to function as users are accustomed.

DNS servers both locate and store DNS records and drive the resolution of DNS queries as they move through the hierarchical structure of the DNS. The highest level comprises DNS root name servers, which direct queries to the appropriate top-level domain servers and then to second-level domain name servers, which hold the authoritative records for a given domain.

There are many types of DNS records, and they serve as a sort of database of instructions on where resources are located, in addition to other critical DNS information. The most familiar example might be A records (for IPv4 IP addresses, or AAAA records, for IPv6 addresses) that contain the IP addresses that browsers need to help users reach the websites they are searching for.

But there are also MX records that direct to a domain’s mail server, CNAME records that direct alias domains to canonical domains, DNAME records that are used to redirect multiple subdomains with one record and point them to another domain, and more.

These records are hosted on authoritative DNS servers, and for DNS to function, these servers must remain healthy and secure. Without functioning DNS servers, there is no DNS.

From the outset, DNS was designed with a hierarchical, distributed database structure to facilitate a more dynamic approach to domain name resolution, one that can keep pace with a rapidly expanding network of computers. The hierarchy starts with the root level—denoted by a dot (.)—and branches out into top-level domains (TLDs)—such as “.com,” “.org,” “.net” or country code TLDs (ccTLDs) such as “.uk” and “.jp,”—and second-level domains.

DNS architectures consist of two types of DNS servers: recursive servers and authoritative servers. Recursive DNS servers are the ones doing the “asking,” searching for the information that connects a user to a web page or resource. Authoritative servers provide the “answers.”

Recursive servers—also known as recursive resolvers or DNS resolvers—are typically managed by internet service providers (ISPs) or third-party DNS service providers. An organization can also host and manage their own resolver.

Recursive resolvers act on behalf of the end user to resolve the domain name into an IP address. Recursive resolvers also cache (temporarily store the results of recent DNS lookups) the answers to a request for a specific amount of time (defined by the time-to-live, or TTL, value) to improve system efficiency for future queries to the same domain.

When a user types a web address into a web browser, the browser connects to a recursive DNS server to resolve the request. If the recursive server happens to have the answer cached, it can connect the user and complete the request. Otherwise, the recursive resolver queries the DNS hierarchy until it finds the A (or AAAA) records containing the IP address for a given domain.

Authoritative name servers hold the definitive records for a domain and respond to requests about domain names stored within their respective zones (typically with answers configured by the domain owner). There are different authoritative servers that are each responsible for a distinct part of the namespace.

Authoritative DNS name servers include:

Root name servers

Root name servers sit at the top of the DNS hierarchy and are responsible for serving the root zone (the central database for the DNS). There are 13 root name server “identities” or “authorities” (logical groupings of root servers) identified by letters A through M. They answer queries for records stored within the root zone and refer requests to the appropriate TLD name server.

Top-level domain (TLD) name servers

TLD servers are responsible for managing the next level of the hierarchy, including generic top-level domains (gTLDs). TLD name servers direct queries to the authoritative name servers for the specific domains within their TLD. So, the TLD name server for “.com” would direct domains ending in “.com,” the TLD name server for “.gov” would direct domains ending in “.gov,” and so on.

Other domain name servers

Second-level domain name servers—the majority of domain name servers—hold zone files with the IP address for the full domain name (“ibm.com,” for instance).

DNS servers are the infrastructure upon which the DNS system is built, and the components that power its core function—connecting users with internet resources. Authoritative DNS servers store DNS records and recursive servers query these authoritative servers to find the records needed to complete a DNS request.

DNS query resolution involves several key processes and components:

A user enters a domain name, such as “ibm.com,” into a browser or app. If the IP address for the site in question is not in the browser’s cache, the request is sent to a recursive DNS resolver. Typically, the user’s device has predefined DNS settings, provided by the ISP, that determine which recursive resolver receives the request.

This process is evolving, as many modern browsers support DNS over HTTPS (DoH), which enables DNS lookup over HTTPS, and many providers have servers set up for this type of look up. For example, if you use Firefox in the United States, it will by default send the query to a Cloudflare DoH server instead of the local ISP provider’s resolver. DoH is becoming more popular because it offers increased privacy and better performance and other benefits.

The recursive resolver checks its own cache for the domain’s corresponding IP address. If the recursive resolver does not have the necessary records in its cache, it initiates the lookup process, starting at the root server.

The recursive resolver queries a root name server, which responds with a referral to the appropriate TLD server for the domain in question (the TLD name server responsible for “.com” domains, in this instance).

The resolver queries the “.com” TLD name server, which responds with the address of the authoritative name server for “ibm.com.”

The resolver queries the domain’s name server, which looks up the DNS zone file and responds with the correct record for the provided domain name.

The recursive resolver returns the IP address to the user’s device. The browser or app can then initiate a connection to the host server at that IP address and access the requested website or service. The browser and resolver cache records in accordance with their respective configurations and TTLs.

DNS is basically a public protocol. Though the terms “public DNS” and “private DNS” are used in different ways, without a universally standard definition for either, they are often used to refer to do distinct infrastructure configurations and processes. The greatest difference is in their intended use and audience.

Public DNS is often used to refer to the “standard” DNS resolution process, or public DNS resolvers, wherein a recursive resolver queries a succession of authoritative servers that hold publicly available DNS records to locate an IP address and ultimately connect a user with the website they are looking for. Often this is a resolver provided by the user’s ISP or by a DNS service like Google’s “quad 8” Public DNS. Private resolvers can also be configured to query public DNS, but they are more commonly used for restricted or corporate networks.

This standard DNS lookup is likely referred to as public DNS because of these publicly available resolvers and the fact that the DNS records on these authoritative servers are accessible to anyone with internet access.

“Private DNS” is sometimes used to describe the use of encryption protocols such as DNS over TLS (DoT) or DNS over HTTPS (DoH). However, these are more accurately described as “privacy features” or “privacy protocols” rather than “private DNS.” The resolution process remains the same, in that a resolver uses the publicly available DNS to find what it needs. In this case, it’s just done with encrypted transfer.

Private DNS is also used to refer to lookup within a closed, internal network, such as corporate networks or virtual private clouds, with access restricted to authorized users. In such a system, private, locally configured resolvers query private servers to locate resources and sites within an internal network. These servers are configured to only serve private zones and internal IP addresses and the network keeps internal URLs and IP addresses hidden from the rest of the internet. This type of private DNS provides organizations with greater control and security.

There are many ways to configure this sort of network. One way is through a special-use domain such as “.local” that is used for resolution on local networks. Another is to have private subdomains of domains that are publicly available on the internet. This private subdomain would only be available to individuals or agents using resolvers within the internal network.

A common enterprise setup that combines both “public” and “private” DNS is called “split-horizon DNS,” or “split brain DNS.” In this configuration, a local recursor queries local, private authoritative servers for internal requests, and relies on the standard DNS for external queries. Split-horizon DNS typically includes a list of domain names (an “allowlist,” of sorts) that tells the server which requests go to internal servers and which to forward to the public internet.

In addition to anycast routing, load balancing, DNS traffic steering and real-time monitoring and troubleshooting capabilities, many managed DNS providers offer advanced security protections as part of their service. Whether an organization uses a managed DNS provider or self-manages their DNS infrastructure, securing DNS servers is an important part of keeping networks, and network resources, safe.

DNS security practices and protocols that help keep DNS servers protected and available include: