Loading full navigation.

Autonomous IT is here. The alert loop ends now. LEARN MORE

Partners

Docs

LM Academy

LM Community

Pricing

Platform
Solution
Industry
Role
There is no result.

LOGICMONITOR BLOG

DNS Lookup: How a Domain Name Is Translated to an IP Address

See how DNS turns a domain name into an IP address step by step, and why fast resolution keeps your pages loading quickly for users all around the world.

5–7 minutes
Denton Chikura

NEWSLETTER

Subscribe to our newsletter

Get the latest blogs, whitepapers, eGuides, and more straight into your inbox.

SHARE

The quick download:

DNS resolution runs before your site can load, so slow lookups make even a fast, well-built page feel slow to users.

  • An uncached lookup can touch four layers of DNS servers (resolver, root, TLD, and authoritative name servers) before the browser opens a single connection.

  • Every unique domain a page references (images, scripts, APIs, fonts, third-party services) needs its own lookup, so one slow resolution can delay the whole page.

  • Much of the request path lies outside the infrastructure you own, so healthy internal servers can still coincide with a slow experience for users.

  • Monitor DNS from outside the firewall so you can catch a slowdown in your data before it becomes a user-reported problem.

When someone enters a domain name in a browser, the browser must find the corresponding IP address before it can connect to the application. That lookup is usually invisible to the user, but any delay or failure in the process can make a fast website feel slow or prevent the site from loading at all.

This guide explains how DNS resolution works from the browser’s first request through the start of the TCP connection. It uses an uncached lookup to show the complete path; caching often shortens the process in practice.

Why DNS resolution matters to web performance

DNS, or the Domain Name System, translates a human-readable name such as www.google.com into an IP address such as 173.194.33.174. The browser needs that address before it can establish a TCP connection and send an HTTP request.

The same principle applies to each unique domain referenced by a page’s resources. A page may depend on domains for images, scripts, APIs, fonts, or third-party services. If one of those lookups is slow or fails, the user may experience a delayed, incomplete, or unavailable page, even when the application’s own servers are healthy.

In a typical cached lookup, the resolver can answer locally or with a limited number of queries. The uncached path below represents the longer, worst-case sequence and makes each DNS layer easier to see.

Because DNS resolution happens before the browser can connect to a server and request content, its time is added directly to the start of the web transaction. Slow or failed DNS therefore delays page loading, while repeated delays across multiple domains can noticeably degrade the user’s experience.

The DNS lookup process, step by step

Step 1: The OS sends a recursive query to a DNS resolver

The operating system doesn’t know where www.google.com is, so it queries a DNS resolver. The query carries a special flag marking it a recursive query. That flag means the resolver has to finish the recursion and return either an IP address or an error.

For most users, the resolver comes from their Internet Service Provider (ISP). Others use an open alternative such as Google DNS (8.8.8.8) or OpenDNS (208.67.222.222).

You can view or change it in your network or router settings. From here, the resolver runs recursion to turn the domain name into an IP address.

Step 2: The resolver sends an iterative query to a root server

The resolver starts by asking one of the root DNS servers for the IP of www.google.com. This query has no recursive flag, so it’s an iterative query. Its response must be an address, the location of an authoritative name server, or an error.

The root is represented by the hidden trailing dot at the end of a domain name. You don’t type it, because the browser adds it automatically.

The DNS root is served by 13 named root-server authorities, A through M, operated by 12 independent organizations and backed by more than 2,000 operational server instances worldwide. These instances serve the same authoritative root-zone data.

Step 3: The root server responds with the TLD servers

These root servers hold the locations of all of the top level domains (TLDs), such as .com, .de, .io, and newer generic TLDs like .camera. The root doesn’t have the IP for www.google.com, but it knows .com might. So it returns the location of the .com servers, sent as a list of the 13 .com gTLD name server (NS) records.

Step 4: The resolver queries a TLD name server

Next, the resolver queries one of the .com name servers for the location of google.com. Like the root servers, each TLD has 4 to 13 clustered name servers in many locations.

TLDs come in two types.

TLDs include country-code TLDs (ccTLDs), such as .uk or .de, and generic TLDs (gTLDs), such as .com. Each TLD has a designated registry operator responsible for its authoritative DNS infrastructure.

For this example, the resolver queries the .com registry infrastructure, operated by Verisign..

Step 5: The TLD server responds with the domain’s name servers

Each TLD server holds a list of all the authoritative name servers for every domain in that TLD. For example, each of the 13 .com gTLD servers lists the name servers for .com domains.

The .com gTLD server doesn’t have the IP for google.com, but it knows where google.com’s name servers are. It responds with all of google.com’s NS records. In this case Google has four name servers, ns1.google.com through ns4.google.com.

