What Is DNS, and How Does It Actually Work?
Web & Networking - 6 min read - Published 2026-08-27
Every time you type a domain name into a browser, something has to translate that human-readable name into the numeric IP address computers actually use to route traffic. That translation system is DNS (Domain Name System), and it's one of the oldest pieces of internet infrastructure still running essentially the same way it did in the 1980s.
The Lookup Chain
A DNS lookup for a domain like example.com doesn't happen in one step - it walks down a hierarchy. Your device first asks a recursive resolver (often run by your ISP or a public service). That resolver asks a root server, which doesn't know the answer but knows which server handles the .com top-level domain. The .com server doesn't know the final answer either, but knows which nameserver is authoritative for example.com specifically. Finally, that authoritative nameserver returns the actual IP address, which gets cached and passed back down the chain.
This hierarchy is why DNS scales to the entire internet: no single server needs to know every domain in existence, just how to point toward the next server that knows more.
The Record Types That Actually Matter
An A record maps a domain to an IPv4 address; an AAAA record does the same for IPv6. A CNAME record points one domain name to another domain name rather than directly to an IP, useful for pointing subdomains at a third-party service without hardcoding its IP. An MX record specifies which mail servers handle email for a domain, and includes a priority value so multiple mail servers can be tried in order. A TXT record holds arbitrary text and is commonly used for domain ownership verification and email authentication systems like SPF and DKIM.
Why DNS Changes Take Time to Show Up
Every DNS record has a TTL (Time To Live) value, which tells resolvers how long they're allowed to cache that answer before checking again. This is why changing a DNS record - pointing a domain at a new server, for example - doesn't take effect everywhere instantly: resolvers around the world that already cached the old answer will keep serving it until their cached copy's TTL expires. Lowering a record's TTL in advance of a planned change is a common way to make the eventual cutover propagate faster.