DNS lookups

Every new hostname starts with a lookup

You typed completefrontend.com, or clicked a link to it, and this page appeared. It felt like one step. But your browser couldn't send a single byte to "completefrontend.com". The internet doesn't deliver to names. It delivers to numbers.

So before anything else, the browser had to find the number behind the name. That number is an IP address, like 199.36.158.100. Finding it is called a DNS lookup. DNS, the Domain Name System, is the internet's shared phone book: a list of names and the numbers they belong to.

A hostname is the name part of a web address: the part between https:// and the next slash. In https://fonts.gstatic.com/s/inter.woff2, the hostname is fonts.gstatic.com. Every hostname needs its own lookup.

Here is the answer the course got when it looked up this site's name:

1// The answer the course got for this site's name.2const answer = { name: "completefrontend.com", address: "199.36.158.100", ttl: 3600 };3 4console.log(`${answer.name} lives at ${answer.address}.`);5console.log(`Keep this answer for ${answer.ttl} seconds.`);

• Line 1 is a comment. It says where the answer came from.
• Line 2 holds the recorded answer: the name, its IP address, and a number called the TTL.
• Line 4 prints completefrontend.com lives at 199.36.158.100.
• Line 5 prints Keep this answer for 3600 seconds. That's one hour. Every answer says how long it stays good. The section on TTLs explains why that matters.

So how long did the lookup take? It depends on where the browser found the answer. Sometimes a lookup takes no time at all. Sometimes it takes more than a quarter of a second. Here is every place the browser can look, nearest first:

• On your device. The browser and the operating system each keep a short list of names they looked up recently. If the name is there, the lookup is free.
• At your network's resolver. This is a server that looks names up for you. Asking it costs one round trip.
• On the walk from the root. If the resolver doesn't know either, it asks other servers, one after another. Each one costs another round trip.

Why does this matter? Latency vs bandwidth showed that round trips, not megabits, decide how fast most pages load. A lookup is one round trip, or several, before the first request to a host can even start. The system design lesson DNS, CDNs, and the edge follows a name to a nearby server. This lesson measures what each lookup costs a page.

How a lookup is resolved and cached

Here is one lookup of completefrontend.com, followed from the nearest place to the farthest.

First, the places that remember

The browser starts close to home. It checks its own cache: a short list of answers it kept from earlier lookups. Then it asks the operating system, which keeps a cache for every program on the device. Neither of these needs the network.

If neither has the name, the device asks a resolver. A resolver is a server whose job is to look names up for other computers. Your internet provider runs one. There are also public ones anyone can use, like Cloudflare's 1.1.1.1. The resolver keeps a big cache of its own, shared by everyone who uses it. If anyone asked for the name a little while ago, it answers at once.

Read this table from top to bottom. It's the order the browser tries, and each row costs more than the one above it:

When nobody knows: the walk from the root

What does the receptionist do when the number isn't in her notebook? She doesn't phone every office in the world. She reads the name from right to left.

Take completefrontend.com. Its last part, .com, is called the top-level domain. A resolver that has nothing cached asks three kinds of server, in this order:

• A root server. It doesn't know any addresses. It only knows who looks after each top-level domain, like .com.
• A .com server. It doesn't know the address either. It knows which servers look after completefrontend.com.
• The site's own name server. This server holds the site's DNS entries, so it gives the real answer.

Each server is like an office that doesn't know the number, but knows which office does. A lookup that a cache can't answer is called a miss. The course did this walk itself, with a tool called dig, the way a resolver does on a miss. Here is what each server said:

1// The walk for this site's name, one server after another.2const walk = [3  { asked: "A root server", said: "ask the .com servers" },4  { asked: "A .com server", said: "ask completefrontend.com's own name servers" },5  { asked: "completefrontend.com's name server", said: "the address is 199.36.158.100" },6];7 8for (const step of walk) console.log(`${step.asked} said: ${step.said}.`);

• Lines 3 to 5 are the three recorded steps, in order. Each one says who was asked and what they said.
• Line 8 prints one sentence for each step.
• The first is A root server said: ask the .com servers.
• The second is A .com server said: ask completefrontend.com's own name servers.
• The third is completefrontend.com's name server said: the address is 199.36.158.100.