Step 6: The resolver queries the domain’s authoritative name server

Finally, the resolver queries one of Google’s name servers for the IP of www.google.com.

Step 7: The authoritative name server returns the IP address

This time the name server knows the IP. It responds with an A or AAAA address record, for IPv4 and IPv6 respectively, depending on the query type.

Step 8: The resolver returns the IP address to the OS

The resolver has now finished the recursion. It can return an IP address to the end user’s operating system.

Step 9: The browser starts the TCP handshake

The operating system now has www.google.com’s IP address. It hands the IP to the application, the browser, which opens the TCP connection and starts loading the page. For more on that process, see our blog post on the anatomy of HTTP.

Slow DNS makes even a fast site feel slow

In this uncached case, four sets of DNS servers were involved in a single lookup: the recursive resolver, root servers, TLD servers, and the domain’s authoritative name servers. A lot can happen before the page even begins to load, but the user sees none of it. They simply wait for each query to complete.

This is why fast DNS matters. A site can be fast and well built, but slow DNS still increases response time because the browser cannot connect to the application until the domain has been resolved.

Much of this resolution process also takes place outside the infrastructure an organization owns. Internal monitoring may show that an application is healthy without showing that users are experiencing delays or failures while trying to reach it. Monitoring from outside the firewall helps reveal how DNS and other internet-dependent services perform from the user’s perspective.

Making DNS performance visible

LogicMonitor Digital Experience measures performance from a global agent network beyond the firewall, helping teams identify DNS and connectivity issues affecting users in different locations.

The LogicMonitor platform processes more than two trillion metrics each day, allowing DNS performance data to be viewed alongside broader infrastructure and application signals. A DNS slowdown can then appear in monitoring data before it becomes a user-reported problem.

For deeper visibility, LogicMonitor’s DNS monitoring capabilities map directly to the resolution process described in this article. Teams can monitor each step of the path, measure response time and availability, compare results across regions and providers, and identify whether an issue originates with the resolver, root, TLD, authoritative name server, or DNS configuration.

See exactly where DNS slows your users down, from resolver to authoritative name server.

LogicMonitor Digital Experience measures DNS resolution from outside your firewall, so you can find and fix connectivity issues before customers feel them. Track the full internet path under continuous watch alongside your infrastructure and application data.

FAQs

What is the difference between a recursive query and an iterative query in DNS?

A recursive query, sent from your operating system to a DNS resolver, requires the resolver to complete the entire lookup and return either an IP address or an error. Iterative queries are what the resolver then sends to the root, TLD, and authoritative name servers, each of which returns either an answer or a pointer to the next server to ask.

Why does DNS resolution affect how fast a web page loads?

DNS resolution happens before the browser can open a TCP connection and request content, so its time is added directly to the start of every web transaction. A single page also references many unique domains for images, scripts, APIs, and fonts, so a slow or failed lookup on any one of them can delay or break the page even when your own servers are healthy.

How can I monitor DNS performance for users?

Much of the DNS resolution path runs outside the infrastructure you own, so internal monitoring alone can miss user-facing delays. LogicMonitor Digital Experience measures DNS and connectivity from a global agent network beyond the firewall, letting you compare response time and availability across regions and providers and pinpoint whether an issue sits with the resolver, root, TLD, or authoritative name server.

By Denton Chikura

Content Marketing Manager

Denton Chikura is a Content Marketing Manager for LogicMonitor Digital Experience, where he drives content on observability, Internet performance, and digital experience. He writes for SREs, IT operations teams, and business leaders, turning performance data into guidance they can act on.

Disclaimer: The views expressed on this blog are those of the author and do not necessarily reflect the views of LogicMonitor or its affiliates.

© LogicMonitor 2026 | All rights reserved. | All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

Related Blogs

What Is a CMDB? A Guide for Modern ITOps
Blog AIOps & Automation

What Is a CMDB? A Guide for Modern ITOps

A CMDB maps the systems, services, and relationships that make up an IT environment. Learn how CMDB data supports incident management and where live observability and AI add critical operational context.
October 29, 2026
Learn more
Benchmarking JavaScript Memory Usage
Blog Digital Experience

Benchmarking JavaScript Memory Usage

Explore how the top 10,000 sites use JavaScript and DOM memory, why it shapes real user experience, and how to build a browser memory baseline you can trust.
October 28, 2026
Learn more
How BGP Route Changes Propagate Across the Internet
Blog Internet Performance Monitoring

How BGP Route Changes Propagate Across the Internet

See how BGP announcements, replacements, and withdrawals shift reachability across networks you don’t own, and why outside-in monitoring catches them.
October 28, 2026
Learn more