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

By Thomas Lovas Lokoy — researched and drafted with AI assistance from published sources; edited and published by NorwegianSpark SA · Editorial policy
DNS, the Domain Name System, is the internet's directory: it turns a name such as topdomainagent.com into the numeric IP address a computer needs to connect. A lookup goes from your device's cache to a recursive resolver, which, if it does not already know the answer, asks a root server, then the server for the extension (.com), then the domain's own authoritative nameserver. Every answer carries a TTL that says how long it may be cached, which is why DNS changes take minutes to hours to reach everyone. Below: each step, the record types with a real lookup, TTL and propagation, and the mistakes that break websites and email.
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 identities, a.root-servers.net to m.root-servers.net, run by 12 independent operators; IANA's list includes Verisign (which runs two), ICANN, NASA's Ames Research Center, the US Department of Defense and the US Army Research Lab. Behind the 13 names sit far more machines: root-servers.org reported 2,047 operational instances on 16 October 2026, spread worldwide using anycast, so a resolver reaches a nearby copy.
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 resolvers cache every answer for as long as its TTL allows, so most queries are answered from a cache without going through all five steps.
A real lookup, traced
Here is what the public resolver at 1.1.1.1 returned for this site's own domain on 16 October 2026, queried over DNS-over-HTTPS:
| Record | What came back | TTL (seconds) |
|---|---|---|
| NS | Two Cloudflare nameservers | 86,400 (one day) |
| A | Two IPv4 addresses | 300 (five minutes) |
| AAAA | Two IPv6 addresses | 300 |
| MX | None | |
| TXT | Three records, all verification tokens for outside services | 300 |
Three things are visible in that table. The nameserver records change rarely, so they carry a long TTL; the address records sit behind a CDN that may change them, so they carry a short one. Two addresses of each kind mean that if one path fails, browsers can try the other. And there is no MX record, so this domain does not receive email at all, which is a deliberate choice you can read straight from DNS. You can see the same records for any domain in our WHOIS lookup, which shows the nameservers, or in your DNS host's dashboard.
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:
- Its resolver privacy commitments, read on 16 October 2026, say it truncates source IP addresses and deletes the truncated addresses and its resolver logs "within 25 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:
- Its privacy page, read the same day, describes temporary logs with IP addresses kept for 24 to 48 hours, and permanent logs without IP addresses that keep city- or region-level location for analysis
- Extensive documentation
- Available at 8.8.8.8 (primary) and 8.8.4.4 (secondary)
Which resolver is fastest depends on where you are and which network you are on, so measure it from your own connection rather than trusting a league table. Your internet provider's resolver is governed by its own privacy policy; read it if that matters to you.
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. Google's sender guidelines have required everyone sending to Gmail accounts to set up SPF or DKIM since 1 February 2024, and senders of more than 5,000 messages a day to set up SPF, DKIM and DMARC. SPF, DKIM and DMARC explained walks through the three records.
Moving nameservers without copying the zone. When you switch DNS hosts, the new host starts with an empty zone unless you import the old records. Export or screenshot every record first.
Where to go next
To put this into practice, how to set up DNS records is the step-by-step, how to connect a domain to your website covers the common hosts, and business email on your own domain covers the MX side. If you want to protect your answers from tampering, DNSSEC explained covers what it fixes and what it breaks, and what a domain name is covers how names, registries and registrars fit together.
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.
Frequently asked questions
What is DNS and how does it work?
DNS stands for the Domain Name System, which acts as the phone book of the internet. It translates human-readable domain names into numerical IP addresses that computers use to communicate. The resolution process involves checking local caches, querying a recursive resolver, and contacting root, TLD, and authoritative name servers.
What are the common DNS record types?
Common DNS record types include A records mapping domains to IPv4 addresses, AAAA records for IPv6 addresses, and CNAME records serving as domain aliases. Additionally, MX records specify mail servers, TXT records handle verification and security data like SPF and DKIM, and NS records specify authoritative name servers.
Why do DNS changes take time to propagate?
DNS changes are not instant because DNS records are cached at multiple levels including your browser, operating system, and recursive resolvers. Each cached copy must expire based on its time to live value before new values are fetched, which typically takes anywhere from a few minutes to forty-eight hours.
How many DNS root servers are there?
There are 13 root server names, a.root-servers.net to m.root-servers.net, run by 12 independent operators, but root-servers.org counted 2,047 operational instances worldwide on 16 October 2026. Anycast routing sends each query to a nearby instance.
What are public DNS resolvers?
Public DNS resolvers are alternatives to your internet service provider resolver that often offer better performance and privacy. Examples include Cloudflare, which provides strong privacy and encryption support, and Google, which offers reliable service and extensive documentation for handling queries.
Sources
Last updated:


