Published: 19 April 2024
Contributors: Chrystal R. China, Michael Goodwin
The Domain Name System (DNS) is the component of the internet standard protocol responsible for converting human-friendly domain names into the internet protocol (IP) addresses computers use to identify each other on the network.
Often called the “phonebook for the internet,” a more modern analogy is that DNS manages domain names in much the same way as smartphones manage contacts. Smartphones eliminate the need for users to remember individual phone numbers by storing them in easily searchable contact lists.
Likewise, the 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 “93.184.216.34,” for instance, users can simply go to the webpage “www.example.com” to get their wanted results.
Read how desktop as a service (DaaS) enables enterprises to achieve the same level of performance and security as deploying the applications on premises.
Before DNS, the internet was a growing network of computers primarily used by academic and research institutions. Developers manually mapped hostnames to IP addresses by using a simple text file called HOSTS.TXT. SRI International maintained these text files and distributed them to all computers 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. A cohort of internet pioneers assisted in the creation of DNS and 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.
Register for the guide on hybrid cloud
From the outset, developers designed the DNS 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)—like “.com,” “.org,” “.net,” or country code TLDs (ccTLDs) like “.uk” and “.jp,”—and second-level domains.
The DNS architecture consists 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.
Recursive servers—also known as recursive resolvers or DNS resolvers—are typically managed by internet service providers (ISPs), large enterprises or other third-party DNS service providers. They act on behalf of the end user to resolve the domain name into an IP address. Recursive resolvers also cache the answers to a request for a certain period (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 search 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 a series of authoritative DNS servers to find the IP address and connect the user to the wanted website.
Authoritative servers provide the “answers.” 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 types of authoritative name servers, each serving a specific function within the DNS hierarchy.
Authoritative DNS name servers include:
Root name servers sit at the top of the DNS hierarchy and are responsible for managing the root zone (the central database for DNS). They answer queries for records stored within the root zone and refer requests to the appropriate TLD name server.
There are 13 IP addresses used to query 13 different root server networks—identified by letters A through M—that handle requests for the TLDs and direct the queries to the appropriate TLD name servers. The Internet Corporation for Assigned Names and Numbers (ICANN) operates these root server networks.
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.
The domain name server (sometimes referred to as the second-level domain name server) holds the zone file with the IP address for the full domain name, such as “ibm.com.”
Every query (sometimes called a DNS request) in the DNS follows the same logic to resolve IP addresses. When a user enters a URL, their computer progressively queries DNS servers to locate the appropriate information and resource records to address the user’s request. This process continues until the DNS finds the right answer from the authoritative DNS server associated with that domain.
More specifically, query resolution in the DNS involves several key processes and components.
A user enters a domain name, such as “ibm.com,” into a browser or app and the request is sent to a recursive DNS resolver. Typically, the user's device has predefined DNS settings, provided by the internet service provider (ISP), that determine which recursive resolver a client queries.
The recursive resolver checks its cache—the temporary storage within a web browser or operating system (such as macOS, Windows or Linux) that holds previous DNS lookups—for the domain's corresponding IP address. If the recursive resolver does not have the DNS lookup data in its cache, the resolver initiates the process of retrieving it from the authoritative DNS servers, starting at the root server. The recursive resolver queries the DNS hierarchy until it finds the final IP address.
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.” This server is sometimes referred to as the second-level 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.
The recursive resolver caches the DNS record—for a time specified by the record's TTL—and 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 to access the requested website or service.
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 a domain 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 ensure that when a user submits a query, the DNS can quickly convert domain names into actionable information that directs users to the correct server.
DNS zone files start with two mandatory records: the global time to live (TTL)—which indicates how records should be stored in the local DNS cache—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, including:
A records map to IPv4 addresses and AAAA records map to IPv6 addresses.
MX records specify an SMTP email server for a domain.
CNAME records redirect hostnames from an alias to another domain (the “canonical domain”).
NS records indicate the authoritative name server for a domain.
PTR records specify a reverse DNS lookup, mapping IP addresses back to domain names.
TXT records indicate the sender policy framework record for email authentication.
DNS lookups typically involve three types of queries. Recursive queries, which connect the recursive server and the DNS client, either fully resolve the domain name or return an error message to the user, notifying them that it cannot locate the domain.
Iterative queries—which connect recursive resolvers (a local DNS server) and nonlocal DNS servers (like the root, TLD or domain name servers)—don’t require domain resolution. Instead, the servers might respond with a referral, where the root server refers the recursive resolver to the TLD, which refers the resolver to an authoritative server that provides the answer (if the answer is available). Therefore, iterative queries resolve with either an answer or a referral.
In the case of nonrecursive queries, the recursive resolver already knows where to locate the answer to the query, so these queries always resolve with an answer. The resolver saves time by either finding the answer cached on the recursive server or skipping the DNS root and TLD name servers to go directly to the appropriate authoritative server. If, for instance, the recursive resolver provides an IP address cached in a previous session, the request would qualify as a non-recursive query.
Organizations have a range of options when using the DNS, including public and private DNS, or a combination of two. Public and private DNS are two completely different things; to understand how to best use the DNS to meet organizational needs, it’s important to understand how each type functions.
Public DNS usually refers to the resolver side of DNS, and the recursive servers used to query authoritative name servers and connect users to websites.
These servers are accessible to any user on the internet and companies like Cloudflare (1.1.1.1), Quad9 and OpenDNS typically provide them free of charge. Public DNS servers are maintained by the organizations that run them. Users and clients have no control over their operation, policies or configuration.
Private DNS generally refers to the authoritative piece of the DNS. Organizations set up private DNS servers within a private network, and these servers act as the authoritative DNS servers, providing DNS lookup for internal resources. Private DNS servers reside behind a firewall and only hold records of internal sites, so access is restricted to authorized users, devices and networks.
Unlike public DNS configurations, private DNS offers organizations control over their DNS servers, allowing them to customize DNS records, apply internal naming schemes and enforce specific security policies. This also means that organizations are responsible for maintaining the infrastructure, whether it’s hosted in on-premises data centers or through cloud services.
Managed DNS solutions essentially outsource the server management and orchestration process. With a managed system, the DNS provider handles all the configuration, maintenance and security protocols for an organization’s DNS servers, and the client uses provider infrastructure to manage domain names. In this case, when a user enters a business’s URL, they’re redirected from the company domain name server to the provider’s servers, which fetch all the resources and respond to the user.
Managed DNS can also provide services and benefits such as dedicated DNS, global server load balancing, uptime guarantees, API-first architecture, DNSSEC support, global anycast networks, accelerated propagation times, monitoring and health check tools, DDoS protection and more.
Most modern DNS servers are quite secure, even in the case of public DNS. However, the best DNS systems can still be vulnerable to cybersecurity issues. Certain types of attacks target the authoritative side of DNS and while others target the recursive side. These 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 distributed denial-of-service (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 data from a compromised network, often encoding the payload within DNS queries and responses to avoid detection.
Domain hijacking occurs when an attacker gains unauthorized access to a domain registrar account and changes the registration details of a domain. Hijacking enables bad actors to redirect traffic to malicious servers, intercept emails and otherwise take control of the user’s online identity.
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 prudent to implement security protocols to minimize DNS attack surfaces, mitigate potential security issues and optimize DNS in networking processes. Some useful practices for solidifying DNS security include:
- Deploying DNS security extensions (DNSSECs) and virtual private networks (VPNs): DNSSEC adds a layer of security to DNS lookups by requiring DNS responses to be digitally signed. Specifically, DNSSEC can protect against DNS spoofing attacks by authenticating the origin of requests and verifying the integrity of DNS data.
VPNs provide confidentiality by using encryption to obscure IP addresses so that location and browsing history data (among other things) remain untraceable.
- 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 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: Regularly clearing the DNS cache removes all entries from the local system, which can be useful for deleting invalid or compromised DNS records that might direct users to malicious sites.
- 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.
IBM® NS1 Connect® provides fast, secure connections to users anywhere in the world with premium DNS and advanced, customizable traffic steering. Always-on, API-first architecture enables your IT teams to more efficiently monitor networks, deploy changes and conduct routine maintenance.
Quickly identify misconfigurations and security issues with customized, real-time reports based on DNS observability data from IBM NS1 Connect DNS Insights.
IBM Cloud® DNS services offer public and private authoritative DNS services with fast response time, unparalleled redundancy and advanced security—managed through the IBM Cloud web interface or by API.