How DNS Works: The Internet's Phone Book Explained

What is DNS?

Every time you type a website address into your browser, something remarkable happens behind the scenes. Your computer needs to figure out exactly where on the internet that website lives, and it does so using the Domain Name System, or DNS. Without DNS, you would need to memorize long strings of numbers just to visit your favorite websites — imagine having to type 142.250.80.46 every time you wanted to search on Google.

DNS is often described as the internet's phone book, and that analogy holds up remarkably well. Think about the days before smartphones, when you needed to call someone. You didn't memorize everyone's phone number — instead, you looked up their name in a phone book, found the corresponding number, and dialed it. DNS works the same way. When you type example.com into your browser, DNS translates that human-readable domain name into a machine-readable IP address like 93.184.216.34 (for IPv4) or 2606:2800:220:1:248:1893:25c8:1946 (for IPv6). This translation process is called DNS resolution.

Computers communicate using numerical IP addresses, but humans are far better at remembering words and names. DNS bridges that gap, acting as the fundamental translation layer that makes the internet usable. It is one of the most critical pieces of internet infrastructure — if DNS stops working, the internet effectively becomes inaccessible for most people, even though the underlying servers and networks are still running perfectly fine. You could still reach any website by IP address, but almost nobody knows or remembers those numbers.

DNS operates as a distributed, hierarchical database spread across millions of servers worldwide. No single server holds all the DNS records for the entire internet. Instead, responsibility is divided across many servers organized in a tree-like structure. This design makes DNS incredibly resilient and scalable — it handles trillions of queries every day without breaking a sweat.

A Brief History of DNS

DNS didn't always exist. In the early days of the internet — or more accurately, ARPANET — the network was small enough that a simple text file could keep track of every host. This file was called HOSTS.TXT, and it was maintained by the Stanford Research Institute's Network Information Center (SRI-NIC). Every computer on the network had a copy of this file, which mapped hostnames to IP addresses in a flat, simple format.

The system worked well enough when ARPANET had only a few dozen hosts. Administrators would periodically download the latest version of HOSTS.TXT via FTP from SRI-NIC, and their machines would know how to reach every other machine on the network. But as ARPANET grew through the late 1970s and early 1980s, this approach started to crumble under its own weight.

The problems were numerous. The file grew larger and larger, consuming more bandwidth with each download. Name collisions became common since there was no hierarchical structure — two organizations might try to claim the same hostname. Updates were slow because only SRI-NIC could modify the master file. And the system didn't scale: by the early 1980s, the number of hosts was growing exponentially, and the centralized HOSTS.TXT approach simply couldn't keep up.

In 1983, Paul Mockapetris, a computer scientist at USC's Information Sciences Institute, published RFC 882 and RFC 883, which defined the Domain Name System. These RFCs were later superseded by RFC 1034 and RFC 1035 in 1987, which remain the core DNS specifications to this day. Mockapetris's design was elegant: a hierarchical, distributed database that could scale with the growing internet while allowing decentralized management of name records. Different organizations could manage their own domain names without needing permission from a central authority.

The transition from HOSTS.TXT to DNS was gradual, but by the late 1980s, DNS had become the standard. The system has been extended and enhanced many times since then — with additions like DNSSEC for security, support for IPv6 addresses, and internationalized domain names — but the fundamental architecture Mockapetris designed over four decades ago still underpins the internet we use today.

The DNS Hierarchy

DNS is organized as an inverted tree structure, with the root at the top and increasingly specific domains branching downward. Understanding this hierarchy is key to understanding how DNS resolution works.

Root Servers sit at the very top of the DNS hierarchy. There are 13 root server clusters, labeled A through M (e.g., a.root-servers.net through m.root-servers.net). Despite the seemingly small number, each "server" is actually a cluster of machines distributed globally using anycast routing, so there are actually hundreds of physical root server instances around the world. Root servers don't know the IP address of every domain on the internet, but they know where to direct queries for each top-level domain. They are the starting point when a DNS resolver has no cached information about where to find a domain.

Top-Level Domain (TLD) Servers form the next level. TLDs are the rightmost part of a domain name — .com, .org, .net, .uk, .io, and so on. There are two main categories: generic TLDs (gTLDs) like .com, .org, and .info, and country-code TLDs (ccTLDs) like .uk, .de, and .jp. TLD servers know which authoritative nameservers are responsible for each second-level domain registered under their TLD. For example, the .com TLD servers know where to find the authoritative nameservers for google.com, amazon.com, and every other .com domain.

