DNS Explained: How Domain Lookups Work and Affect Speed

Quick answer: the Domain Name System (DNS) is the internet's phone book. It turns a name you can remember, such as example.com, into the IP address a computer needs, such as 93.184.216.34. Your device asks a recursive resolver (usually your ISP's or a public one), which finds the answer by asking other DNS servers if it does not already have it saved. Saved answers are reused until their time to live (TTL) runs out. A cached lookup takes a few milliseconds or less, while a full uncached lookup can add tens to a couple of hundred milliseconds to the first visit to a site.

What is DNS and why does it exist?

Computers route traffic using IP addresses, but people remember names. DNS bridges the two. It is a distributed, hierarchical database: no single server knows everything, and responsibility is split among millions of servers operated by registries, hosting providers, ISPs and companies. Because of this design the system scales to billions of lookups per day and has no single point of failure.

Besides address lookups, DNS stores other facts about domains: where email for a domain should go, which servers are authoritative for it, text strings used for ownership verification and email authentication, and aliases between names. Almost every action on the internet, from opening a web page to sending a message or starting a game, starts with at least one DNS query.

The cast of DNS servers

A lookup involves several roles. One physical server can play more than one role, but the roles are distinct.

Role	What it does	Example
Stub resolver	Small client built into your operating system; asks the recursive resolver and caches answers	Your phone or laptop
Recursive resolver	Does the work of finding the answer on your behalf and caches it for all its users	ISP resolver, 8.8.8.8, 1.1.1.1, 9.9.9.9
Root servers	Know which servers handle each top-level domain	The 13 root server identities (A to M), each served by many anycast sites
TLD servers	Know which servers handle each domain under a top-level domain	Servers for .com, .org, .uk, .de
Authoritative servers	Hold the actual records for a domain; give the final answer	The DNS service of the domain's owner or host

The root system has 13 named identities, A through M, but each is operated by many servers in hundreds of locations around the world using anycast, so there are well over a thousand physical instances. This keeps root lookups close to users.

How does a DNS lookup work step by step?

Suppose you open www.example.com and nothing is cached anywhere:

1. Local caches. The browser checks its own cache, then the operating system's. If either has an unexpired answer, the lookup ends there.
2. Ask the recursive resolver. The stub resolver sends a query to the configured resolver, typically in a single UDP packet to port 53.
3. Resolver cache. If another user of the same resolver recently looked up the name, the resolver replies from memory. For popular sites this is the usual case.
4. Ask a root server. Otherwise the resolver asks a root server about www.example.com. The root replies with a referral: "for .com, ask these servers". Resolvers also cache these referrals for a long time, so this step is usually skipped.
5. Ask a TLD server. The resolver asks a .com server, which replies with a referral to the authoritative servers for example.com.
6. Ask the authoritative server. That server returns the actual record, for example an A record with an IPv4 address.
7. Return and cache. The resolver gives the answer to your device and stores it for the TTL.

The resolver's work is called recursion; the individual steps from server to server, where each answer is a referral to the next, are iterative queries. Your device does not see them, it only sees the final answer.

DNS record types you will meet

Type	Purpose	Example value
A	Name to IPv4 address	203.0.113.10
AAAA	Name to IPv6 address	2001:db8::10
CNAME	Alias to another name	www.example.com to example.cdn.net
MX	Mail servers for the domain, with priority	10 mail.example.com
NS	Authoritative name servers for the zone	ns1.example.net
TXT	Free text: verification, SPF, DKIM, DMARC	"v=spf1 include:..."
SOA	Zone administration data, including the negative caching time	serial number, refresh timers
PTR	Reverse lookup: address to name	10.113.0.203.in-addr.arpa

A CNAME matters for speed: if www.example.com is an alias for a CDN's name, the resolver must follow the alias and look up the second name too, which can add a query to the chain. Content delivery networks use this to return a different address depending on who is asking, so that users are directed to a nearby server.

Caching and TTL: why DNS is usually fast

Every DNS answer carries a TTL, a number of seconds for which it may be reused. Typical values range from 60 seconds (for sites that change addresses often or use DNS for load balancing) to 86,400 seconds (one day) for stable records. Caches exist at four levels: the browser, the operating system, the home router (many routers run a small forwarding resolver) and the recursive resolver. A repeat visit to a site within the TTL does not use the network for DNS at all.

Failures are cached too. If a name does not exist, the resolver remembers that "negative" answer for a period set in the zone's SOA record, which prevents repeated lookups for names that are not there.

This is also why DNS changes are not instant. If you change an A record whose TTL was 3,600 s, resolvers that cached the old value just before the change may keep serving it for up to an hour. Planned migrations often lower the TTL a day in advance and raise it again afterwards.

How much latency does DNS add?

DNS delay depends on whether the answer is already cached and on the distance to the resolver.

Case	Typical time	Why
Browser or OS cache hit	Well under 1 ms	No network traffic
Resolver cache hit	Roughly 1 to 30 ms	One round trip to a nearby resolver
Uncached, referrals cached	Roughly 20 to 150 ms	The resolver asks the TLD and authoritative servers
Fully cold, distant authoritative server	Can exceed 200 ms	Several sequential round trips, possibly across continents

