DNS, Explained: From Resolvers to Encrypted Queries

Every request you make on the internet starts with a phonebook lookup so fast you never notice it — and so foundational that when it breaks, the entire internet "is down" while every server is perfectly healthy. DNS is the internet's most critical invisible system, and most developers' understanding of it stops at "it turns names into IPs." This is the full walkthrough: the chain, the caching, the security model, and the quiet privacy war that's redefining the protocol.

The lookup: a chain of four servers

When your browser asks for example.com, it doesn't ask one server. It walks a chain, each step narrowing the search:

Your resolver (usually your ISP's, or 8.8.8.8, or your router's) receives the query.
The resolver asks a root server (13 logical roots worldwide, anycast to hundreds of machines): "who handles .com?"
The root answers with the TLD server for .com, which the resolver asks: "who handles example.com?"
The .com TLD answers with the authoritative server — the one the domain owner configured — which the resolver asks: "what's the IP?"

Only then does the resolver return the answer to your browser. Three round-trips per name, hidden behind caching.

1
# See the full chain with dig's trace mode
2
dig +trace example.com
3
# ;; Received 525 bytes from 198.41.0.4#53(root) in 32 ms
4
# ...root -> .com -> example.com -> answer

Caching and TTL: the reason it's fast

DNS would be unusably slow if every lookup walked the whole chain. Every answer carries a TTL — time to live, in seconds — and every server in the chain caches the answer until it expires. That's why a domain change "takes time to propagate": it's not propagation, it's expiry. The old answer keeps being served from caches until the TTLs run out.

1
dig example.com
2
# ;; ANSWER SECTION:
3
# example.com.    3600  IN  A  93.184.216.34
4
#                    ^^^^ TTL: 3600 seconds = 1 hour of caching

This is also why DNS changes feel slow after the fact: lower your TTL before a planned migration (to 300, say), wait a day for old caches to drain, then flip. Change the record with a long TTL and you'll be chasing stale answers for a week.

The wire: UDP, port 53, and the 512-byte ceiling

DNS was designed for simplicity: a tiny request, a tiny answer, over UDP port 53. One consequence — answers are limited to 512 bytes on classic UDP, which is why DNSSEC (below) needed the "EDNS0" extension to allow larger packets. When an answer doesn't fit, the resolver retries over TCP. UDP made DNS fast and cheap; it also made it spoofable.

The security model: DNSSEC and the cache-poisoning era

For most of DNS history, the answer to "how do we know this IP is real?" was "we just don't." A malicious actor on the path could answer your resolver's query with a forged reply (cache poisoning), and your resolver would happily cache it. The fix, deployed incrementally since 2010, is DNSSEC: the zone's owner signs its records with a private key, and resolvers verify the signature against a chain of trust that ends at the root's public key.

1
# Verify DNSSEC: the "ad" flag means the answer was authenticated
2
dig +dnssec example.com
3
# ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2

DNSSEC does not encrypt anything — it authenticates. Your queries are still visible to anyone on the path; they just can't be forged anymore. That distinction matters for the privacy half of the story.

The privacy problem

Here's the uncomfortable fact most users never hear: every DNS query you make is a record of every site you visit. Your ISP's resolver sees every domain your browser resolves — a complete browsing history in a log file, with no HTTPS protection because the DNS lookup happens before the connection. For years this was just accepted; ISPs monetized it, and governments subpoenaed it.

DoH and DoT: encrypting the phonebook

Two standards exist to fix the visibility problem:

DoT (DNS over TLS) — DNS over a TLS connection on port 853. Simple, encrypted, but a distinct port that firewalls can spot and block.
DoH (DNS over HTTPS) — DNS queries inside ordinary HTTPS on port 443. Deliberately indistinguishable from normal web traffic; this is what Firefox, Chrome, and modern operating systems now use by default.

Both encrypt the query so the network path (ISP, Wi-Fi hotspot, country firewall) sees only "an encrypted query to 8.8.8.8" — not which domains. The trade is that your queries now go to whoever runs your chosen resolver, which is why resolver choice became a privacy decision: Cloudflare 1.1.1.1, Google 8.8.8.8, and Quad9 9.9.9.9 all publish transparency reports and no-logging promises, and you get to pick which company (if any) you trust with the phonebook.

1
# Test DoH from the command line (needs a DoH-capable client)
2
kdig +https @dns.google example.com
3
# ;; TLS session (TLS1.3)-(ECDHE-X25519)-(AES-256-GCM)
4
# example.com.  3600  IN  A  93.184.216.34

Running your own resolver

The privacy maximalist move is running your own resolver — either a recursive one that walks the chain yourself, or more practically a forwarding resolver that talks DoH/DoT upstream:

1
# Minimal unbound config: forward everything over TLS to Cloudflare
2
server:
3
  interface: 127.0.0.1
4
  access-control: 127.0.0.1 allow
5

6
forward-zone:
7
  name: "."
8
  forward-tls-upstream: yes
9
  forward-addr: 1.1.1.1@853#cloudflare-dns.com

Point your router or devices at it, and every device on your network gets encrypted, logged-nowhere DNS with a config file you can read. It's the homelab equivalent of rolling your own keys — not for everyone, but the knowledge is the point.

The mental model

DNS is a distributed, cached, mostly-unsigned phonebook that the entire internet calls before every single request. Three facts make it click:

It's a chain — resolver → root → TLD → authoritative — and caching is what makes the chain bearable.
It's authenticated, not private — DNSSEC stops forgery; DoH/DoT stop surveillance; you need both to get either fully.
It's your data — every query is a visit log, and choosing a resolver is choosing who holds it.

The internet feels like it "just works" because DNS is fast, cached, and invisible. It's also the layer where your privacy either gets defended or sold — and now you know which one your setup is doing.