Authoritative Nameservers are the final authority for a specific domain. When you register a domain name, you configure (or your hosting provider configures) authoritative nameservers that hold the actual DNS records for your domain. These servers provide definitive answers to queries about your domain — returning the IP address for your web server, the mail server addresses for your email, and any other DNS records you've configured. If an authoritative nameserver says a domain points to a particular IP address, that answer is considered authoritative and trustworthy.

To put it all together: a domain name like www.example.com is read right to left in the DNS hierarchy. First comes the root (represented by an invisible dot at the very end), then the TLD (.com), then the second-level domain (example), and finally the subdomain (www). At each level of the hierarchy, a different set of servers is responsible for directing the query to the next level.

How DNS Resolution Works Step by Step

When you type www.example.com into your browser and press Enter, the following sequence of events occurs. While it sounds complex, the entire process typically completes in under 100 milliseconds.

Step 1: Browser Cache Check. Your browser first checks its own DNS cache to see if it already knows the IP address for www.example.com. If you've visited this site recently, the answer may already be stored locally, and no external query is needed.

Step 2: Operating System Cache Check. If the browser cache doesn't have the answer, the request is passed to the operating system's DNS resolver (sometimes called the stub resolver). The OS checks its own DNS cache, which is shared across all applications. On many systems, the OS also checks the local /etc/hosts file (or its Windows equivalent) for any manual mappings.

Step 3: Recursive Resolver Query. If neither local cache has the answer, the OS sends a DNS query to the configured recursive resolver (also called a recursive DNS server or recursor). This is typically provided by your ISP, but many people use public resolvers like Google's 8.8.8.8, Cloudflare's 1.1.1.1, or Quad9's 9.9.9.9. The recursive resolver's job is to do the heavy lifting of tracking down the answer. It first checks its own cache — since it handles queries for many users, there's a good chance it already has the answer cached from a previous request.

Step 4: Root Server Query. If the recursive resolver doesn't have a cached answer, it begins the iterative resolution process by querying one of the root servers. The resolver sends a query asking "Where can I find information about .com domains?" The root server doesn't know the answer to the original query, but it responds with a referral — the IP addresses of the TLD nameservers responsible for the .com domain.

Step 5: TLD Server Query. The recursive resolver then queries one of the .com TLD servers, asking "Where can I find information about example.com?" The TLD server responds with another referral — the IP addresses of the authoritative nameservers for example.com (for instance, ns1.example.com and ns2.example.com).

Step 6: Authoritative Nameserver Query. Finally, the recursive resolver queries the authoritative nameserver for example.com, asking "What is the IP address for www.example.com?" The authoritative server has the definitive answer and responds with the IP address — for example, 93.184.216.34.

