How DNS works

Type example.com in the address bar; ~50 milliseconds later the page loads. In between, the Domain Name System — the distributed directory that translates human names into IP addresses — walked a tree of servers around the world. This is what happened.

The cast of characters

• Stub resolver — built into your OS. When an app says "I want to talk to example.com," it asks the stub. The stub does very little work; it just forwards the question to the recursive resolver and caches the answer.
• Recursive resolver — usually run by your ISP (or Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9). This is the one that actually does the hierarchy walk.
• Root servers — 13 logical name servers (A.root-servers.net through M.), actually hundreds of physical instances via anycast. They know who runs each top-level domain.
• TLD servers — separate name servers for .com, .org, country TLDs like .uk and .jp. They know which authoritative server owns each domain within their TLD.
• Authoritative server — the actual source of truth for a domain. Usually run by the domain registrar or a DNS provider like Cloudflare, Route 53, or NS1.

The walk, step by step

You type example.com into the address bar.

1. The browser asks the stub resolver. The stub probably has it cached; assume not.
2. The stub asks its configured recursive resolver. Same — probably cached; assume not.
3. The recursive resolver asks a root server: "Who handles .com?" The root server replies with the addresses of the .com TLD servers.
4. The recursive resolver asks a .com TLD server: "Who is authoritative for example.com?" It replies with the NS records — typically a couple of name-server hostnames.
5. The recursive resolver asks an authoritative server: "What's the A record for example.com?" It replies with the IP.
6. The recursive resolver caches the answer (for the TTL the authoritative server set) and returns it to your stub. Your stub returns it to the browser, which finally opens a TCP connection.

Steps 3–5 are skipped almost all the time because everything is cached. A cold lookup is ~150 ms across continents; a cache hit is <5 ms.

Beyond A records

The same hierarchy serves dozens of record types. The common ones:

• A — IPv4 address.
• AAAA — IPv6 address.
• CNAME — alias to another name.
• MX — mail-server routing.
• TXT — free-form text. Hosts SPF, DKIM, DMARC, domain-verification tokens.
• NS — which authoritative servers own the zone.
• SOA — administrative metadata for the zone.
• CAA — which Certificate Authorities can issue TLS certs for this name.
• PTR — reverse DNS (IP → name).
• SRV — service discovery (which host runs SIP on which port, etc.).

IPFerret's DNS lookup tool queries any of these.

Caching, and why it matters

Every DNS answer carries a TTL — how long a downstream resolver should consider it valid. Low TTLs (60–300 seconds) let you flip records fast for blue-green deployments; high TTLs (hours to days) reduce upstream load and speed up repeat lookups.

The trade-off bites during outages: if you set a 1-hour TTL on an A record and the upstream goes down, traffic keeps hitting the dead IP for up to an hour after you've updated DNS. Many CDNs solve this with their own short-TTL anycast layer ahead of your origin.

Modern privacy: DoH, DoT, DNSSEC

• DNSSEC — cryptographic signatures on records. Lets a resolver verify "this answer wasn't forged." Doesn't encrypt anything; just attests.
• DNS over HTTPS (DoH) — DNS wrapped in HTTPS on port 443. Hides queries from local network observers. Modern browsers can do this directly.
• DNS over TLS (DoT) — DNS wrapped in TLS on a dedicated port 853. Same goal, easier for network operators to identify and allow/block.
• Encrypted Client Hello (ECH) — encrypts the SNI in TLS so a network observer can't see which site you're visiting even when DoH is in use.

When DNS quietly misbehaves

• Stale cache. Your record propagated globally; one ISP's resolver still caches the old value. There's nothing you can do but wait the TTL.
• DNS leak. You're on a VPN but your OS is sending DNS queries outside the tunnel — your ISP still sees every site you browse. Test on our DNS leak test.
• DNS hijacking by your ISP. Some ISPs rewrite NXDOMAIN responses to point at their own "search" pages. Switching to a third-party resolver fixes it.
• CNAME-flattening edge cases. Some providers flatten CNAMEs at the apex (where they're technically illegal). Behaviour varies across resolvers.

You can chase any of these with IPFerret's DNS lookup tool — it hits Cloudflare's DoH endpoint, so it bypasses your ISP's resolver entirely and gives you the authoritative-side answer.