How DNS Works: Domain Name System Explained

Every time you type a website address like google.com or github.com into your browser, something remarkable happens behind the scenes. Your computer does not magically know where that website lives on the internet. Instead, it relies on a global, distributed system that translates the human-friendly name you typed into a machine-readable IP address. That system is the Domain Name System, or DNS.

DNS is one of the foundational technologies of the internet. Without it, we would have to remember long strings of numbers for every website, email server, and online service we use. Understanding how DNS works is essential for developers, system administrators, and anyone who wants a deeper grasp of how the web actually functions.

In this article, we will break down DNS from the ground up. You will learn what it is, how the resolution process works step by step, the different types of DNS servers and records, how caching improves performance, common misconceptions, and practical takeaways you can apply as a developer.

What Is DNS?

The Domain Name System is a hierarchical and decentralized naming system for computers, services, and other resources connected to the internet or a private network. Its primary job is to map human-readable domain names to numerical IP addresses.

Think of DNS as the phonebook of the internet. When you want to call a friend, you look up their name and find their phone number. Similarly, when your browser wants to load a webpage, it looks up the domain name and finds the corresponding IP address so it can establish a connection.

IP addresses come in two main versions:

• IPv4 — 32-bit addresses written as four numbers separated by dots (for example, 93.184.216.34)
• IPv6 — 128-bit addresses written in hexadecimal (for example, 2606:2800:220:1:248:1893:25c8:1946)

DNS handles both. An A record maps a name to an IPv4 address, while an AAAA record maps a name to an IPv6 address.

DNS was designed in the 1980s to replace the earlier hosts.txt file, a single centralized file that listed every hostname and IP address on the early internet. As the network grew, a single file became impossible to maintain. DNS solved this by creating a distributed, hierarchical database that scales to the size of the modern internet.

Simple Explanation

Imagine you want to visit example.com. Your browser does not know the IP address of example.com. So it asks a series of specialized servers:

1. First, it checks whether it already knows the answer from a previous visit (local cache).
2. If not, it asks a recursive DNS resolver (usually provided by your ISP or a public service like 1.1.1.1 or 8.8.8.8).
3. The recursive resolver then asks the root DNS servers, which point it to the correct top-level domain (TLD) servers for .com.
4. The TLD servers point the resolver to the authoritative nameservers for example.com.
5. The authoritative nameserver finally returns the actual IP address.
6. The resolver gives that IP address back to your browser, which then connects to the web server and loads the page.

This entire process usually completes in milliseconds, especially when answers are already cached along the way.

A useful analogy is a large library:

• The recursive resolver is the librarian who goes and finds the book for you.
• The root servers are the main index that tells the librarian which section of the library to search.
• The TLD servers are the specific shelves for a category (for example, all .com books).
• The authoritative nameserver is the dictionary on that shelf that contains the exact definition (the IP address).

How DNS Works Internally

DNS resolution is a carefully orchestrated sequence of queries and referrals. Let us examine the architecture and the full resolution path in detail.

The Four Main Types of DNS Servers

1. Recursive Resolver (DNS Recursor) — Receives the query from the client (your browser or operating system). It is responsible for performing the full lookup by querying other servers on behalf of the client. Most users interact only with this server.
2. Root Nameservers — There are 13 logical root server identities (a.root-servers.net through m.root-servers.net), operated by different organizations and distributed globally using anycast. They do not know the final IP address; they only know which TLD servers handle each top-level domain.
3. TLD Nameservers — These servers are authoritative for a top-level domain such as .com, .org, .net, or country-code TLDs like .uk or .in. They return the nameservers that are authoritative for the specific second-level domain.
4. Authoritative Nameservers — These hold the actual DNS records for a domain (A, AAAA, MX, CNAME, TXT, and others). They provide the definitive answer.

Step-by-Step DNS Lookup Process

Here is the complete sequence when nothing is cached:

