Type bbc.com into a browser and press Enter. Before the browser can contact the site, it usually needs DNS to turn that name into one or more network addresses.
The lookup may be almost invisible because the answer is already cached nearby. If it is not, a recursive resolver may have to follow referrals through the DNS hierarchy before it can return an address.
That distinction matters because a cached answer and a full recursive lookup are not the same journey. The first can return in milliseconds, while the second adds several network trips and may take tens or hundreds of milliseconds depending on distance, congestion, packet loss and server response.
The first answer may already be on the device
DNS resolution does not always begin on the open internet. Depending on the browser, operating system and network configuration, the device may first check a browser cache, an operating-system cache or a local hosts file.
If a usable answer is already there, no DNS packet needs to leave the machine. The DNS portion of a repeat visit can therefore end before the router sees anything.
When the local caches are empty, the operating system normally sends a query to the recursive resolver configured for that connection. A home router may act as a forwarding stop, but some devices contact an ISP resolver or a public service such as Google Public DNS, Cloudflare or Quad9 directly.
The original DNS design separates the small resolver on the user’s machine from the servers that search the distributed namespace. That division, described in RFC 1034, lets the recursive resolver perform the wider search and return the result to the device.
The recursive resolver does the searching
A recursive resolver is the part that does the running around. It receives a question such as “What address record is available for bbc.com?” and first checks its own cache.
Each cached record has a time-to-live, or TTL, attached to it. RFC 1035 defines TTL as a value that tells caches how long a record may be retained before it must be refreshed.
Popular names can be requested repeatedly while their records remain valid, so one successful lookup may serve many later users. Obscure names, short TTLs and recently changed records are more likely to produce cache misses.
This is why there is no honest universal promise that DNS “usually” finishes below one fixed number. Google’s own discussion of DNS latency says cache misses add considerable delay and that network distance, congestion, packet loss and slow name servers all affect the result.
A cache miss may climb from the root
If the resolver lacks both the final record and the referrals needed to reach it, it can begin at the DNS root. The root server does not know the address of every website, and it does not perform the rest of the lookup for the resolver.
Instead, the root returns a referral to the servers responsible for the relevant top-level domain. For bbc.com, that means directing the resolver toward the .com name servers.
The .com servers then return a referral to the authoritative name servers for bbc.com. One of those authoritative servers can provide the requested record, or another step such as a CNAME alias that the resolver must follow.
The root itself is represented by 13 named authorities, A through M, rather than 13 physical machines. The IANA root-server list identifies the 13 names and the 12 organisations that operate them.
Behind those names is a worldwide anycast system. As of August 4, 2026, root-servers.org listed 2,002 operational instances, allowing the same root-server identity to be announced from many locations.
Anycast makes one name exist in many places
Anycast lets multiple servers advertise the same IP address from different networks. Internet routing then carries a query toward an available instance according to the routing system’s view of the best path, which is often nearby in network terms but not necessarily the geographically closest building.
This arrangement reduces distance and spreads load without changing the resolver’s root hints. The operational model is described in RFC 4786.
The number 13 is also a protocol-history artifact, not a limit on the number of machines. ICANN’s Root Server System Advisory Committee FAQ explains that adding more named root servers would once have pushed a priming response beyond the original 512-byte DNS-over-UDP limit.
Modern DNS can carry larger messages using the extension mechanism defined in RFC 6891, and DNS implementations also support TCP when needed. The 13 names remained, while anycast multiplied the physical infrastructure behind them.
Small packets make the common case fast
A traditional DNS question is compact, often asking for an A record for IPv4 or an AAAA record for IPv6. A small query and response can fit into one UDP datagram, avoiding the connection setup required by TCP.
That does not mean every lookup is one packet or one round trip. DNSSEC signatures, long record sets, aliases, retries and encrypted transports can all make the exchange larger or add steps.
Readers who want to see the records directly can use Make Tech Easier’s guide to querying DNS with nslookup. The tool can reveal A, AAAA, MX, CNAME and other records returned for a domain.
The practical speed comes from layering compact messages, distributed servers and caches at several levels. When a needed record is already fresh, the hierarchy stays quiet; when it is missing, the resolver performs the longer search and then stores the result for later queries.
The lookup can be fast without being private
Traditional DNS over UDP or TCP is normally unencrypted, so a network operator between the device and resolver can inspect the domain being requested. HTTPS may protect the later page content, but it does not retroactively hide a plaintext DNS question.
DNS over HTTPS encrypts the connection between the client and its chosen resolver using the method standardised in RFC 8484. The resolver still receives the query, but observers on the local network cannot simply read it from a plaintext DNS packet.
Make Tech Easier has separate guides to enabling DNS over HTTPS in browsers and changing DNS providers on Android and iPhone. Those choices change who handles the query and whether the path to that resolver is encrypted.
Paul Mockapetris published the original DNS concepts and implementation specifications in November 1983 in RFC 882 and its companion specification. More than four decades later, the same basic choreography still begins whenever a device needs to turn a name into an address.
Most of the time, the answer comes from somewhere close and the deeper hierarchy never moves. When the caches are empty, the question descends from the root to the domain’s own servers, then returns carrying the address the browser needed before it could open the connection.