What Is DNS and How Does It Work? A Plain-English Guide

# What Is DNS and How Does It Work? A Plain-English Guide

Every time you type a website address into your browser, something remarkable happens behind the scenes. Your computer does not actually know where "google.com" is. Computers communicate using numerical IP addresses, like 142.250.80.46. The system that translates the human-readable domain name you typed into the numerical address your computer needs is called DNS — the Domain Name System.

DNS is often described as the phone book of the internet. That analogy holds up well: just as a phone book translates a person's name into their phone number, DNS translates a domain name into an IP address. But the actual process is more sophisticated than a single lookup in a single book. Here is exactly what happens, step by step, from the moment you type a URL to the moment the page loads.

The Full DNS Resolution Process

Step 1: Your Browser Checks Its Cache

Before your computer reaches out to the internet, it checks whether it already knows the answer. Your browser maintains a DNS cache — a local record of recent domain-to-IP translations. If you visited google.com five minutes ago, the answer is probably still cached, and no network request is needed.

If the browser cache misses, the operating system checks its own DNS cache. On Windows, you can view this cache by running `ipconfig /displaydns` in the command prompt. On macOS and Linux, the system resolver maintains a similar cache.

Step 2: The Recursive Resolver

If neither local cache has the answer, your computer sends a DNS query to a recursive resolver. This is typically provided by your internet service provider (ISP), but many people configure their computers to use public resolvers like Cloudflare's 1.1.1.1 or Google's 8.8.8.8.

The recursive resolver is the workhorse of the DNS system. Its job is to take your query ("What is the IP address for google.com?") and find the answer, even if it has to ask multiple servers along the way. It also caches answers so that future queries for the same domain can be answered faster.

Step 3: The Root Name Servers

If the recursive resolver does not have the answer cached, it starts at the very top of the DNS hierarchy: the root name servers. There are 13 root server clusters (labelled A through M), operated by organisations like ICANN, Verisign, NASA, and the US Department of Defense. Despite there being only 13 cluster identifiers, there are actually hundreds of physical servers distributed globally using anycast routing.

The recursive resolver asks a root server: "Where can I find information about .com domains?" The root server does not know the IP address of google.com, but it knows which servers are responsible for the .com TLD. It responds with the addresses of the .com TLD name servers.

Step 4: The TLD Name Servers

The recursive resolver now contacts a .com TLD name server and asks: "Where can I find information about google.com?" The TLD server does not know the final IP address either, but it knows which name servers are authoritative for google.com. It responds with those addresses.

Step 5: The Authoritative Name Server

Finally, the recursive resolver contacts one of google.com's authoritative name servers and asks: "What is the IP address for google.com?" This server has the definitive answer. It responds with the IP address (or addresses), and the recursive resolver passes this answer back to your computer.

Your browser now connects to the IP address and loads the website.

The Entire Process Takes Milliseconds

This five-step process sounds slow, but it typically completes in 20 to 100 milliseconds. And because of aggressive caching at every level, most DNS queries are answered from cache without going through all five steps.

DNS Record Types Explained

When the authoritative name server responds to a query, it returns a specific type of DNS record. Each record type serves a different purpose. Here are the most common ones:

A Record

An A record maps a domain name to an IPv4 address. This is the most fundamental DNS record type.

Example: `example.com → 93.184.216.34`

When someone types your domain into a browser, the A record is what ultimately tells their computer which server to connect to.

AAAA Record

An AAAA record (pronounced "quad-A") is the same as an A record but for IPv6 addresses. As the internet transitions from IPv4 to IPv6, AAAA records are increasingly important.

Example: `example.com → 2606:2800:0220:0001:0248:1893:25c8:1946`

CNAME Record

A CNAME (Canonical Name) record maps one domain name to another domain name. It is essentially an alias.

Example: `www.example.com → example.com`

This tells DNS that www.example.com should resolve to whatever IP address example.com resolves to. CNAMEs are commonly used for subdomains and for pointing your domain to hosting services (e.g., `blog.example.com → mysite.netlify.app`).

Important limitation: a CNAME record cannot coexist with other record types for the same name. You cannot have both a CNAME and an MX record for the same subdomain.

MX Record

