DNS

Why It Matters

Nothing else in the stack runs until DNS answers. A perfectly healthy server with a broken record is, from the visitor's side, indistinguishable from a server that has burned down. It is also the part of a setup that people edit rarely and therefore edit badly: a typo in a hosting dashboard is visible immediately, whereas a typo in a zone can sit unnoticed for hours behind a cache. Lookups cost time too — a cold resolution adds tens of milliseconds before the first byte of the page is even requested. And because answers are cached, a mistake is not undone by fixing it; it is undone by waiting out whatever TTL was attached to the wrong answer.

How It Works

Your browser asks the operating system, which asks a recursive resolver. If that resolver has a fresh answer it returns it and the story ends there. Otherwise it queries a root server, is referred to the servers for the top-level domain, is referred again to the authoritative nameservers for the domain, and finally receives the DNS records for the name. It caches each step for the stated TTL and hands the answer back. The browser then opens a TCP connection to the address it was given and sends the request, including the original hostname in the Host header, so a server holding thousands of sites knows which one to serve.

Real-World Example

Common Mistakes

• ✕Testing only in a browser — the browser, the operating system and the router all cache, so what you see may be several layers of stale answer rather than the record you just saved
• ✕Editing records at a provider that is no longer authoritative — the edits save happily and are never read by anyone
• ✕Reading a lookup failure as a hosting fault — a site can be entirely healthy while its name simply fails to resolve

Related Terms