// DNS · HOW IT WORKS

🧭 The journey of a DNS query

You type example.com and hit Enter. Before the first byte of the site arrives, that name must be turned into an IP — and that kicks off a journey through the DNS hierarchy: root → TLD → authoritative. Walk through it step by step.

The resolution, step by step

💻 Your device + resolver 🌐 DNS hierarchy
  1. 01 www.example.com? local

    Your browser asks

    Before connecting to anything, your device needs the IP of www.example.com. It asks the recursive resolver (your ISP’s, or 1.1.1.1 / 8.8.8.8). But first it checks its cache.

    Most queries never leave your network: they’re answered from cache in microseconds.
  2. 02 ¿ .com ? → raíz (.) query

    Query a root server (.)

    If it’s not cached, the resolver starts at the top: it asks a root server for www.example.com.

    There are 13 root identities (A–M), replicated by anycast across hundreds of servers worldwide.
  3. 03 NS de .com reply

    The root delegates to .com

    The root doesn’t know the IP, but it knows who runs .com: it replies with the TLD’s name servers (NS).

    The root only delegates. It never sees your final domain or content: just the “.com”.
  4. 04 ¿ example.com ? → TLD .com query

    Query the .com server

    The resolver repeats the question, now to a .com TLD server.

    Each level gets one step closer to the answer: it’s a hierarchy of delegation.
  5. 05 NS de example.com reply

    The TLD delegates to the domain

    The .com server refers to example.com’s authoritative servers (the ones its owner set).

    Whoever controls the authoritative NS controls the domain’s answers: that’s why their security matters so much.
  6. 06 ¿ www.example.com ? → autoritativo query

    Query the authoritative server

    Final question: the resolver queries example.com’s authoritative server, the one that does have the answer.

    “Authoritative” = the source of truth for that domain, not a cached copy.
  7. 07 A 93.184.216.34 · TTL 3600 reply

    A record + TTL

    The authoritative server returns the A record (the IPv4; it’d be AAAA for IPv6) and a TTL: how many seconds it may be cached.

    The TTL is a trade-off: high = fewer queries but slower changes; low = the opposite.
  8. 08 cache + respuesta local

    Caches and answers you 🔗

    The resolver stores the answer (for the TTL) and hands the IP to your browser. Only now does the connection begin (TCP and, if HTTPS, the TLS handshake).

    Next time anyone on your network asks for that name, it comes straight from the resolver’s cache.

Without JavaScript you get the full resolution as an article. With JS, step through it (arrow keys ← → work too).

🗄️ Cache and TTL

The full journey (root → TLD → authoritative) happens once; then the answer lives in the resolver’s cache for its TTL. That’s why most queries are answered instantly and never leave your network.

🪜 Hierarchy and delegation

No one holds the “whole” directory: the root delegates to the TLD, and the TLD to the authoritative server, via NS records. The resolver is the only one doing the recursive work; the rest just refer or reply.

🔒 Privacy and authenticity

Classic DNS travels in the clear (UDP/53): your ISP —and anyone listening— sees which domains you request. DoH/DoT encrypt it; DNSSEC signs the answers so no one can slip you a fake IP (cache poisoning).

Sources: RFC 1034/1035 · root-servers.org. Once you have the IP, next comes the TLS handshake. And browse the DNS record types.