How DNS Works: What Really Happens When You Type a Web Address

The four players in every DNS lookup

A single lookup can involve four different kinds of servers. Each one knows only part of the answer and points you to whoever knows the next part.

• Recursive resolver. The middleman. Your device (through a small "stub resolver" built into the operating system) asks it the question, and it does the legwork. It is usually run by your internet provider, though public resolvers are popular alternatives.
• Root nameserver. The top of the tree. It doesn't know where example.com is, but it knows which servers handle .com.
• TLD nameserver. Responsible for one top-level domain such as .com, .org or a country code like .jp. It points to the servers that are authoritative for the specific domain.
• Authoritative nameserver. The final source of truth for a domain. It holds the actual records and returns the IP address, or an alias that sends the resolver on another lookup.

How DNS works, step by step

Here is what happens the first time anyone using your resolver looks up a name, with nothing cached yet:

1. Your browser asks the operating system, which forwards the question to the recursive resolver.
2. The resolver asks a root server. The root replies with a referral: "I don't know, but here are the .com servers."
3. The resolver asks a .com TLD server, which refers it to the domain's authoritative nameservers.
4. The resolver asks an authoritative server, which returns the record, for example the IPv4 address in an A record.
5. The resolver hands the answer back to your device and keeps a copy in its cache.
6. Your browser connects to that IP address and the page starts loading.

Notice that the root and TLD servers never give the final answer. ICANN's root server advisory committee notes that most root responses are referrals, steering resolvers toward the next server to ask.

Why it's usually so fast: caching and TTLs

If every lookup walked the whole tree, the internet would crawl. Instead, resolvers cache what they learn. Every DNS record carries a TTL (time to live) that tells servers how long they may keep it before checking again. If someone else on your resolver looked up the same site recently, you get the cached answer immediately. Resolvers also cache the referrals themselves, so they rarely need to contact a root server at all.

The root of it all: 13 names, over a thousand servers

You may have heard that the internet runs on 13 root servers. That's half true. According to ICANN's RSSAC FAQ, there are 13 root server identities (named a.root-servers.net through m.root-servers.net), each with one IPv4 and one IPv6 address. But each identity is served by many machines using anycast, where the same address is announced from many locations and routing delivers your query to a nearby copy. ICANN counts more than 1,500 such instances worldwide, run by a dozen independent operators.

Why only 13 names? The limit is historical: early DNS answers had to fit into a 512-byte UDP message, and listing more root servers would have overflowed the reply resolvers use to bootstrap. Later extensions eased that constraint, but the 13 identities remain.

DNS record types you'll actually meet

An authoritative server can hold many kinds of records. These are the ones most site owners and developers touch:

Try it yourself: watching a lookup happen

The dig tool (built into macOS and available for most Linux systems) lets you see DNS at work. Try these from a terminal:

# Ask your default resolver for a domain's IPv4 address
dig example.com A

# Just the answer, nothing else
dig +short example.com

# Find who handles a domain's email
dig example.com MX +short

# Walk the delegation chain yourself: root, then TLD, then authoritative
dig +trace example.com

On Windows, nslookup example.com gives a similar, simpler view. The +trace option is the best way to understand the hierarchy, because it skips your resolver's cache and shows each referral in turn.

Keeping lookups private: DNS over TLS and DNS over HTTPS

Classic DNS travels in plain text, usually over port 53, so anyone on the network path can see which sites you look up and, in principle, tamper with the answers. Two IETF standards encrypt the hop between your device and your resolver:

• DNS over TLS (DoT), RFC 7858. Wraps DNS in a TLS connection on dedicated TCP port 853. The RFC focuses on stub-to-resolver traffic and frames the goal as stopping eavesdropping and on-path tampering.
• DNS over HTTPS (DoH), RFC 8484. Sends DNS messages inside ordinary HTTPS requests, using the application/dns-message media type. Because it looks like regular web traffic, it is harder to block or interfere with, and browsers can use it directly.

Neither one proves that an answer is genuine at its source; that is the job of DNSSEC, which signs records cryptographically. RFC 7858 explicitly says encryption does not replace it. Encrypted transport plus signed records is the strongest combination, and it pairs naturally with other modern defenses such as phishing-resistant passkeys.

Frequently asked questions