Only the last server knew the address. The first two only knew who to ask next. Each step was a round trip of its own, and the next one couldn't start until it came back. So the times add up:

1// How long each server took to answer, in milliseconds (ms).2const root = 126;3const dotCom = 53;4const siteServer = 80;5 6const walkTime = root + dotCom + siteServer;7console.log(`The whole walk took ${walkTime} ms.`);

• Lines 2 to 4 hold how long each server took to answer, as the course recorded them.
• Line 6 adds them up. Line 7 prints The whole walk took 259 ms.

That's more than a quarter of a second, and the browser hasn't started connecting yet. It's also about the longest the walk gets. A resolver keeps the root's and .com's answers in its cache too, so a miss can often skip the first steps. Google Public DNS says a resolver rarely has to ask more than two name servers.

The last step can't be skipped: only the site's own name server has the answer. Here, it took 80 ms. That's why the company that runs your name servers matters. The next section comes back to it.

Why the same name is fast one time and slow the next

So a lookup costs nothing, one round trip, or a walk. Which one do your visitors get? You might expect a big public resolver to always have your name. The course tested that. It asked 1.1.1.1 for completefrontend.com ten times in a row:

1// completefrontend.com, asked ten times in a row through the public resolver 1.1.1.1.2const times = [24, 390, 36, 8, 107, 132, 12, 25, 21, 89];3 4console.log(`The fastest answer took ${Math.min(...times)} ms.`);5console.log(`The slowest answer took ${Math.max(...times)} ms.`);

• Line 2 holds the ten recorded times, in the order they came back.
• Line 4 prints The fastest answer took 8 ms.
• Line 5 prints The slowest answer took 390 ms.

Same name, same resolver, asked one after another. Yet the slowest answer took almost 50 times as long as the fastest. Even www.google.com, a name every resolver surely has, took anywhere from 9 to 110 ms.

Why? Google's Public DNS team explains it. A big resolver isn't one machine. It's many machines behind a load balancer, which hands each question to one of them at random. Each machine keeps its own cache. So the machine that answers you may not be the one that remembered your name.

Back in the office, it's like a front desk with ten receptionists, each with her own notebook. Whether you wait depends on who you happen to ask.

Google also measured what a miss costs. Its web crawler sees 130 ms on average to look up a name, when the servers answer. Some messages get lost on the way, and some servers never reply. Counting those, the real average is 300 to 400 ms. So you can't count on a lookup being cached, even for a popular name. Plan for the slow case.

Try it yourself. Pick where the answer is, and see how many trips over the network the lookup needs:

TTLs and DNS providers

Back to the receptionist's notebook. How long should she trust a number she wrote down? If the shop moves, an old number is worse than none.

DNS answers this with a TTL, short for time to live. Every answer carries one. It says how many seconds any cache may keep the answer. After that, the cache must throw it away and ask again. This site's answer said 3600 seconds: one hour.

Here is the same thing over time, for one cache that's asked for the same name again and again:

Each tall bar is a miss: a slow lookup that pays for the walk. Each short bar is a hit: the cache had the answer, so it came back at once. A cache that's asked all the time misses once per TTL. So the TTL decides how often your name server gets asked:

1// This site's answer had a TTL of 3600 seconds: one hour.2const ttl = 3600;3const secondsInADay = 24 * 60 * 60;4 5const asksPerDay = secondsInADay / ttl;6console.log(`A busy cache asks again ${asksPerDay} times a day.`);

• Line 2 is this site's TTL, in seconds.
• Line 3 works out how many seconds there are in a day: 86,400.
• Line 5 divides the day by the TTL. Line 6 prints A busy cache asks again 24 times a day.

Now make the TTL one minute:

1// A TTL of 60 seconds: one minute.2const ttl = 60;3const secondsInADay = 24 * 60 * 60;4 5const asksPerDay = secondsInADay / ttl;6console.log(`A busy cache asks again ${asksPerDay} times a day.`);

• Besides the comment, only line 2 changes: a TTL of 60 seconds.
• Line 6 prints A busy cache asks again 1440 times a day.

That's 60 times as many misses. Each one is a visitor who waits for the walk. Google's DNS team notes that sites are choosing shorter TTLs, and that this means more lookups.

