A DNS lookup finds the IP address behind a domain name; an HTTP request uses that address to actually fetch the page's content. They happen one after the other, and a slow or failed step in either one can make a website feel broken even when the other step works fine. Understanding the difference matters for anyone who manages a site, buys ads that link to landing pages, or debugs why a page "won't load." A DNS problem and a server problem look identical to a visitor — both show a blank screen or an error — but they require completely different fixes.
Table of Contents
- What DNS Lookup Actually Does
- What Happens During the HTTP Request
- Why the Order Matters for Troubleshooting
- Where This Shows Up in Everyday Site Management
- Frequently Asked Questions
What DNS Lookup Actually Does
DNS stands for Domain Name System. It's the directory service that translates a human-readable domain, like example.com, into the numeric IP address a computer needs to connect to a server, such as 192.0.2.10. When a browser needs to open a page, it first asks a DNS resolver — usually run by the user's internet provider, or a public option like Google's 8.8.8.8 or Cloudflare's 1.1.1.1 — "what address does this domain point to?" That resolver checks its cache, and if it doesn't already know the answer, it queries a chain of DNS servers (root, then the domain's registry, then the domain's own nameservers) until it finds the authoritative answer. This lookup produces nothing visible to the user.
No page content, no images, no text — just an IP address handed back to the browser. It's pure address resolution, comparable to looking up a phone number before dialing it. DNS records also carry more than one domain's address. An MX record points to mail servers, a CNAME aliases one domain to another, and a TXT record can hold verification codes for services like Google Search Console or email authentication (SPF, DKIM). All of these are resolved through the same system, even though only the A or AAAA record matters for loading a web page.
What Happens During the HTTP Request
Once the browser has an IP address, it opens a connection to the server at that address and sends an HTTP (or HTTPS) request — a formatted message asking for a specific resource, typically the page's HTML file. HTTP stands for Hypertext Transfer Protocol; it's the language browsers and servers use to exchange web content. The server receives that request, runs whatever code generates the page — a WordPress or Drupal template, a static file, an application script — and sends back a response. That response includes a status code (200 for success, 404 for not found, 500 for a server error) and the actual content: HTML, then the CSS, JavaScript, and images the browser requests next.
Unlike DNS, which only needs to happen once per domain until the cache expires, HTTP requests happen repeatedly throughout a single page load — one for the HTML, then separate ones for every stylesheet, script, and image referenced in it. This is why a page with dozens of unoptimized image files can load slowly even when DNS resolves instantly: the bottleneck has moved to the second step. If HTTPS is in use, there's an additional exchange — the TLS handshake — between DNS resolution and the HTTP request itself, where the browser and server agree on encryption and the server proves its identity with a certificate. That handshake adds its own round trip time but is a separate step from both DNS and the HTTP exchange that follows it.
Why the Order Matters for Troubleshooting
Separating these steps matters because each one fails for different reasons and needs a different fix. A DNS failure means the browser never even learns where to send the request — the domain doesn't resolve, or resolves to the wrong address. An HTTP failure means the browser reached a server successfully, but that server returned an error or no usable content. For site owners, this distinction shortens debugging time.
Tools like `dig`, `nslookup`, or online DNS checkers test the first step in isolation by showing exactly what IP address a domain resolves to, without touching the server. A direct browser request to the server's IP address, or an HTTP status checker, isolates the second step. This also explains a common point of confusion after launching a new site or changing hosts: visitors in different locations may see the old site for anyone whose DNS resolver is still a few steps behind, even though the server side is already updated and working correctly. DNS changes propagate gradually across resolvers worldwide rather than updating everywhere simultaneously.
- If a browser shows "DNS_PROBE_FINISHED_NXDOMAIN" or "server not found," the problem is in DNS: the domain may be newly registered and not yet propagated, nameservers may be misconfigured, or a DNS record may point to a decommissioned server.
- If a browser shows a 404, 500, 502, or 503 error, or a blank white page, DNS worked — the browser reached a server. The problem is on the server side: a broken plugin, an expired SSL certificate, a crashed database connection, or a misconfigured redirect.
- If a page hangs with no error at all, it can be either step: a slow DNS resolver, or a server that accepted the connection but is too slow to respond.
Where This Shows Up in Everyday Site Management
Anyone running a WordPress or Drupal site, managing Google Ads campaigns, or tracking SEO performance encounters this split in practical ways, even without thinking about it as "DNS versus HTTP." Monitoring tools that report "uptime" are usually timing the full sequence — DNS lookup, connection, and HTTP response combined — and some report DNS lookup time as a separate metric specifically so a slow resolver doesn't get blamed on the server, or vice versa. Reading that breakdown, when a monitoring tool provides one, is often the fastest way to tell which half of the page-load process is responsible for a reported slowdown.
- **Moving hosts or changing nameservers**: this is a DNS-layer change. The site itself (the HTTP-serving part) may be fully functional on the new host while some visitors still reach the old one, because their resolver hasn't picked up the updated record yet.
- **A broken ad landing page**: if an ad's destination URL returns an error, check the HTTP response first — DNS almost certainly isn't the issue if the domain loads for other pages on the same site.
- **SSL certificate warnings**: these occur after DNS has already succeeded, during the HTTPS handshake that precedes the HTTP exchange, so they point to a certificate or server configuration problem, not a domain-resolution one.
- **CDN and DNS-based security services** (like Cloudflare) sit between these two steps: they intercept the DNS resolution so that the IP address returned points to the CDN's network first, which then forwards the request to the origin server.
Frequently Asked Questions
Does every page load require a new DNS lookup?
No. Browsers and operating systems cache DNS results for a period set by the record's TTL (time to live), so repeat visits often skip straight to the HTTP request until that cache expires.
Can a website have correct DNS but still be completely down?
Yes. DNS only confirms that a domain points to an address; if the server at that address is crashed, overloaded, or misconfigured, visitors will reach it but get an error instead of a page.
Why does a new site sometimes work for the owner but not for visitors?
This usually means DNS changes haven't finished propagating to every resolver yet. The owner's device may already be using the updated record, cached locally, while other visitors' resolvers still hold the old one.
