DNS Speed Test

What Is DNS

DNS stands for Domain Name System. Think of it as the phone book of the internet. When you type a website address like example.com into your browser, that name is meaningless to the computers that actually deliver web pages. They speak in numbers — IP addresses like 93.184.216.34. DNS is the system that translates the human-friendly name into the machine-friendly number.

Without DNS, you would have to memorize the IP address of every website you want to visit. Want to check your email? Type 142.250.80.46 instead of gmail.com. Want to watch a video? Type 208.65.153.238 instead of youtube.com. The internet as we know it would not exist.

DNS is not one server sitting in a closet somewhere. It is a massive, distributed system of thousands of servers spread across the globe, working together in a hierarchy. Every time you visit a website, multiple servers cooperate to find the right IP address — and the whole thing happens in milliseconds. By the time you notice a page loading, DNS has already done its job.

The system was invented in 1983 by Paul Mockapetris, and it has been quietly running the internet ever since. Most people never think about DNS until something goes wrong. But understanding how it works gives you real power over your browsing speed, privacy, and security.

The DNS Resolution Process — Step by Step

When you type a URL into your browser and hit Enter, a chain of events begins. The process is called DNS resolution, and it follows a specific sequence of checks and queries. Here is exactly what happens.

Step 1: Browser Cache Check

Your browser is the first place it looks. Modern browsers maintain their own DNS cache — a temporary storage of recently resolved domain names. If you visited example.com five minutes ago, the browser already knows its IP address and skips the entire lookup process. This check takes less than a millisecond. The cached entry sticks around based on the TTL (Time to Live) value set by the domain's DNS records. After the TTL expires, the browser discards the entry and starts fresh.

Step 2: Operating System Cache Check

If the browser does not have the answer, it asks the operating system. Your OS maintains its own DNS cache, separate from the browser. On Windows, this is handled by the DNS Client service. On macOS, it is mDNSResponder. On Linux, it is systemd-resolved or nscd. The OS cache is shared across all applications on the device, so if another app recently resolved the same domain, the answer is already sitting there. This check also takes less than a millisecond.

Step 3: Recursive Resolver Query

If nothing is cached locally, the OS sends the query to your configured recursive DNS resolver. This is the server your device talks to directly. It is usually provided by your ISP (assigned automatically via DHCP), but you can also configure it to use a public resolver like Cloudflare 1.1.1.1 or Google 8.8.8.8. The recursive resolver is where the real work begins. Its job is to find the answer, no matter how many servers it has to ask.

Step 4: Root Server Query

The recursive resolver does not know the answer off the top of its head (unless it is cached). It starts at the top of the DNS hierarchy: the root servers. There are 13 root server clusters in the world, designated A through M, though each cluster actually consists of hundreds of servers distributed globally using anycast routing. The resolver asks a root server: "Who handles .com domains?" The root server does not know the specific IP for example.com. But it knows who is in charge of all .com domains. It responds with the address of the appropriate TLD (Top-Level Domain) server and sends the resolver on its way.

Step 5: TLD Server Query