So why not always choose a long TTL? Remember the old number in the receptionist's notebook. If you move your site to a new address, caches keep sending visitors to the old one until their TTL runs out. Read this table across: each row is one choice, what you get, and what it costs.

Who answers on a miss: your DNS provider

On a miss, the last step of the walk is your site's own name server. The company that runs it is your DNS provider. Its speed is your visitors' wait. In the recorded walk, this site's provider answered in 80 ms. The farther the provider's servers are from the resolver, the longer that step takes. Google Public DNS lists "authoritative servers" that are "geographically remote" as a cause of slow misses.

Notice what you can and can't choose. You choose your DNS provider and your TTL. You don't choose your visitors' resolvers. They use their internet provider's, or a public one they picked.

dns-prefetch and preconnect

So far, every lookup happened at the moment the browser needed it. Could it happen earlier, before anything has to wait for it?

Picture the tea shop's page. Its heading uses a font from fonts.gstatic.com. But the browser finds that out late. First it reads the HTML. Then it downloads the stylesheet. Only then does it see the font, and start looking up fonts.gstatic.com. All that time, the heading waits for its font.

A page can give the browser the same head start, with resource hints: lines in the page's head that tell the browser what it will need soon. They're hints, not orders. A busy browser may skip one.

dns-prefetch asks for the lookup only. Use it for hosts the page will need later:

1<head>2  <!-- Hosts the tea shop needs later: look up their addresses now. -->3  <link rel="dns-prefetch" href="https://analytics.example.com">4  <link rel="dns-prefetch" href="https://videos.example.com">5</head>

• Line 2 is a comment. The tea shop needs these two hosts later, not right away.
• Lines 3 and 4 each ask the browser to look one host up now. When the page later loads a file from that host, the answer is already in the cache.

preconnect goes further. It does the lookup, then opens the connection and sets up TLS. TLS is the step that makes the connection private: the S in HTTPS. Use preconnect for one or two hosts the page needs right away, like the heading's font:

1<head>2  <!-- The heading's font comes from here: get the whole line ready now. -->3  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>4</head>

• Line 3 asks the browser to set up the whole connection to fonts.gstatic.com now.
• It ends with crossorigin. Browsers fetch fonts in a special mode, called anonymous mode. A preconnect only helps if it's made in the same mode, so a font host needs crossorigin. Without it, the browser only does the lookup.

Here is what each hint moves. Each row loads the font, measured in round trips:

With no hint, the lookup, the connection, TLS and the font request all wait until the stylesheet names the font. With dns-prefetch, the lookup is already done. With preconnect, only the font request is left. The work doesn't disappear. It moves into time the page was spending waiting anyway.

Read this table across to choose a hint. Each row says what the hint does early, and what it's for:

A few rules keep hints from backfiring. They come from web.dev and MDN:

• Preconnect to one or two hosts, not ten. web.dev says the browser closes any connection that isn't used within 10 seconds. Extra connections can also delay more important files.
• Don't hint your own hostname. MDN explains why: the browser looked it up before it could read the hint.
• Give each hint its own tag. Writing rel="preconnect dns-prefetch" in one <link> cancels the preconnect in Safari.
• A hint can come from the server too. Both work as an HTTP Link header, which the browser can act on before it reads any HTML.

Browsers also guess some lookups on their own. Ilya Grigorik describes them looking up likely hostnames from your browsing history, or when you hover over a link. A hint is for the hosts the browser can't guess. Resource hints covers these two hints and three more.

HTTPS DNS records for faster HTTP/3

A lookup usually brings back one thing: an address. Could it tell the browser more?

Here's why that would help. HTTP/3 is the newest version of HTTP, the language browsers and servers speak. It runs over a newer kind of connection, called QUIC. HTTP/3 and QUIC shows what it gains. But a browser can only use HTTP/3 if it knows the server speaks it.

How does it find out? Usually the server says so in a response header, Alt-Svc. Cloudflare's engineers point out the catch: that header only arrives after the browser has already connected. So the first connection uses an older version. Only later connections can use HTTP/3.

An HTTPS record is that phone book entry. It tells the browser how to connect, before it connects. RFC 9460 made it a standard in 2023. A record is one entry in DNS: a name, a type, and its data. The address you met earlier came from an A record, the type that holds an address.

