What is DNS (Domain Name System)?

Often called the “phonebook for the internet,” a more modern analogy is that DNS manages domain names like a smartphone manages contacts. Smartphones eliminate the need for users to remember individual phone numbers by storing them in easily searchable contact lists.

Likewise, DNS enables users to connect to websites by using internet domain names instead of IP addresses. Rather than having to remember the web server is at “192.0.2.1,” for instance, users can simply go to the webpage “www.example.com” to get their wanted results.

To understand how DNS works, it’s important to first understand the components involved.

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 website. 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 period 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.

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 nameserver “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.

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.

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).

In addition to the major server types, the DNS uses zone files and several record types to help with the resolution process. Zone files are text-based files that include mappings and information about specific domains within a DNS zone.

Each line of a zone file specifies a DNS resource record—a single piece of information about the nature of a particular type or piece of data. The resource records help ensure that when a user submits a query, the DNS can quickly convert domain names into actionable information that directs queries to the correct server.

DNS zone files start with two mandatory records: the name server (NS) record—which indicates the authoritative name server for a domain—and the start of authority (SOA) record—which specifies the primary authoritative name server for the DNS zone.

After the two primary records, a zone file can contain several other record types. They include:

Every query (sometimes called a DNS request) follows the same logic to resolve IP addresses. There are different ways in which queries are initiated—as a common example, let’s consider a person using a web browser.

When the user enters a URL into their web browser, the browser sends the query to the DNS resolver, which progressively queries authoritative DNS servers to locate the authoritative name server that holds the domain’s records, including the associated IP address. The IP address is returned to the browser, and the user is connected to the website.

More specifically, query resolution in the DNS involves several key processes and components

• Query initiation. 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.

• Recursive resolver. 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.

• Root name 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).

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

• Domain name server. 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.

• Query resolution. 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. Public and private DNS are not necessarily exact, universally used and understood terms and concepts, and their use is often imprecise.

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.

The use of “private DNS” is even fuzzier. It 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, there is a local recursor that queries local, private authoritative servers for internal requests, and relies on the standard DNS for external queries. Usually there is a list of domain names, a sort of “allow list”, that tells the server which requests go to internal servers and which to forward to the public internet.

Managed DNS is a third-party service that enables an organization to outsource the hosting, operation and management of their DNS infrastructure. With managed DNS, the authoritative DNS records for an organization’s domains are hosted on the provider’s globally distributed network of servers. In many cases, managed DNS providers offer a central control plane, dashboard or APIs that enable clients to manage and automate their DNS records and other settings.

Managed DNS services often provide features such as Anycast routing, load balancing, uptime service level agreements (SLAs), failover protection, DNSSEC and monitoring and troubleshooting tools that can enable faster, more reliable, more secure domain resolution than traditional self-managed DNS setups.

Even the best DNS systems can be vulnerable to cybersecurity issues. DNS-related attacks include:

DNS spoofing, also called cache poisoning, occurs when an attacker inserts false address records into a DNS resolver’s cache, causing the resolver to return an incorrect IP address and redirect users to malicious sites. Spoofing can compromise sensitive data and lead to phishing attacks and malware distribution.

DNS amplification is a type of DDoS attack where an attacker sends small queries to a DNS server with the return address spoofed to the victim’s IP address. These attacks exploit the stateless nature of DNS protocols and leverage the fact that a small query can generate an outsized response.

As a result of an amplification attack, the DNS server responds with much larger replies, which amplifies the amount of traffic directed at the user, overwhelming their resources. This can prevent DNS from working and bring down the application.

DNS tunneling is a technique used to bypass security measures by encapsulating non-DNS traffic, like HTTP, within DNS queries and responses. Attackers can use DNS tunnels to relay malware commands or to exfiltrate DNS information from a compromised network, often encoding the payload within DNS queries and responses to avoid detection.

Neglected DNS entries for subdomains that point to decommissioned services are prime targets for attackers. If a service (like a cloud host) has been decommissioned but the DNS entry remains, an attacker can potentially claim the subdomain and set up a malicious site or service in its place.

Regardless of which DNS services an organization chooses, it’s important to implement security protocols to minimize DNS attack surfaces, mitigate potential security issues and optimize the DNS in networking processes. Some useful practices for solidifying DNS security include:

• Deploying DNS security extensions (DNSSECs). DNSSEC adds a layer of security to DNS lookups by requiring DNS responses to be digitally signed. DNSSEC can protect against DNS spoofing attacks by authenticating the origin of requests and verifying the integrity of DNS data.

• Employing rate limiting practices. Rate limiting on DNS servers can mitigate DDoS attacks by restricting the number of responses—or the rate at which servers send responses—to a single requester in a specified time period.

• Requiring two-factor authentication (2FA) for domain registrars. Establishing 2FA for domain registrar accounts can make it more difficult for attackers to gain unauthorized access to servers and reduce the risk of domain hijacking.

• Using redundancies. Deploying the DNS in a redundant configuration across several geographically dispersed servers can help ensure network availability if there is an attack or outage. If the primary server goes down, secondary servers can take over DNS resolution services.

• Implementing DNS flushing. Clearing the DNS cache removes all entries from the local network, which can be useful for deleting invalid or compromised DNS records that might direct users to malicious sites. Generally, this is an on-demand service provided by the resolver operator. Otherwise, caches are cleared with TTLs expire.
  
  
• Staying informed about DNS threats. Attackers and security threats evolve in much the same way as the systems they compromise. Staying abreast of the latest DNS vulnerabilities and threats can help teams stay ahead of bad actors.

Before DNS, the internet was a growing network of computers primarily used by academic and research institutions. Developers manually mapped hostnames to IP addresses using simple text files called HOSTS.TXT, which were maintained by SRI International and distributed to every computer on the internet. However, as the network expanded, this approach became increasingly untenable.

To address the limitations of HOSTS.TXT and create a more scalable system, University of Southern California computer scientist Paul Mockapetris invented the domain name system in 1983. The cohort of internet pioneers who helped create the DNS also authored the first request for comments (RFCs) that detailed the new system’s specifications, RFC 882 and RFC 883. RFC 1034 and RFC 1035 later superseded the earlier RFCs.

Eventually, as the DNS expanded, DNS management became the responsibility of the Internet Assigned Numbers Authority (IANA), before ultimately landing under the control of the nonprofit, Internet Corporation for Assigned Names and Numbers (ICANN), in 1998.