How DNS works, from query to answer
The internet's phone book: how a name becomes an IP address, step by step.
Explain like I'm 5
Computers don't actually talk to each other using names like shellquest.io. They use numbers called IP addresses, like 65.108.95.19. Names are for humans; numbers are for machines.
DNS is the giant phone book that turns a name into its number. When you type a website name, your computer asks a helper, “what's the number for this name?” The helper asks around until it finds the answer, tells you, and remembers it for a while so it's instant next time.
DNS translates human names into machine addresses by asking a chain of specialised directories — and caching the answer so it doesn't have to ask again.
Beginner
A DNS name is read right to left, getting more specific. In www.shellquest.io. the trailing dot is the invisible root, then .io is the top-level domain (TLD), then shellquest is the domain, then www is a host within it.
The directory stores different kinds of entries, called records:
| Record | What it holds |
|---|---|
| A | An IPv4 address for a name. |
| AAAA | An IPv6 address. |
| CNAME | An alias — “this name is really that name, go look there.” |
| MX | Where to deliver email for the domain. |
| NS | Which nameservers are authoritative for the domain. |
| TXT | Arbitrary text — used for SPF, DKIM, domain verification, etc. |
| SRV | Locates a service: host + port for things like SIP, LDAP, and Kerberos (_kerberos._tcp). |
| CAA | States which Certificate Authorities are allowed to issue TLS certificates for the domain. |
| SOA | Start Of Authority: the zone's serial number, refresh/retry timers and negative-cache TTL. |
| PTR | Reverse lookup: an IP address back to a name. |
Two kinds of server do the work:
- A recursive resolver (run by your ISP, or
1.1.1.1/8.8.8.8) does the legwork of finding an answer for you and caches it. - Authoritative nameservers hold the real records for a zone and give definitive answers.
Every record carries a Time To Live: how many seconds it may be cached. A 3600 TTL means resolvers can reuse the answer for an hour before asking again. TTLs are why DNS changes aren't instant.
Intermediate
Here's what actually happens the first time anyone looks up shellquest.io (nothing cached yet). Your device asks its recursive resolver, and the resolver walks the hierarchy iteratively — each server points it one step closer.
Notice the two different styles of question:
- Recursive query — what your device asks the resolver: “give me the final answer, do whatever it takes.”
- Iterative query — what the resolver asks each server: “answer if you can, otherwise tell me who to ask next.” The root and TLD servers only ever refer — they never know the final IP.
Caching happens at every layer — your browser, your OS stub resolver, and the recursive resolver all hold answers until the TTL expires. So the elaborate walk above usually happens once; the next million users get a cached answer in a millisecond.
Root servers know the TLDs. TLD servers know each domain's nameservers. Authoritative servers know the actual records. The resolver chains these referrals together and remembers the result.
Advanced
Delegation and glue. When .io delegates shellquest.io to ns1.shellquest.io, there's a chicken-and-egg problem: to find that nameserver you'd need to resolve a name inside the zone you're trying to reach. The fix is a glue record — the parent zone includes the nameserver's IP directly, breaking the loop.
Negative caching. “Does not exist” (NXDOMAIN) is an answer too, and it's cached — for a duration set by the SOA record's minimum TTL. This stops repeated lookups of typo'd or missing names from hammering authoritative servers.
Transport. DNS classically runs over UDP port 53 for speed. If a response exceeds the size limit it's marked truncated and the resolver retries over TCP. EDNS0 negotiates larger UDP payloads (important for DNSSEC's big responses) and carries extensions.
Zones, primaries and secondaries. A zone is the slice of the namespace an authoritative server is responsible for. For resilience you run several authoritative servers: a primary holds the editable master copy, and secondaries pull a read-only copy via a zone transfer — a full AXFR the first time, then incremental IXFR updates triggered by a bumped SOA serial (and pushed promptly with NOTIFY). If two authoritative servers disagree, mismatched SOA serials are the first thing to check.
Returning several A records for one name gives crude round-robin balancing; GeoDNS and managed providers go further, handing back different answers based on the resolver's location or health checks. It's powerful but blunt: clients and resolvers cache by TTL, so DNS-based failover is only as fast as your lowest TTL.
| Mechanism | Why it matters |
|---|---|
| Anycast | The 13 root “servers” and big resolvers are actually hundreds of nodes sharing one IP; routing sends you to the nearest. This is how DNS stays fast and DDoS-resistant globally. |
| Reverse DNS (PTR) | Maps IPs back to names via the special in-addr.arpa (IPv4) and ip6.arpa (IPv6) zones. Mail servers lean on it for reputation. |
| SOA | The Start Of Authority record: serial number, refresh/retry timers for zone transfers, and the negative-cache TTL. |
Deep dive
Plain DNS has no authentication — a resolver believes whatever answer it gets, which enables cache poisoning (injecting forged answers). DNSSEC fixes integrity by signing records with a chain of trust that mirrors the hierarchy.
- Each zone signs its records, producing RRSIG signatures, verifiable with the zone's DNSKEY.
- The parent zone publishes a DS record — a hash of the child's key — linking child to parent.
- Validation walks from the root's well-known trust anchor down to the name, checking each link. Tamper anywhere and validation fails (SERVFAIL).
DNSSEC proves an answer is authentic, but the query and answer still travel in cleartext. DoH (DNS over HTTPS) and DoT (DNS over TLS) add confidentiality by encrypting the transport — a different problem from DNSSEC's integrity.
The failures that actually page engineers:
| Symptom | Usual cause |
|---|---|
| “It works for me but not them” | Split-horizon DNS, or different resolvers holding different cached answers. |
| Change didn't take effect | TTL — old answer still cached. Lower the TTL before a migration, not during. |
| Intermittent failures | One authoritative nameserver out of sync (check SOA serials) or an EDNS/firewall issue dropping large responses. |
| SERVFAIL on a signed zone | Broken DNSSEC chain — expired RRSIGs or a missing DS after a key rollover. |
The tool that ends arguments is dig +trace, which performs the iterative walk yourself so you can see exactly where it breaks:
# Walk the delegation chain from the root downward
dig +trace shellquest.io
# Query a specific authoritative server directly (bypass caches)
dig @ns1.shellquest.io shellquest.io A
# Check what's actually cached + the remaining TTL
dig shellquest.io A +noall +answer
# Inspect DNSSEC records
dig shellquest.io DNSKEY +dnssecDNS is a globally distributed, cached, hierarchical database. Resolvers chain referrals from the root through the TLD to authoritative servers, then cache the result for its TTL. DNSSEC adds authenticity via a signed chain of trust; DoH/DoT add privacy. Most real-world DNS pain is just caching and TTLs behaving exactly as designed.
Frequently asked questions
What is the difference between recursive and authoritative DNS?
A recursive resolver does the work of finding an answer on your behalf and caches it. An authoritative nameserver holds the real records for a domain and gives definitive answers. Your device talks to a resolver; the resolver talks to authoritative servers.
Why do DNS changes take time to propagate?
There's no global push — resolvers simply cache old answers until the record's TTL expires. If a record had a 24-hour TTL, some resolvers may serve the old value for up to 24 hours. Lowering the TTL before a change reduces this window.
What is a TTL in DNS?
Time To Live: the number of seconds a record may be cached before a resolver must look it up again. Lower TTLs mean faster changes but more queries; higher TTLs mean fewer queries but slower changes.
What does DNSSEC actually protect against?
It protects the integrity and authenticity of DNS answers, preventing spoofing and cache poisoning via a signed chain of trust. It does not encrypt your queries — that's what DoH and DoT do.
What's the difference between an A record and a CNAME?
An A record maps a name directly to an IPv4 address. A CNAME is an alias that points one name at another name, which must then be resolved to find the address. You can't have a CNAME at a zone apex (the bare domain).
ShellQuest turns concepts like this into bite-sized lessons, puzzles and labs you actually practise.
Join the waitlist