What Is DNS? How the Domain Name System Works

Computers don't communicate using names. They communicate using IP addresses — numeric labels like 198.51.100.10 (IPv4) or 2001:db8::1 (IPv6) that identify a specific machine on the network. Names like example.com exist for people, because nobody wants to memorize a string of digits for every site they visit.

DNS is the system that maps names to addresses (and back again). When you type example.com, DNS is what looks up the IP address your browser should connect to. Without it, the modern web would be effectively unusable — and just as importantly, it lets the address behind a name change at any time without you ever needing to know.

That last point is the real power of DNS: names are stable, addresses are not. A company can move its website to a new server, switch hosting providers, or spread traffic across dozens of machines, all while example.com stays exactly the same.

The classic way to describe DNS is as the internet's phonebook: you know a name, you look it up, and you get the number to dial. It's a useful starting point — DNS really does turn a name you know into an address you need.

But the analogy has limits worth understanding:

• There is no single book. DNS data is spread across millions of servers worldwide, organized in a hierarchy. No one machine holds all the answers.
• It's distributed and delegated. Each part of a name is managed by a different authority, who can delegate sub-parts to others.
• It's more than names-to-numbers. DNS also stores mail routing, text records for security, aliases, and more — not just IP addresses. See DNS record types for the full picture.
• Answers are cached and time-limited. Unlike a printed book, DNS results expire and refresh on their own schedule.

So: a phonebook, yes — but a living, distributed, self-updating one with no central copy.

DNS is organized as an inverted tree. Reading a domain name from right to left walks you down that tree, from the most general level to the most specific.

• The root sits at the very top, written as an invisible trailing dot (example.com.). A small, globally distributed set of root servers knows one thing well: which servers are responsible for each top-level domain.
• Top-level domains (TLDs) are the rightmost label — .com, .org, .net, country codes like .uk, and hundreds more. Each TLD is run by a registry whose nameservers know which servers are authoritative for every domain registered under it.
• Authoritative nameservers hold the actual records for an individual domain such as example.com. These are the source of truth — the final answer about that domain's IP addresses, mail servers, and other records.

This delegation is what makes DNS scale. The root doesn't need to know anything about example.com directly; it only needs to point you toward .com, which points you toward the domain's own nameservers. You can see a domain's nameservers with our nameserver lookup, and learn more in nameservers and NS records.

Let's resolve example.com from scratch — a "cold" lookup with nothing cached anywhere. Here's the full journey:

1. Your device asks a stub resolver. The tiny DNS client built into your operating system takes the name example.com and hands it off to a configured recursive resolver (often run by your ISP, your router, or a public service).
2. The recursive resolver checks its cache. If it already looked up example.com recently and the answer hasn't expired, it returns that immediately. Assume here it hasn't, so it does the legwork.
3. It asks a root server. "Where do I find .com?" The root replies with a referral: the nameservers for the .com TLD.
4. It asks a .com TLD server. "Where do I find example.com?" The TLD replies with another referral: the authoritative nameservers for example.com.
5. It asks an authoritative nameserver. "What's the A record for example.com?" This server holds the real answer and returns it — for example, 198.51.100.10.
6. The resolver caches and replies. It stores the answer for the duration of its TTL, then hands the IP address back to your stub resolver, which gives it to your application.
7. Your device connects. Your browser opens a connection to 198.51.100.10 and the page loads.

The key insight: the recursive resolver does the recursion — chasing referrals from root to TLD to authoritative on your behalf — while each server it asks gives only a referral or a final answer. The whole exchange typically completes in tens of milliseconds, and most of the time several steps are skipped entirely thanks to caching.

It's easy to conflate the two kinds of server, but they play opposite roles:

• A recursive resolver works for you. It accepts a question, then does whatever it takes — querying root, TLD, and authoritative servers in turn — to track down the answer and return it. It also caches results to speed up future lookups. Examples are the resolvers run by ISPs and public DNS providers.
• An authoritative nameserver works for a domain. It doesn't go ask anyone else; it simply publishes the definitive records for the zones it's responsible for. When the recursive resolver finally reaches it, it gives the real answer (or a referral to a delegated sub-zone).

Put simply: recursive resolvers ask questions until they get an answer; authoritative servers give answers for the names they own. A single recursive query may touch several authoritative servers along the way.

If every lookup had to start at a root server, DNS would be slow and the root would be overwhelmed. Caching prevents that. When a recursive resolver gets an answer, it keeps a copy for a set amount of time before discarding it.

That lifespan is controlled by the record's TTL (Time To Live), a value in seconds attached to every DNS record. A TTL of 3600 means "this answer is good for one hour." During that window, any user asking the same resolver for the same name gets the cached answer instantly, with no trip to root, TLD, or authoritative servers.

TTL is also why DNS changes aren't instant: until cached copies expire around the internet, some resolvers still hand out the old answer. This lag is what people mean by propagation. For a full treatment — including how to plan TTLs before a migration — see TTL and propagation.

A zone is a portion of the DNS namespace that a single administrator controls as one unit. When you own example.com, you manage the example.com zone — all the records directly under that name, unless you delegate a sub-zone (like support.example.com) to someone else.

The records for a zone live in a zone file: a structured list of every record the authoritative nameserver will answer with. A simplified zone file for example.com might contain entries like these:

• example.com. 3600 IN A 198.51.100.10 — the IPv4 address
• example.com. 3600 IN AAAA 2001:db8::1 — the IPv6 address
• example.com. 3600 IN MX 10 mail.example.com. — where mail goes
• www.example.com. 3600 IN CNAME example.com. — an alias
• example.com. 3600 IN NS ns1.example.com. — the authoritative nameserver

Each line names a record's owner, its TTL, its class (IN for internet), its type, and its value. The zone file is the authoritative source — what nameservers load and serve as the definitive answers for that domain.

DNS stores far more than IP addresses. The record type tells resolvers what kind of information they're asking for. The ones you'll meet most often:

• A and AAAA — map a name to an IPv4 and IPv6 address respectively. See A and AAAA records.
• CNAME — points one name at another name as an alias. See CNAME records.
• MX — directs email to the correct mail servers. See MX records.
• TXT — holds arbitrary text, widely used for email authentication (SPF, DKIM, DMARC) and domain verification. See TXT, SPF, DKIM, and DMARC.
• NS — names the authoritative nameservers for a zone.
• SOA — the "start of authority" record carrying zone-wide settings.

For the complete catalog and when to use each, read DNS record types.

DNS isn't just a web concern — it's the foundation that other internet services are built on:

• The web. Every link, every API call, every image load starts with a DNS lookup. If DNS fails, sites appear "down" even when the servers behind them are perfectly healthy.
• Email. Mail delivery depends on MX records to find the right servers, and on SPF, DKIM, and DMARC records to prove messages are legitimate and block spoofing.
• Security and trust. Because so much hinges on DNS, it's also a target. DNSSEC adds cryptographic signatures so resolvers can verify that an answer truly came from the real authoritative source and wasn't tampered with in transit.

Understanding DNS makes you better at diagnosing outages, configuring services, and protecting domains — skills that pay off whether you run one website or a thousand.

who.is lets you inspect any domain's DNS the same way a recursive resolver does — but with everything laid out for you to read:

• Run a live DNS lookup to see a domain's A, AAAA, MX, TXT, and NS records as they're served right now.
• Check a domain's nameservers to see which servers are authoritative for it.
• Look up WHOIS or RDAP data for registration details — who owns a domain and when it expires.
• Investigate an address directly with IP WHOIS to find out who an IP belongs to.

Together, these tools let you trace a name all the way from registration to the records that make it work. Start by looking up a domain's DNS records.