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.
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.
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).
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.
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.
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).
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.
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.
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.
Run a free DNS lookup on any domain using the Lemwatch DNS lookup tool — 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.