Domain Name System
The Domain Name System (DNS) is the distributed, hierarchical database and lookup protocol that translates domain names into the data computers need, most often IP addresses. Where a domain name is the label itself, DNS is the machinery that stores records about such labels across millions of servers and answers queries about them in milliseconds, which is why it is often called the phone book of the Internet.
DNS was designed by Paul Mockapetris in 1983 to replace a single shared file. Before it, every machine on the ARPANET-era network copied a file named HOSTS.TXT, maintained centrally at SRI, and the approach buckled as the number of hosts and the frequency of changes grew. Mockapetris's design, first published as RFC 882 and RFC 883 and revised in 1987 as RFC 1034 and RFC 1035, delegated authority instead: each part of the namespace is managed by whoever owns it, and no single machine needs the whole database. Those 1987 documents remain the foundation of DNS today, extended by many later RFCs.
Answering a query involves a chain of cooperating roles, and the chain is what makes DNS scale. An application asks a stub resolver built into the operating system, which forwards the question to a recursive resolver, typically run by an Internet provider or a public service. If that resolver has no cached answer, it walks the hierarchy: it asks a root server where the name's top-level domain is handled, asks the TLD server which servers are authoritative for the domain, and finally asks that authoritative nameserver for the actual record. The root zone is served under thirteen named identities, letters a through m, but each is replicated at hundreds of sites using anycast routing, so the number of physical servers is far larger.
DNS stores typed records, and the type determines what a name means. An A record maps a name to an IPv4 address and an AAAA record to an IPv6 address; CNAME makes one name an alias for another; MX lists the mail servers for a domain; NS names the authoritative servers; TXT holds free-form text that is widely used for ownership verification and email-authentication policies such as SPF and DKIM; and PTR supports reverse lookup from address to name. Every record carries a time to live (TTL), the number of seconds that resolvers may cache it. Caching is why DNS is fast and cheap, and also why a changed record is not seen everywhere at once; the folk term "DNS propagation" is really caches expiring on their own schedules.
Most queries travel as single small UDP datagrams to port 53, falling back to TCP for large responses, and for decades they were sent unencrypted and unauthenticated. That openness allowed forged answers (cache poisoning), so DNSSEC was developed to add digital signatures that let a resolver verify a record came from the zone's owner, although it protects integrity rather than secrecy. Privacy is addressed separately by DNS over TLS and DNS over HTTPS, which hide queries from on-path observers and shift trust to the chosen resolver. Open resolvers have also been abused in amplification attacks, in which a small spoofed request triggers a much larger reply aimed at a victim.
In practice DNS is both a dependency and a tool. Outages in a major DNS provider can make otherwise healthy sites unreachable, which is why services publish several nameservers across providers. Load balancing, geographic routing, service discovery in cloud and Kubernetes clusters, and blue-green deployments all lean on DNS, and an engineer debugging "the site is down" will usually run lookups with dig or nslookup early on. A frequent mistake is to cache an address in application code forever, ignoring the TTL, so that a failover never takes effect.
Read the Domain Name System as a globally shared, cached, delegated directory: a 1983 invention that lets any name be resolved by walking a hierarchy of servers, with typed records and TTLs deciding what each name means and how long the answer may be trusted.