
How DNS Works — The Internet's Phone Book
DNS (Domain Name System) translates domain names like 8vast.io into IP addresses like 104.21.32.1. Every internet connection starts with a DNS lookup. Before your browser can open a TCP connection or send an HTTP request, it needs an IP address — and that comes from DNS.
Paul Mockapetris invented DNS in 1983 and formalized it in RFC 1034 and RFC 1035 in 1987. The core design has not changed: a distributed, hierarchical database mapping names to addresses.
What Problem Does DNS Solve?
Computers route packets using IP addresses — numbers like 104.21.32.1 (IPv4) or 2606:4700:3030::6815:2001 (IPv6). Humans remember names. Without DNS, you would need to memorize IP addresses for every website, mail server, and API endpoint you use.
But DNS does more than just map names to addresses. It's a general-purpose distributed database that stores multiple types of records:
| Record type | What it stores | Example |
|---|---|---|
| A | IPv4 address | 8vast.io → 104.21.32.1 |
| AAAA | IPv6 address | 8vast.io → 2606:4700:... |
| CNAME | Alias to another name | www.8vast.io → 8vast.io |
| MX | Mail server | 8vast.io → mail.8vast.io |
| TXT | Arbitrary text | SPF records, domain verification |
| NS | Name server | 8vast.io → ns1.cloudflare.com |
| SOA | Zone authority | Who is responsible for this domain |
How Does a DNS Lookup Work?
When you type 8vast.io into your browser, a chain of lookups unfolds:
- Browser cache — your browser checks if it already resolved this name recently.
- OS resolver — the operating system has its own cache and a configured DNS resolver.
- Recursive resolver — your ISP or a public resolver (like
1.1.1.1or8.8.8.8) takes the question and works through the hierarchy. - Root server — the recursive resolver asks one of 13 root server clusters: "where do I find
.iodomains?" The root responds with the address of the.ioTLD servers. - TLD server — the
.ioTLD server says: "the authoritative server for8vast.ioisns1.cloudflare.com." - Authoritative server — the final answer:
8vast.iois104.21.32.1.
Each answer includes a TTL (time to live) — a number of seconds the result can be cached. A typical TTL is 300 seconds (5 minutes). During that window, subsequent lookups skip the entire chain and return instantly.
Why Does DNS Use UDP?
Most DNS queries fit in a single packet — the question and answer are each well under 512 bytes. UDP handles this perfectly: send a question, get an answer, no handshake overhead.
Using TCP for a DNS lookup would add a round trip for the handshake — on a 50ms link, that's 50ms of latency before the question is even asked. For a system that needs to be fast above all else, that cost is unacceptable for most queries.
DNS falls back to TCP in specific cases: when the response is too large for a single UDP packet (over 512 bytes, or 4096 with EDNS), or for zone transfers between DNS servers where reliability matters.
How Does Caching Work?
DNS is designed around caching. Without it, every web page load would trigger dozens of lookups cascading through the hierarchy.
Caching happens at every level:
- Browser — stores recent lookups for the TTL duration. Chrome, Firefox, and Safari all maintain their own DNS caches.
- Operating system —
systemd-resolvedon Linux,mDNSResponderon macOS. Shared across all applications. - Recursive resolver — caches answers for all clients behind it. An ISP resolver serving millions of users will have most popular domains cached.
- CDN edge — services like Cloudflare cache DNS responses at the edge, reducing latency to single-digit milliseconds.
The TTL controls freshness. A low TTL (60 seconds) means changes propagate quickly but generate more queries. A high TTL (86400 seconds, one day) reduces query load but means changes are slow to propagate. Most production domains use TTLs between 300 and 3600 seconds.
What Happens When DNS Fails?
DNS failures are uniquely disruptive because DNS sits at the start of every connection. If your DNS resolver is down, nothing works — web pages don't load, APIs don't connect, email doesn't deliver. The application-level errors look confusing: "connection refused," "host not found," "network unreachable." All of them can be DNS.
Common failure modes:
- Resolver unreachable — your configured DNS server is down. Fix: switch to a public resolver like
1.1.1.1or8.8.8.8. - Authoritative server down — the domain's name servers are offline. Nothing you can do as a client except wait. Cached results continue working until TTL expires.
- Cache poisoning — an attacker injects a fake response, redirecting the domain to a malicious IP. DNSSEC signatures prevent this but adoption is still incomplete.
- TTL expiry during outage — DNS was working when caches were fresh. After the TTL expires, lookups fail. High-traffic domains with short TTLs are hit fastest.
To debug DNS issues, dig and nslookup are the standard tools:
dig 8vast.io A +short
104.21.32.1
dig 8vast.io A +trace
# Shows the full resolution path: root → TLD → authoritative
How Is DNS Being Secured?
Traditional DNS sends queries in plaintext over UDP. Anyone on the network path — your ISP, a public Wi-Fi operator, a state actor — can see every domain you look up.
Three technologies are closing this gap:
DNS over HTTPS (DoH) — wraps DNS queries inside HTTPS connections. From the network's perspective, it looks like regular web traffic. Supported by major browsers and resolvers (1.1.1.1, 8.8.8.8). Approximately 8% of DNS queries now use DoH, and adoption is growing.
DNS over TLS (DoT) — wraps DNS queries in TLS on port 853. More explicit than DoH (network operators can see you're making DNS queries, just not which ones). Used primarily by Android's Private DNS feature.
DNSSEC — digitally signs DNS responses so clients can verify the answer wasn't tampered with. Doesn't hide your queries (that's what DoH/DoT do), but prevents cache poisoning and spoofing. Adoption is growing but inconsistent — approximately 30% of domains are signed.
These technologies complement each other: DoH/DoT hide what you're looking up, DNSSEC proves the answer is authentic.
What Is the Hierarchy?
DNS is a tree structure. The root is the top. Below it are top-level domains (TLDs), then second-level domains, then subdomains.
. (root)
/ | \
.com .io .org
| |
google 8vast
| |
www docs
Reading a domain name right to left follows the hierarchy: docs.8vast.io means "look up .io at the root, then 8vast at the .io TLD server, then docs at the 8vast.io authoritative server."
There are 13 root server clusters (named a.root-servers.net through m.root-servers.net), operated by different organizations worldwide. Through anycast routing, each cluster has hundreds of physical servers — over 1,700 root server instances globally. They handle over 100 billion queries per day.
Next Steps
DNS resolves names, but what happens after you have an IP address?
- How HTTP Works — the application protocol that runs after DNS gives you an address.
- How TCP Works — the transport layer that carries DNS (fallback), HTTP, and most internet traffic.
- How TLS Works — the encryption layer that DoH and DoT build on.