These ranges vary a lot by network. A page that pulls resources from many different domains (fonts, analytics, ads, CDNs) triggers a separate lookup for each one, and since lookups for new domains cannot be skipped, they can add up to a noticeable part of load time on first visit. For how this fits into the load sequence, see TTFB and web performance.

Choosing a DNS resolver

By default your router hands your devices the ISP's resolver address via DHCP. You can change it on the device or the router. The options differ in speed, privacy and features:

• ISP resolver: usually close to you, often fast for popular sites. Some ISPs redirect or log queries, and quality varies.
• Public resolvers such as Google Public DNS (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1) and Quad9 (9.9.9.9): large caches, anycast presence in many cities, and support for encrypted DNS. Quad9 blocks known malicious domains by default.
• Filtering or family-safe resolvers: block categories of sites at the DNS level.

One subtle point: a resolver far from you can send you to a CDN server that is far from you, since the CDN often guesses your location from the resolver's address. A very distant resolver can therefore slow the actual content as well as the lookup. Many large resolvers pass along a truncated client subnet (the EDNS Client Subnet option) to reduce this, although some privacy-focused ones deliberately do not.

Encrypted DNS: DoH and DoT

Classic DNS queries and answers travel in plain text, usually over UDP port 53 and falling back to TCP for large answers. Anyone on the path can read or alter them. DNS over TLS (DoT), normally on port 853, and DNS over HTTPS (DoH), on port 443 and looking like ordinary web traffic, encrypt the link between your device and the resolver. They protect against local snooping and tampering but do not make you anonymous to the resolver. DNSSEC is a different feature: it signs records so a resolver can check that answers have not been forged, but does not encrypt anything.

Encrypted DNS needs a TCP and TLS connection to the resolver, which costs a few round trips the first time. Because the connection is reused for later queries, the long-term overhead is small.

Worked examples

Example 1: First visit versus second visit

Your resolver is 15 ms away. You visit a site with no cache entries anywhere. The resolver already has the .com referral cached, so it needs one query to the authoritative server, 40 ms away from it. Your lookup time is 15 ms (to the resolver) plus 40 ms (resolver to authoritative server) = 55 ms. A minute later you visit again: the browser answers from its own cache in well under 1 ms. A different user on the same resolver gets the cached answer in about 15 ms.

Example 2: A page with eight third-party domains

A page loads files from its own domain and eight others. If each needs a fresh lookup at around 30 ms, that is 240 ms of DNS work. Browsers do these in parallel, so the delay on the page is smaller, but each domain also needs its own connection setup, and the first critical ones still delay rendering. Reducing the number of distinct domains is a known web performance tactic.

Example 3: Waiting for a change to take effect

You change a website's A record at 12:00. The record had TTL 3,600 s. A resolver that fetched the old value at 11:59 can keep serving it until 12:59. A resolver that fetched it at 11:00 will already have refreshed at 12:00. So over the next hour, different people see different results, and everyone sees the new address by 13:00 at the latest, unless some software ignores TTL and keeps records longer.

Example 4: Telling DNS apart from connection problems

The browser says it cannot find a server. On the command line, nslookup example.com or dig example.com returns an address, but ping to that address fails. The name resolution works; the problem is reachability. If the lookup itself fails but pinging a known address such as 1.1.1.1 works, the fault is DNS, and switching resolver should fix it.

DNS and latency measurement

DNS affects how latency numbers should be read. When a tool times a request to a hostname, the first request includes the DNS lookup plus the connection setup; later requests may reuse the cached answer and an open connection. The GlobeLatency test measures real HTTPS requests from your browser, so a destination's first pass can include DNS, TCP and TLS setup, and the best pass is often a little lower than the first. Its live map also uses DNS: it resolves each destination's hostname through Google's public resolver (dns.google) to find where the server is and then looks up the address in a geolocation database. For CDN and anycast destinations, the answer depends on where the lookup is done from, so a pin shows where the lookup resolved, not necessarily where the company is based.

Common mistakes and myths

• "Faster DNS gives me faster internet." It speeds up the first connection to each new name only. Downloads, streaming and game traffic are unaffected once the address is known.
• "DNS propagation takes 48 hours." It takes as long as the old TTL, which is often minutes to a few hours. Some registry-level changes (such as changing name servers) can take longer because of their own TTLs.
• "If a site will not load, DNS must be broken." Many failures are connection, server or firewall problems. Check whether the name resolves with nslookup or dig first.
• "A public resolver always beats my ISP." Not necessarily. A nearby ISP resolver can be faster, and a distant public resolver might send you to a slower CDN node. Measure instead of assuming.
• "A VPN or DoH hides everything." They hide DNS from the local network, but the resolver or VPN operator can still see queries.
• Forgetting the local caches. After a DNS change, the browser or OS may still hold the old answer. Flushing the cache, for example with ipconfig /flushdns on Windows, fixes it on your own machine.

What to do next

If you want the bigger picture, read how the internet works. The step after name lookup is opening a connection, explained in TCP and UDP explained. To see why content delivery networks rely on DNS tricks, read CDN and anycast. To measure how your connection performs to destinations worldwide, run a free latency test, and if pages feel slow to start, check TTFB and web performance.