Here is the HTTPS record the course looked up for cloudflare.com, cut to one address of each kind:

1// cloudflare.com's HTTPS record, with one address of each kind.2const record = "1 . alpn=h3,h2 ipv4hint=104.16.132.229 ipv6hint=2606:4700::6810:84e5";3const names = { h3: "HTTP/3", h2: "HTTP/2" };4 5const alpn = record.split(" ").find((part) => part.startsWith("alpn="));6const protocols = alpn.replace("alpn=", "").split(",");7console.log(`It speaks ${protocols.map((protocol) => names[protocol]).join(" and ")}.`);

Line 2 is the record. Read it from left to right:

• 1 is its priority. A name can have several records, and the browser tries the lowest number first.
• . means "this same name": connect to cloudflare.com itself.
• alpn=h3,h2 lists the protocols the site speaks. h3 is HTTP/3, and h2 is HTTP/2.
• ipv4hint and ipv6hint are addresses. The browser can start connecting without waiting for a separate address lookup.

The rest of the code reads the protocols:

• Line 3 gives each protocol code a readable name.
• Line 5 finds the part that starts with alpn=. Line 6 splits it into h3 and h2.
• Line 7 prints It speaks HTTP/3 and HTTP/2.

completefrontend.com had no HTTPS record when the course looked. So browsers learn this site's protocols the older way, from the reply.

For a site that speaks HTTP/3, an HTTPS record lets even a visitor's first connection use it. You don't always have to write one by hand. Cloudflare, for example, publishes one by itself for the sites it serves, with HTTP/3 in it when a site turns HTTP/3 on.

Counting hostnames on a page

So far, one hostname. But a page rarely uses just one. Its fonts, scripts, pictures and ads often come from other hosts. Each new hostname is one more lookup, and usually one more connection too.

It's like a shopping list. Five things from one shop is one trip. Five things from five shops is five trips, even if each trip is short.

How many hosts does a real page use? The Web Almanac 2024 counted third parties: companies other than the site itself, such as analytics, ads or fonts. Line up the top million sites, and the page in the middle used 27 of them. Among the top thousand sites, the page in the middle used 66. Each third party brings at least one hostname of its own.

To count a page's hostnames, take each file's address and keep its hostname. JavaScript's URL does that for you:

1const fontFile = new URL("https://fonts.gstatic.com/s/inter/v13/inter.woff2");2 3console.log(`This file comes from ${fontFile.hostname}.`);

• Line 1 turns the font file's address into a URL object, which splits the address into parts.
• Line 3 prints its hostname part: This file comes from fonts.gstatic.com.

Now do it for every file on the tea shop's page:

1// Every file the tea shop's page loads.2const files = [3  "https://shop.example.com/",4  "https://cdn.example.net/app.js",5  "https://fonts.googleapis.com/css2?family=Inter",6  "https://fonts.gstatic.com/s/inter/v13/inter.woff2",7  "https://cdn.example.net/hero.jpg",8  "https://www.googletagmanager.com/gtag/js",9];10 11const hosts = new Set(files.map((file) => new URL(file).hostname));12console.log(`${files.length} files come from ${hosts.size} hostnames.`);

• Lines 3 to 8 are the page's six files.
• Line 11 turns each file into its hostname and puts them in a Set. A Set keeps each value only once, so two files from cdn.example.net count as one host.
• Line 12 prints 6 files come from 5 hostnames.

Notice that Google Fonts alone needs two hosts. The stylesheet comes from fonts.googleapis.com, and the font files from fonts.gstatic.com. That's two lookups and two connections for one font.

Now count this page's own hostnames, in your own browser:

1const hosts = new Map();2for (const file of performance.getEntriesByType("resource")) {3  const host = new URL(file.name).hostname;4  hosts.set(host, [...(hosts.get(host) ?? []), file]);5}6 7for (const [host, files] of hosts) {8  const dns = files[0].domainLookupEnd - files[0].domainLookupStart;9  show(host, files.length, dns);10}

In the panel's code:

• Line 3 finds each file's hostname. Line 4 adds the file to that host's group.
• Line 8 reads the lookup time of the host's first file. Later files from the same host reuse its answer.