Step 7: Response and Caching. The recursive resolver caches this answer (for a duration specified by the record's TTL) and returns it to your operating system, which caches it as well, and passes it to your browser, which also caches it. Your browser can now establish a TCP connection to 93.184.216.34 and request the web page.

It's worth noting the difference between recursive and iterative queries. Your computer sends a recursive query to the resolver, meaning "find the complete answer for me." The resolver then performs iterative queries to the various DNS servers, meaning each server responds with the best information it has (usually a referral) and the resolver follows the chain. This is why the recursive resolver is sometimes called a "resolver" — it resolves the query by doing all the legwork on your behalf.

DNS Record Types

DNS isn't just about mapping domain names to IP addresses. The system supports many different record types, each serving a specific purpose. Here are the most important ones:

A Record (Address Record) — The most fundamental DNS record type. An A record maps a domain name to an IPv4 address (a 32-bit address like 93.184.216.34). When someone types your domain into their browser, the A record is what ultimately tells their computer which server to connect to. A domain can have multiple A records, which enables basic round-robin load balancing — the resolver will return different IP addresses for successive queries, distributing traffic across multiple servers.

AAAA Record (Quad-A Record) — The IPv6 equivalent of the A record. As the internet transitions from IPv4 to IPv6, AAAA records map domain names to 128-bit IPv6 addresses like 2606:2800:220:1:248:1893:25c8:1946. The name "AAAA" comes from the fact that an IPv6 address is four times the size of an IPv4 address (128 bits vs. 32 bits). Modern websites should have both A and AAAA records to support both IPv4 and IPv6 clients.

CNAME Record (Canonical Name Record) — A CNAME record creates an alias from one domain name to another. For example, you might have a CNAME record that points www.example.com to example.com. When a resolver encounters a CNAME, it restarts the lookup process using the canonical (target) name. An important rule: a CNAME record cannot coexist with other record types for the same name, and a CNAME cannot be used at the zone apex (the bare domain like example.com itself) according to the DNS specification, although some DNS providers offer workarounds like ALIAS or ANAME records.

MX Record (Mail Exchange Record) — MX records specify the mail servers responsible for receiving email for a domain. Each MX record has a priority value (lower numbers indicate higher priority). When someone sends an email to user@example.com, the sending mail server queries the MX records for example.com and attempts delivery to the highest-priority server first, falling back to lower-priority servers if the primary is unavailable. For example, a domain might have 10 mail1.example.com and 20 mail2.example.com as its MX records.

TXT Record (Text Record) — TXT records hold arbitrary text data associated with a domain. While originally intended for human-readable notes, TXT records are now widely used for machine-readable purposes. The most common uses include SPF (Sender Policy Framework) records that specify which mail servers are authorized to send email on behalf of your domain, DKIM (DomainKeys Identified Mail) records for email authentication, DMARC (Domain-based Message Authentication) policies, and domain ownership verification for services like Google Workspace or cloud providers. A typical SPF record might look like v=spf1 include:_spf.google.com ~all.

NS Record (Nameserver Record) — NS records delegate a DNS zone to a set of authoritative nameservers. They tell the DNS system which servers are responsible for answering queries about a particular domain. Every domain must have at least two NS records for redundancy. When you register a domain and point it to a hosting provider, you're essentially setting NS records at the registrar level. For example, example.com NS ns1.provider.com.

SOA Record (Start of Authority) — Every DNS zone has exactly one SOA record, which contains administrative information about the zone. The SOA record specifies the primary nameserver for the zone, the email address of the domain administrator (with the @ replaced by a dot), serial numbers used for zone transfer synchronization, and various timing parameters like refresh intervals, retry intervals, expiration times, and the minimum TTL. The SOA record is essential for DNS zone management and transfers between primary and secondary nameservers.

PTR Record (Pointer Record) — PTR records are used for reverse DNS lookups — translating an IP address back into a domain name. While A and AAAA records let you find the IP address for a domain, PTR records let you find the domain name for an IP address. Reverse DNS is configured in special zones: for IPv4, addresses are reversed and appended to in-addr.arpa (so 93.184.216.34 becomes 34.216.184.93.in-addr.arpa). PTR records are commonly used by mail servers to verify the identity of sending servers and by network administrators for logging and troubleshooting.

DNS Caching and TTL

If every DNS query required a full trip through the root servers, TLD servers, and authoritative nameservers, the DNS system would be overwhelmed. Caching is the mechanism that makes DNS fast and efficient, and TTL (Time to Live) is the control mechanism that governs how long cached records remain valid.

Caching occurs at multiple levels in the DNS resolution chain:

Browser Cache: Modern browsers maintain their own DNS cache. Chrome, Firefox, Safari, and Edge all store DNS responses for recent lookups. In Chrome, you can view the browser's DNS cache by navigating to chrome://net-internals/#dns. Browser DNS caches are typically short-lived and are cleared when you close the browser or manually flush them.
Operating System Cache: The OS maintains its own DNS cache that is shared across all applications. On macOS, the DNS cache is managed by mDNSResponder; on Windows, the DNS Client service handles it; and on Linux, it depends on whether a local caching resolver like systemd-resolved or nscd is running. You can flush the OS DNS cache on macOS with sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder, and on Windows with ipconfig /flushdns.
Recursive Resolver Cache: This is the most impactful level of caching. Since recursive resolvers serve many clients, they accumulate a large cache of DNS records. When one user queries a popular domain like google.com, the resolver caches the result and can serve it instantly to all subsequent users who query the same domain, without making any additional external queries. ISP resolvers and popular public resolvers like Cloudflare and Google handle millions of queries and maintain extensive caches.

TTL (Time to Live) is a value, expressed in seconds, that is set on every DNS record by the domain administrator. It tells caching servers how long they should store a record before discarding it and fetching a fresh copy from the authoritative server. Common TTL values include:

300 seconds (5 minutes): A low TTL commonly used during DNS migrations or for records that change frequently. Services like CDNs often use low TTLs so they can quickly redirect traffic to different servers.
3600 seconds (1 hour): A moderate TTL that balances freshness with caching efficiency. This is a common default for many DNS providers.
86400 seconds (24 hours): A high TTL suitable for records that rarely change, such as MX records or NS records. Higher TTLs reduce the number of queries that authoritative servers need to handle but mean changes take longer to propagate globally.

When planning a DNS change — such as migrating a website to a new server — it's a best practice to lower the TTL well in advance (at least 24–48 hours before the change). This ensures that by the time you update the DNS record, most caches have already expired the old record and will quickly pick up the new one. After the migration is complete and verified, you can raise the TTL back to a higher value to reduce query volume on your authoritative servers.

It's important to understand that even after you update a DNS record, the old record will continue to be served by caches until their TTL expires. This is why DNS changes "propagate" across the internet over time rather than taking effect instantly. The propagation time is directly related to the TTL values that were set on the old records.

DNS Security

DNS was designed in the 1980s when the internet was a trusted academic network, and security was not a primary concern. As the internet grew into a global communications platform, the lack of built-in security in DNS became a significant vulnerability. Several threats target DNS, and various solutions have been developed to address them.

DNS Spoofing (Cache Poisoning) is one of the most well-known DNS attacks. In a cache poisoning attack, an attacker injects forged DNS records into a resolver's cache. When the resolver receives a query for a domain, it sends out a request to the authoritative server. The attacker races to send a fake response before the real one arrives, providing a malicious IP address that points to an attacker-controlled server. If successful, all users of that resolver who query the targeted domain will be directed to the attacker's server, where they might encounter phishing pages, malware, or other threats. The Kaminsky attack, discovered by Dan Kaminsky in 2008, revealed that DNS cache poisoning was far easier to carry out than previously thought, prompting urgent patches and accelerating the adoption of DNSSEC.

DNSSEC (DNS Security Extensions) adds a layer of authentication to DNS responses. With DNSSEC, authoritative nameservers digitally sign their DNS records using public-key cryptography. When a DNSSEC-validating resolver receives a response, it can verify the digital signature to confirm that the response hasn't been tampered with and genuinely came from the authoritative source. DNSSEC creates a chain of trust from the root zone down through the TLD to the authoritative server. While DNSSEC prevents tampering and forgery, it does not encrypt DNS queries — the content of queries and responses is still visible to anyone who can observe the network traffic.

DNS over HTTPS (DoH) encrypts DNS queries by wrapping them in HTTPS, the same encryption protocol used for secure web browsing. When your device uses DoH, DNS queries are sent to a compatible resolver (like Cloudflare's 1.1.1.1 or Google's 8.8.8.8) over an encrypted HTTPS connection on port 443. This prevents ISPs, network administrators, or anyone monitoring your network from seeing which domains you're resolving. DoH is supported by major browsers — Firefox, Chrome, Edge, and Safari — and can be enabled in their privacy settings. Critics of DoH point out that it centralizes DNS resolution with a few large providers and can interfere with legitimate network monitoring and content filtering.

DNS over TLS (DoT) is an alternative encryption approach that wraps DNS queries in TLS (Transport Layer Security) on a dedicated port (853). Unlike DoH, which disguises DNS traffic as regular HTTPS traffic, DoT uses its own port, making it easier for network administrators to identify and manage DNS traffic while still providing encryption. DoT is more commonly used on mobile devices and in operating system-level DNS configuration. Android (version 9 and later) supports DoT natively through its "Private DNS" setting.

For comprehensive DNS security, the ideal approach combines DNSSEC (to ensure response authenticity) with either DoH or DoT (to ensure query privacy). Together, these technologies address both tampering and surveillance threats to DNS.

Common DNS Tools

Several command-line tools are available for querying DNS records and troubleshooting DNS issues. These tools are invaluable for system administrators, developers, and anyone who needs to verify DNS configuration.

dig (Domain Information Groper) is the most powerful and flexible DNS lookup tool. It is the standard tool used by DNS administrators and is available on most Unix-like systems (macOS, Linux). dig provides detailed output including the query, answer, authority, and additional sections of the DNS response, along with timing information and the server that responded.

Basic dig usage to look up an A record:

dig example.com

Query a specific record type:

dig example.com MX
dig example.com AAAA
dig example.com TXT
dig example.com NS

Use a specific DNS server for the query (useful for verifying records on a particular resolver):

dig @8.8.8.8 example.com
dig @1.1.1.1 example.com AAAA

Get a concise answer with the +short flag:

dig example.com +short
# Output: 93.184.216.34

Trace the full DNS resolution path from root servers to the authoritative answer:

dig example.com +trace

nslookup is an older, simpler DNS query tool that is available on virtually all operating systems, including Windows. While less detailed than dig, it is straightforward and widely known. It can operate in interactive or non-interactive mode.

# Basic lookup
nslookup example.com

# Query a specific DNS server
nslookup example.com 8.8.8.8

# Look up MX records
nslookup -type=MX example.com

# Look up nameservers
nslookup -type=NS example.com

host is the simplest of the three tools, providing clean and concise output. It is ideal for quick lookups when you don't need the verbose detail that dig provides.

# Basic lookup
host example.com
# Output:
# example.com has address 93.184.216.34
# example.com has IPv6 address 2606:2800:220:1:248:1893:25c8:1946

# Reverse DNS lookup
host 93.184.216.34

# Query specific record type
host -t MX example.com
host -t TXT example.com

Each of these tools has its strengths: use dig for detailed DNS debugging and analysis, nslookup for quick cross-platform lookups, and host for simple, human-readable answers.

Troubleshooting DNS Issues

DNS problems can be frustrating because they often manifest as the cryptic "This site can't be reached" or "DNS_PROBE_FINISHED_NXDOMAIN" error in your browser. Here are the most common DNS issues and how to resolve them.

Problem: Website not loading, DNS_PROBE_FINISHED_NXDOMAIN error.

This error means the DNS resolver couldn't find any records for the domain. Possible causes include a mistyped domain name, an expired domain registration, or DNS records that haven't been configured yet. Start by verifying the domain name is spelled correctly, then use dig or nslookup to check whether DNS records exist. If you own the domain, verify that your domain registration is active and that NS records are correctly pointing to your DNS provider.

Problem: DNS changes not taking effect.

This is almost always a caching issue. DNS records are cached at multiple levels (browser, OS, recursive resolver), and each cached entry will persist until its TTL expires. Solutions include flushing your local DNS cache, trying a different DNS resolver, and waiting for the TTL to expire. If you need changes to take effect quickly, reduce the TTL on the record well before making the change — ideally 24 to 48 hours in advance. You can verify what different resolvers see by querying them directly:

# Check what Google's resolver sees
dig @8.8.8.8 yourdomain.com +short

# Check what Cloudflare's resolver sees
dig @1.1.1.1 yourdomain.com +short

# Check the authoritative answer directly
dig yourdomain.com +trace

Problem: Slow DNS resolution.

If websites are loading slowly and the delay seems to be in the initial connection (before any content loads), slow DNS resolution may be the culprit. This can happen when your configured DNS resolver is far away, overloaded, or experiencing issues. Solutions include switching to a faster public DNS resolver (Cloudflare's 1.1.1.1 and Google's 8.8.8.8 are generally the fastest), running a local DNS caching resolver, or checking for network issues between you and your DNS server. You can measure DNS resolution time with dig:

# The "Query time" line shows how long resolution took
dig example.com | grep "Query time"
# ;; Query time: 23 msec

Problem: Email not being delivered.

Email delivery depends heavily on correct DNS configuration. If email isn't working, check MX records to ensure they point to the correct mail servers and that the mail servers are reachable. Also verify SPF, DKIM, and DMARC records (stored as TXT records), as missing or incorrect email authentication records can cause messages to be rejected or flagged as spam by receiving servers.

# Check MX records
dig yourdomain.com MX +short

# Check SPF record
dig yourdomain.com TXT +short | grep spf

# Check DMARC record
dig _dmarc.yourdomain.com TXT +short

Problem: DNS works for some users but not others.

This inconsistency is typically caused by DNS propagation delays after a recent change. Different recursive resolvers cache records independently, so some resolvers may still be serving the old record while others have picked up the new one. The solution is usually to wait for propagation to complete (up to the old TTL value). You can identify which resolvers have updated by querying multiple resolvers from different providers and geographic locations.

Problem: Intermittent DNS failures.

If DNS resolution works sometimes but fails at other times, the issue might be with the authoritative nameservers or the network path to them. Check that all configured NS records are responding correctly and that you have at least two authoritative nameservers for redundancy. You can test each nameserver individually:

# Find the nameservers
dig yourdomain.com NS +short

# Query each one directly
dig @ns1.provider.com yourdomain.com
dig @ns2.provider.com yourdomain.com

Conclusion

DNS is one of the most fundamental systems underpinning the modern internet. Every website visit, every email sent, every API call — nearly all internet communication begins with a DNS query. The system's elegant hierarchical design, conceived by Paul Mockapetris over four decades ago, has scaled from a network of a few hundred hosts to one serving billions of devices and trillions of queries daily. Understanding how DNS works — from the recursive resolution process and record types to caching behavior and security mechanisms — gives you a deeper appreciation for the infrastructure that makes the internet seamless and a practical advantage when configuring, debugging, or securing your own domains and services.