1. You type example.com into the browser and press Enter.
2. The browser checks its own DNS cache. If the record is present and still valid (based on TTL), it uses it immediately.
3. If not found, the browser asks the operating system’s stub resolver. The OS checks its own cache and the local hosts file.
4. If still unresolved, the stub resolver sends a recursive query to the configured recursive DNS resolver (ISP or public resolver).
5. The recursive resolver checks its cache. If the answer is not there, it begins iterative queries starting at the root.
6. The recursive resolver queries a root nameserver. The root responds with a referral to the .com TLD nameservers.
7. The recursive resolver queries a .com TLD nameserver. The TLD responds with a referral to the authoritative nameservers for example.com.
8. The recursive resolver queries one of the authoritative nameservers for example.com. The authoritative server returns the A (or AAAA) record containing the IP address.
9. The recursive resolver caches the answer according to the TTL and returns the IP address to the client.
10. The browser uses the IP address to open a TCP connection (usually followed by TLS for HTTPS) and requests the webpage.

When caching is involved at any layer, many of these steps are skipped, which is why subsequent visits to the same site feel faster.

Recursive vs Iterative Queries

• Recursive query — The client asks the resolver to do all the work and return either the final answer or an error. The client does not receive intermediate referrals.
• Iterative query — The server returns the best answer it currently has. If it does not know the final answer, it returns a referral to another server that might know more. The recursive resolver uses iterative queries when talking to root, TLD, and authoritative servers.

In normal operation, your computer issues a recursive query to the recursive resolver, and the recursive resolver issues iterative queries to the rest of the hierarchy.

DNS Record Types

DNS stores information in resource records. The most important types for developers are:

Record Type	Purpose	Example
A	Maps a name to an IPv4 address	example.com → 93.184.216.34
AAAA	Maps a name to an IPv6 address	example.com → 2606:2800:220:1:248:1893:25c8:1946
CNAME	Creates an alias that points to another name	www.example.com → example.com
MX	Specifies mail servers and their priority	10 mail.example.com
NS	Lists the authoritative nameservers for a zone	ns1.example.com
TXT	Stores arbitrary text (SPF, DKIM, verification)	v=spf1 include:_spf.google.com ~all
SOA	Start of Authority — zone metadata and timing parameters	Primary NS, serial, refresh, retry, expire, minimum

CNAME records cannot coexist with other record types at the same name, and they are not allowed at the zone apex (the bare domain) unless the provider supports special flattening or ALIAS records.

Caching and TTL

Every DNS record carries a Time-To-Live (TTL) value measured in seconds. The TTL tells resolvers how long they may cache the answer before they must ask again.

Caching occurs at multiple layers:

• Browser DNS cache
• Operating system DNS cache
• Recursive resolver cache
• Sometimes intermediate caches in corporate networks or CDNs

A longer TTL improves performance and reduces load on authoritative servers, but it also means changes take longer to become visible worldwide. A shorter TTL allows faster updates (useful during migrations or failovers) at the cost of more frequent queries.

Common TTL values range from 300 seconds (5 minutes) for dynamic records to 86400 seconds (24 hours) for stable records such as NS records.

When people talk about “DNS propagation,” they are usually referring to the time it takes for old cached copies to expire according to the previous TTL. The authoritative servers update immediately; the delay is caused by caches elsewhere.

Protocol Details

DNS traditionally uses UDP on port 53 for most queries because they are small and need to be fast. If a response is too large (or for zone transfers), TCP on port 53 is used. Modern DNS also supports DNS over HTTPS (DoH) and DNS over TLS (DoT) to encrypt queries and improve privacy.

Real-World Examples

DNS is involved in almost every internet interaction:

• Web browsing — Every page load begins with one or more DNS lookups for the main domain and any additional resources (CDNs, APIs, analytics, fonts).
• Email delivery — When you send an email to user@example.com, the sending mail server queries the MX records of example.com to discover where to deliver the message.
• API calls — Mobile apps and backend services resolve hostnames of third-party APIs before making HTTP requests.
• Microservices — Inside a Kubernetes cluster or service mesh, service discovery often relies on DNS (or DNS-like mechanisms) so that services can find each other by name.
• Load balancing and failover — Multiple A records, low TTLs, or health-checked DNS services can distribute traffic or switch traffic to a backup region when a primary site fails.
• CDN routing — Content delivery networks use DNS to return the IP address of the edge server that is geographically closest to the user.

As a developer you encounter DNS when you:

• Point a custom domain to a hosting provider or Vercel/Netlify project
• Configure SPF, DKIM, and DMARC records for email authentication
• Debug “site not found” or “connection refused” issues that turn out to be DNS misconfigurations
• Use tools such as dig, nslookup, or host to inspect records

Code and Command-Line Examples

You can inspect DNS behavior directly from the terminal. Here are a few practical examples.

Basic lookup with dig:

dig example.com

This returns the A record, the authoritative nameservers, and timing information.

Trace the full resolution path:

dig +trace example.com

This shows the queries to the root, TLD, and authoritative servers.

Query a specific record type:

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

Query a public resolver:

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

Check your local cache (Windows):

ipconfig /displaydns

Flush local DNS cache:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
resolvectl flush-caches

These commands are invaluable when diagnosing why a domain points to the wrong IP after a change.

Common Misconceptions

• “DNS changes are instantaneous.” — The authoritative servers update immediately, but resolvers around the world continue serving the old answer until the previous TTL expires. Propagation is really cache expiration.
• “DNS is just for websites.” — DNS is used for email (MX), service discovery, certificate authority authorization (CAA), reverse lookups (PTR), and many other purposes.
• “CNAME can be used at the root of a domain.” — Standard CNAME records are not allowed at the zone apex. Providers offer ALIAS or ANAME records or CNAME flattening as workarounds.
• “A longer TTL is always better.” — Longer TTLs improve performance for stable records but make emergency changes slower. Plan ahead by lowering TTL before major changes.
• “DNS is secure by default.” — Traditional DNS queries and responses travel in plaintext and can be intercepted or spoofed. DNSSEC adds cryptographic signatures; DoH and DoT encrypt the channel.
• “There are only 13 root servers.” — There are 13 root server identities, but each is implemented by hundreds of physical servers distributed worldwide using anycast.

Best Practices and Key Takeaways

• Understand the full resolution path so you can diagnose problems systematically (browser cache → OS cache → recursive resolver → root → TLD → authoritative).
• Choose TTL values deliberately. Use shorter TTLs (300–600 seconds) before planned migrations, then raise them again once stable.
• Always publish both A and AAAA records when your infrastructure supports IPv6.
• Use CNAME for subdomains that should follow another name; use A/AAAA (or provider ALIAS) for the apex.
• Protect email deliverability with correct MX, SPF, DKIM, and DMARC records.
• Prefer public recursive resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) when you need reliability or privacy features, or run your own resolver in larger environments.
• Monitor DNS health. Incorrect or missing records are a frequent cause of outages and email failures.
• Remember that DNS is a critical dependency. If it fails, almost every higher-level service becomes unreachable.

Mastering DNS gives you a powerful mental model of how the internet maps names to locations. It also makes you far more effective when deploying applications, debugging connectivity issues, or designing resilient systems.

FAQ

What is DNS in simple terms?
DNS is the system that translates human-readable domain names (like example.com) into the numeric IP addresses that computers use to communicate.

How does DNS resolution work step by step?
The browser or OS asks a recursive resolver. The resolver queries root servers, then TLD servers, then the domain’s authoritative nameservers, and finally returns the IP address. Caching often short-circuits this process.

What is the difference between a recursive resolver and an authoritative nameserver?
A recursive resolver finds the answer on behalf of the client by querying other servers. An authoritative nameserver is the final source of truth that holds the actual DNS records for a domain.

What is DNS TTL?
TTL (Time To Live) is the number of seconds a resolver is allowed to cache a DNS record before it must request a fresh copy from the authoritative server.

Why do DNS changes take time to appear?
Because resolvers and clients continue using previously cached answers until those answers expire according to the old TTL. The change itself is instant at the authoritative servers.

What are the most common DNS record types?
A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), NS (nameservers), TXT (text data such as SPF), and SOA (zone authority).

Can I use a CNAME on the root domain?
Not with a standard CNAME record. Many DNS providers offer ALIAS, ANAME, or CNAME flattening features that achieve a similar result at the apex.

How can I check DNS records for a domain?
Use command-line tools such as dig, nslookup, or host, or online DNS lookup services. dig +trace is especially useful for seeing the full resolution path.

Related Articles

• What Happens When You Type a URL?
• How HTTP Works
• How HTTPS Works
• How Browsers Render Web Pages
• How APIs Work
• Networking Basics for Developers

Understanding DNS is a foundational skill that pays dividends across web development, DevOps, and system design. Once you internalize the resolution process, caching behavior, and record types, many previously mysterious network issues become straightforward to diagnose and fix.