MX (Mail Exchange) records specify which mail servers handle email for your domain. When someone sends an email to you@example.com, the sending mail server looks up the MX records for example.com to find out where to deliver the message.

Example: `example.com MX 10 mail1.example.com` `example.com MX 20 mail2.example.com`

The numbers (10, 20) are priority values. Lower numbers have higher priority. If mail1 is unavailable, the sending server tries mail2.

If you use Google Workspace, your MX records will point to Google's mail servers. If you use Microsoft 365, they will point to Microsoft's servers.

TXT Record

TXT records store arbitrary text data associated with your domain. They are used for a wide variety of verification and security purposes:

• SPF (Sender Policy Framework): Specifies which mail servers are allowed to send email on behalf of your domain. Example: `v=spf1 include:_spf.google.com ~all`
• DKIM: Contains a cryptographic public key for email authentication
• DMARC: Defines how email servers should handle messages that fail SPF or DKIM checks
• Domain verification: Services like Google Search Console, Stripe, and Mailchimp use TXT records to verify domain ownership

NS Record

NS (Name Server) records specify which DNS servers are authoritative for your domain. When you change your domain's name servers at your registrar, you are updating these records at the TLD level.

Example: `example.com NS ns1.cloudflare.com` `example.com NS ns2.cloudflare.com`

TTL: How Long DNS Records Are Cached

Every DNS record includes a TTL (Time to Live) value, measured in seconds. This tells resolvers how long they should cache the record before checking for an update.

Common TTL values: - 300 seconds (5 minutes): Good for records that might change frequently - 3600 seconds (1 hour): Standard for most records - 86400 seconds (24 hours): Good for records that rarely change

When you are about to make a DNS change, it is good practice to lower the TTL to 300 seconds a day or two before making the change. This ensures that after you update the record, the old value expires from caches within five minutes. After the change is live and working, you can raise the TTL back to a longer value.

DNS Propagation: Why Changes Are Not Instant

When you update a DNS record, the change does not take effect instantly worldwide. This is because DNS records are cached at multiple levels — your browser, your operating system, your ISP's recursive resolver, and other resolvers around the world. Each cached copy has to expire (based on the TTL) before the new value is fetched.

DNS propagation typically takes anywhere from a few minutes to 48 hours, depending on the previous TTL value and how aggressively different resolvers cache.

You can check the propagation status of your DNS changes using tools like dnschecker.org, which queries DNS servers around the world and shows you which ones have the new record and which still have the old one.

Public DNS Resolvers: Cloudflare vs Google

Most people use whatever DNS resolver their ISP provides. But public DNS resolvers often provide better performance and privacy:

Cloudflare 1.1.1.1: - Consistently the fastest public DNS resolver in benchmarks - Strong privacy policy — Cloudflare commits to not selling your data and purges query logs within 24 hours - Supports DNS over HTTPS (DoH) and DNS over TLS (DoT) for encrypted queries - Available at 1.1.1.1 (primary) and 1.0.0.1 (secondary)

Google 8.8.8.8: - Reliable and fast, though typically slightly slower than Cloudflare - Extensive documentation and transparency reports - Google does log some query data for operational purposes - Available at 8.8.8.8 (primary) and 8.8.4.4 (secondary)

Both are significant improvements over most ISP resolvers, which can be slow, unreliable, and may log or monetise your browsing data.

Common DNS Mistakes

Forgetting to update MX records after a DNS change. If you move your domain to new name servers and do not re-create your MX records, your email stops working. Always document your existing DNS records before making changes.

Setting TTL too high before a migration. If your A record has a TTL of 86400 (24 hours) and you change it, some users will see the old IP for up to a day. Lower TTL in advance.

Using a CNAME at the zone apex. A CNAME record at the root domain (example.com, not www.example.com) is technically not allowed by the DNS specification and can cause issues. Some providers offer ALIAS or ANAME records as a workaround.

Not setting up SPF, DKIM, and DMARC. Without these TXT records, email you send from your domain is more likely to land in spam folders. These records are not optional in 2026 — major email providers like Gmail and Outlook actively penalise domains that lack them.

DNS is foundational infrastructure that most people never think about until something breaks. Understanding how it works puts you in a much better position to troubleshoot issues, migrate hosting providers, and configure your domain correctly from the start.