DNS (Domain Name System) is the hierarchical, distributed system that translates human-readable domain names (example.com) into the IP addresses (93.184.216.34 or an IPv6 equivalent) computers actually use to route traffic. It's defined in RFC 1034 and RFC 1035 (1987) and has been extended by numerous later RFCs, but the core hierarchical lookup model hasn't changed.
How it works
Resolving a name is a chain of delegated lookups: a recursive resolver (often run by your ISP or a public service like 8.8.8.8 or 1.1.1.1) queries a root server, which points it to the right TLD server (for .com, .org, etc.), which points it to the domain's authoritative name server, which finally returns the answer. Each answer type is a different record:
- A — hostname → IPv4 address
- AAAA — hostname → IPv6 address
- CNAME — hostname → another hostname (an alias)
- MX — domain → mail server(s), with priority
- TXT — arbitrary text, commonly used for domain verification and email authentication (SPF, DKIM)
- NS — which servers are authoritative for a domain
Lookups mostly travel over UDP port 53 (falling back to TCP for large responses like zone transfers), and answers are cached for a duration set by each record's TTL (time to live) — which is why DNS changes can take anywhere from minutes to a day or more to fully propagate.
Common pitfalls
- A low TTL makes DNS changes propagate faster but increases lookup traffic and load on authoritative servers; a high TTL is more efficient but means outages or migrations take longer to reflect for everyone.
- DNS caching happens at multiple layers (OS, browser, resolver) — clearing one cache doesn't guarantee a stale record disappears everywhere immediately.
- A CNAME record can't coexist with other records at the same name (per the original spec) — a common "why won't this record save" surprise when setting up a root domain alias.
- DNS resolution failing and a server being down produce similar symptoms to an end user, but require completely different debugging (
dig/nslookup vs. checking the server itself).
Related terms
- CORS — a browser's notion of "cross-origin" is ultimately anchored to the hostname DNS resolves, among other origin components.
- Docker — containerized services commonly rely on an internal DNS layer to resolve other container and service names within the same network.
See also
- Tool: IPv4 Address Analyzer — inspect and validate the IP addresses that DNS A records ultimately resolve domain names to.