Some hosts may say "hidden". The browser only shares another site's timing if that site allows it, with a Timing-Allow-Origin header.

Fewer hostnames mean fewer lookups and fewer connections. Serve what you can from your own host. For each new third party, ask whether it's worth the trip.

Which hint, if any?

Here are seven hosts a page might use. Each needs a different hint, or none. For each one, ask two questions. Does the page need it right away? And will most visits use it at all?

Common mix-ups

• "DNS is only slow on bad networks." No. A miss walks from server to server on any network. The recorded walk took 259 ms.
• "Once a name is looked up, it's cached for everyone." No. A big resolver is many machines, each with its own cache. And every answer expires when its TTL runs out.
• "Preconnect to every third party." No. The browser closes a connection it doesn't use within 10 seconds, and extra connections can delay important files.
• "A preconnect to a font host works without crossorigin." No. Fonts are fetched in anonymous mode. Without crossorigin, the browser only does the lookup.
• "dns-prefetch for my own hostname speeds it up." No. The browser looked it up before it could read the hint.
• "A longer TTL is always better." No. You get fewer misses, but a new address takes that long to reach everyone.
• "Browsers always use HTTP/3 when a site supports it." Not on the first connection, unless an HTTPS record says so.

Practice exercises

Answer first, then use the hints.

// A TTL of 30 seconds.
const ttl = 30;
const secondsInADay = 24 * 60 * 60;

const asksPerDay = secondsInADay / ttl;
console.log(`A busy cache asks again ${asksPerDay} times a day.`);

// Every file the tea shop's page loads.
const files = [
  "https://shop.example.com/",
  "https://cdn.example.net/app.js",
  "https://fonts.googleapis.com/css2?family=Inter",
  "https://fonts.gstatic.com/s/inter/v13/inter.woff2",
  "https://cdn.example.net/hero.jpg",
  "https://www.googletagmanager.com/gtag/js",
  "https://cdn.example.net/logo.svg",
  "https://player.example.org/embed.js",
];

const hosts = new Set(files.map((file) => new URL(file).hostname));
console.log(`${files.length} files come from ${hosts.size} hostnames.`);

// The HTTPS record of a site that only speaks HTTP/2.
const record = "1 . alpn=h2 ipv4hint=192.0.2.10";
const names = { h3: "HTTP/3", h2: "HTTP/2" };

const alpn = record.split(" ").find((part) => part.startsWith("alpn="));
const protocols = alpn.replace("alpn=", "").split(",");
console.log(`It speaks ${protocols.map((protocol) => names[protocol]).join(" and ")}.`);

Check your understanding

For each question, ask where the answer comes from, and whether the lookup is still in the way.

Key takeaways

• Every new hostname needs a lookup before the browser can connect to it.
• The browser looks nearest first: its own cache, the system's, then the resolver's. Only on a miss does the walk from the root begin.
• The recorded walk took 259 ms. Google measures 300 to 400 ms on average for a miss, once failures are counted.
• A big resolver is many machines with separate caches, so the same name can be fast one time and slow the next.
• The TTL decides how long caches keep an answer. Short means more misses. Long means slower changes.
• Preconnect one or two critical hosts, dns-prefetch the rest, and never hint your own.
• An HTTPS record lets even the first connection use HTTP/3.
• Count your page's hostnames, and cut the ones it doesn't need.

Sources

The facts on this page come from these docs, standards and data:

• Primer on Web Performance (DNS, TCP and TLS before the first byte), High Performance Browser Networking, Ilya Grigorik.
• Performance: causes and mitigations of DNS latency, Google Public DNS.
• 1.1.1.1 (DNS Resolver), Cloudflare.
• Using dns-prefetch, MDN.
• Establish network connections early to improve perceived page speed, web.dev.
• RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS records), IETF.
• Speeding up HTTPS and HTTP/3 negotiation with... DNS, Cloudflare.
• Third Parties, Web Almanac 2024, HTTP Archive.
• PerformanceResourceTiming: domainLookupStart, MDN.
• RequestTimingView.ts: the Network panel's Timing tab, Chrome DevTools source.

Coming next: TCP connections and slow start. After the lookup comes the connection. A new TCP connection starts by sending a little, then more and more. That's why the first 14 KB of a page matter.