The resolver now queries the TLD server for .com (or .org, .net, .uk — whatever the domain's extension is). The TLD server manages all domains under that extension. It does not know the IP address for example.com either. But it knows which authoritative name server is responsible for that domain. It responds with something like: "The name server for example.com is ns1.exampledns.com." The resolver now has its next target.

Step 6: Authoritative Server Query

The resolver contacts the authoritative name server for the specific domain. This server is the final authority. It holds the actual DNS records for example.com — the A record that maps to 93.184.216.34, the MX record for email, the TXT records, and everything else. The authoritative server responds with the IP address. The resolver now has the answer.

Step 7: Response Back to the Browser

The recursive resolver takes the IP address and sends it back to the operating system. The OS passes it to the browser. The browser now has the IP address it needs to connect to the web server. It opens a TCP connection to that IP address, sends the HTTP request, and starts downloading the page. The entire DNS resolution process — from cache check to IP address — typically takes between 20 and 100 milliseconds for an uncached domain. For cached lookups, it takes less than 1 millisecond.

After receiving the answer, the resolver caches it locally based on the TTL value. The next time anyone on the same network asks for example.com, the resolver can answer immediately without repeating the entire chain. This caching is what makes DNS fast in practice. Without it, every single page load would require multiple round trips to root servers and TLD servers.

DNS Server Types

Not all DNS servers do the same thing. The system relies on several distinct server types, each with a specific role. Understanding the difference helps you make sense of how a lookup actually works.

Recursive Resolvers

This is the server your device talks to directly. It is the workhorse of the DNS system. When you ask for a domain name, the recursive resolver does all the legwork — querying root servers, TLD servers, and authoritative servers on your behalf. It caches results so subsequent lookups for the same domain are instant. Your ISP provides one by default, but you can configure your device to use public resolvers like Cloudflare 1.1.1.1, Google 8.8.8.8, or Quad9 9.9.9.9 instead. The performance of your recursive resolver directly affects your browsing speed.

Root Servers

Root servers sit at the top of the DNS hierarchy. There are 13 root server clusters (named a.root-servers.net through m.root-servers.net), but each cluster contains hundreds of servers distributed across the globe using anycast routing. Root servers do not resolve domain names directly. They point recursive resolvers toward the correct TLD server. If a root server goes down, it does not matter — the anycast system routes traffic to the nearest available instance.

TLD Servers

Top-Level Domain servers manage everything under a specific extension. The .com TLD server handles all .com domains. The .org TLD server handles all .org domains. Country-code TLD servers like .uk or .de handle domains for specific countries. When a TLD server receives a query, it responds with the address of the authoritative name server for the specific domain. TLD servers are operated by organizations like Verisign (.com, .net), Public Interest Registry (.org), and various country-code registries.

Authoritative Name Servers

Authoritative servers are the final word on a domain's DNS records. They hold the actual data — the A records, AAAA records, MX records, CNAME records, and everything else. When an authoritative server receives a query, it responds with the answer directly. It does not query other servers. If it does not have a record, it says so. Domain owners configure their authoritative name servers through their registrar, and those servers are what the rest of the DNS system ultimately relies on.

How DNS Caching Works

DNS caching is the single most important performance optimization in the entire system. Without caching, every page load would require multiple round-trip queries across the globe. Caching eliminates that overhead by storing answers at multiple levels.

TTL — Time to Live

Every DNS record has a TTL value, measured in seconds. This tells caching servers how long they should keep the answer before asking again. A TTL of 3600 means the answer can be cached for one hour. A TTL of 300 means five minutes. Domain owners set TTL values based on how often their records change. Records that rarely change (like MX records for email) often have high TTLs. Records that change frequently (like failover configurations) have low TTLs.

Browser Cache

Your browser maintains its own DNS cache as the first line of defense. Chrome, Firefox, Safari, and Edge all cache DNS results locally. The browser cache has the lowest latency — typically under 1 millisecond — because the data is stored in memory. Different browsers have different cache durations, but they generally respect the TTL value from the DNS record. When the TTL expires, the browser discards the entry and re-queries on the next visit.

OS Cache

The operating system maintains a second cache layer shared by all applications. On Windows, the DNS Client service stores results. On macOS, mDNSResponder handles caching. On Linux, systemd-resolved or nscd manages the cache. The OS cache typically has a slightly higher latency than the browser cache but still responds in under 1 millisecond. Flushing the DNS cache clears entries at this level. See our guide on how to flush DNS cache for platform-specific instructions.

Router Cache

Many home routers maintain their own DNS cache. When any device on your network resolves a domain, the router caches the result. Subsequent requests from any device on the same network hit the router cache first, which can save a trip to the recursive resolver. Router cache durations vary by manufacturer, but most use a default TTL of around 300 to 600 seconds. Restarting your router clears its cache.

Resolver Cache

Your recursive resolver maintains the largest and most important cache. When it resolves a domain for the first time, it stores the answer and serves it to every client that asks. In a busy office or ISP, the resolver cache might serve thousands of users from a single cached entry. Resolver caches typically hold entries for the duration specified by the TTL, though some resolvers may override very short TTLs with a minimum floor (often 300 seconds) to reduce load on authoritative servers.

The layered nature of DNS caching means that most DNS lookups you perform during normal browsing never go beyond your browser or OS cache. Only the first visit to a domain (or the first visit after a TTL expires) triggers a full recursive lookup. This is why DNS is so fast in practice — the system is designed to avoid repeated queries.

DNS Record Types

DNS is not just about mapping domain names to IP addresses. The system supports several record types, each serving a different purpose. Here are the ones you are most likely to encounter.

A Record (Address)

The A record maps a domain name to an IPv4 address. This is the most fundamental DNS record type. When you look up example.com and get 93.184.216.34, that answer came from an A record. Every domain that has a website needs at least one A record.

AAAA Record (IPv6 Address)

The AAAA record (pronounced "quad-A") maps a domain name to an IPv6 address. As IPv4 addresses run out, more domains are adding AAAA records alongside their A records. IPv6 addresses look like 2606:2800:220:1:248:1893:25c8:1946 — longer and more complex than IPv4, but necessary for the future of the internet.

CNAME Record (Canonical Name)

A CNAME record points one domain name to another domain name, creating an alias. For example, www.example.com might have a CNAME record pointing to example.com. This means when you look up www.example.com, the DNS system first resolves example.com, then returns that IP address. CNAMEs are commonly used for subdomains that point to the same server as the main domain.

MX Record (Mail Exchange)

MX records tell email servers where to deliver email for a domain. If you send an email to user@example.com, your email server looks up the MX record for example.com to find out which server handles its mail. Domains can have multiple MX records with different priorities, providing backup if the primary mail server goes down.

TXT Record (Text)

TXT records store arbitrary text data. They are used for a variety of purposes: domain ownership verification (Google, Microsoft, and others require you to add a specific TXT record to prove you own a domain), email authentication (SPF and DKIM records), and policy declarations (DMARC). TXT records have become increasingly important as security and verification requirements have grown.

NS Record (Name Server)

NS records specify which authoritative name servers are responsible for a domain. When you register a domain, your registrar sets NS records pointing to the name servers you choose. These records are what the DNS system uses to find the authoritative server for your domain. Changing NS records is how you migrate a domain to a new DNS provider.

PTR Record (Pointer)

PTR records do the opposite of A records — they map an IP address back to a domain name. This is called reverse DNS lookup. PTR records are commonly used for email servers to verify that the sending server is legitimate. If your IP address does not have a proper PTR record, emails you send are more likely to be flagged as spam.

DNS and Internet Speed

DNS speed does not increase your bandwidth. A faster DNS resolver will not make your 100 Mbps connection into a 200 Mbps connection. But it does something arguably more important: it reduces the time between typing a URL and seeing the page start to load.

Here is why this matters. A typical modern webpage pulls resources from 20 to 50 different domains. The main site, the CDN serving images, the font provider, the analytics script, the advertising network, the video embed — each one requires a DNS lookup. If your resolver adds 50 milliseconds to each lookup and the page triggers 30 lookups, you are waiting an extra 1.5 seconds before the page even begins rendering. That is a noticeable delay, and it is entirely caused by DNS.

A fast resolver like Cloudflare 1.1.1.1 completes lookups in 5 to 15 milliseconds. A slow ISP resolver might take 50 to 100 milliseconds. Across dozens of lookups per page, that difference compounds into seconds of wasted time every time you visit a new website.

DNS speed also affects how quickly streaming services locate the optimal CDN node. Services like Netflix, YouTube, and Spotify use DNS to route you to the nearest server. A slow resolver might point you to a physically farther server, resulting in higher buffering and longer startup times. A fast resolver gets you to the right server faster.

For gaming, DNS speed affects launch times, matchmaking responsiveness, and patch download initiation. Once you are connected to a game server, DNS is no longer in the picture — all communication is direct IP-to-IP. But the initial connection and every time you refresh a menu or load a store page, DNS is involved.

The good news is that DNS speed is one of the few performance bottlenecks you can fix yourself, instantly, and at no cost. You do not need to upgrade your internet plan or buy new hardware. You just need to change two numbers in your network settings. Run our DNS speed test to see which resolver is fastest from your location, then change your DNS settings to use it.

DNS Security Overview

Traditional DNS has a fundamental security problem: it sends queries in plaintext. Anyone on your network path — your ISP, your employer, the coffee shop running the WiFi — can see every domain you visit. DNS was designed in the early 1980s when the internet was a trusted academic network. Security was an afterthought. Three major protocols address this gap.

DNSSEC (DNS Security Extensions)

DNSSEC adds cryptographic signatures to DNS records. When a resolver receives a response, it can verify that the response actually came from the authoritative server and was not tampered with in transit. DNSSEC prevents DNS spoofing attacks where an attacker redirects you to a malicious server by sending fake DNS responses. DNSSEC does not encrypt DNS queries — the data is still visible to observers — but it ensures the answers are authentic. Adoption is growing but not yet universal. Some domains have DNSSEC enabled, others do not.

DNS over HTTPS (DoH)

DoH encrypts DNS queries by wrapping them inside standard HTTPS traffic. Your DNS lookups travel through the same encrypted channel as regular web browsing, making them indistinguishable from normal HTTPS connections. This prevents eavesdropping and manipulation of DNS queries. Most modern browsers support DoH natively. Firefox, Chrome, Edge, and Safari all have built-in DoH support. Our guide to DNS over HTTPS explains the details.

DNS over TLS (DoT)

DoT achieves the same goal as DoH — encrypting DNS queries — but uses a dedicated TLS connection on port 853 instead of tunneling through HTTPS. DoT is easier to identify and manage on corporate networks because it uses a separate port, which can be an advantage or disadvantage depending on your perspective. Some network administrators prefer DoT because they can see and manage DNS traffic. Others prefer DoH because it blends in with regular web traffic.

For most users, the practical choice is simple: enable DoH in your browser settings and choose a DNS provider with a strong privacy policy. That combination gives you encrypted queries and a resolver that does not log your browsing history. See our guide to DNS and speed for more on how security protocols affect performance.

Frequently Asked Questions