---
title: "How DNS lookups work — a visual guide"
description: "A plain-English visual guide to how DNS lookups work — recursive resolvers, root servers, TLD servers, authoritative name servers, and caching. With SVG diagrams."
canonical: "https://lemwatch.com/guides/how-dns-works"
source: "https://lemwatch.com"
---

# How DNS lookups work — a visual guide

> Every web request starts with a DNS lookup. This guide walks through the recursive resolver, root server, TLD server, and authoritative name server — with an SVG diagram of the full flow — then explains why caching matters and how to spot a broken DNS chain.

## The DNS lookup flow in 5 steps

 When you type lemwatch.com into a browser, the browser doesn't know the IP address. It asks a chain of servers, each of which knows part of the answer. The five steps are **browser cache**, **recursive resolver**, **root server**, **TLD server**, and **authoritative name server**. Each step either returns a cached answer or hands the query down the chain.

### 1. Browser & OS cache

 Before any network traffic, the browser checks its own cache, then the operating system's. If the domain was looked up recently, the IP is returned instantly with no DNS query at all. Cache lifetime is controlled by the record's TTL (time-to-live).

### 2. Recursive resolver

 If the local cache is cold, the OS sends the query to a recursive resolver — usually run by your ISP, or a public one like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google). The resolver's job is to chase the answer through the rest of the hierarchy on your behalf and cache the result.

### 3. Root name server

 There are 13 root server clusters worldwide (named A through M). The resolver asks one of them where the .com servers live. The root server doesn't know the answer for lemwatch.com — it just points to the authoritative servers for the .com TLD.

### 4. TLD name server

 The resolver then asks a .com TLD server which name server owns lemwatch.com . The TLD server returns the authoritative name server addresses (e.g. ns1.example.com ).

### 5. Authoritative name server

 Finally, the resolver asks the authoritative server for lemwatch.com 's A record (IPv4) or AAAA record (IPv6). That answer is returned to the resolver, cached, and passed back to the browser. The full round-trip typically takes 20–120 milliseconds for an uncached lookup, and under 5ms for a cached one.

## Why DNS caching matters

 Without caching, every page load would trigger five hops through the DNS hierarchy. With caching, repeat lookups are effectively free. The TTL on each record tells resolvers how long to cache it — short TTLs (60–300 seconds) make changes propagate fast but increase load, long TTLs (3600–86400 seconds) reduce load but slow propagation.

## How DNS breaks (and how to spot it)

- Stale cache — Old records persist past a domain move. Flushing the local resolver cache usually fixes it.

- NXDOMAIN responses — The authoritative server says the record doesn't exist. Common after a typo or an accidentally-deleted record.

- SERVFAIL responses — The authoritative server is unreachable or the DNSSEC signature failed. Usually a provider outage.

- Slow lookups — Resolver is overloaded or the authoritative server is geographically far. Switching to a faster public resolver (1.1.1.1, 8.8.8.8) often helps.

- Mismatched A/AAAA records — IPv4 resolves but IPv6 fails (or vice versa), causing intermittent failure depending on the client's network.

## What to monitor

 For production sites, the things that matter are: **resolution latency** (slow DNS is invisible until you measure it), **record change detection** (someone modifies an A or NS record without telling the team), and **NS-record drift** (a registrar update fails halfway). Lemwatch's DNS monitoring tracks all three on every site you add, and alerts on any record hash change.

## Try it yourself

 Run a free DNS lookup on any domain using the [Lemwatch DNS lookup tool](https://lemwatch.com/tools/dns-lookup) — it shows the A, AAAA, MX, NS, TXT, and CNAME records, plus the resolution time. For continuous monitoring with change alerts, the same checks run automatically inside the [full Lemwatch platform](https://lemwatch.com/features).

## Further reading

- RFC 1035 — Domain Names, Implementation and Specification

- Cloudflare Learning Center — What is DNS?

- MDN Web Docs — DNS



## Lemwatch at a glance

- What it is: website monitoring that checks uptime, page changes, SEO, security, SSL and speed in one tool.
- Free plan: 10 sites, no time limit, all check types.
- Pro: $19/mo, 50 sites, public API and webhooks.
- Agency: $59/mo, 150 sites, white-label status pages.
- Source: https://lemwatch.com/pricing (facts verified from the product's own plan limits).



## Related

- [Free DNS lookup tool](https://lemwatch.com/tools/dns-lookup)
- [Free SSL certificate checker](https://lemwatch.com/tools/ssl-checker)
- [DNS glossary entry](https://lemwatch.com/glossary/dns)
- [All Lemwatch features](https://lemwatch.com/features)
- [Domain disasters we've prevented](https://lemwatch.com/changelog/domain-disasters-prevented)
- [Lemwatch pricing](https://lemwatch.com/pricing)
- [Visual guides](https://lemwatch.com/guides)
