Cloud Parts

DNS

The internet’s phone book: turns names into addresses.

3 technologies on this page ↓
Live model
What you’re watchingThe browser asks a resolver. Cached answers return right away; on a miss the resolver asks the authoritative server (after walking the root and TLD servers, in reality) and caches the result.

How it works

DNS translates a name like api.example.com into an IP address. Your device asks a resolver, which answers from its cache or walks the hierarchy (the root, then .com, then your domain’s authoritative servers) and caches the answer for the record’s TTL. Cloud DNS services add health-checked failover and routing by latency or geography.

Think of it as

Calling a contact from your phone instead of memorizing their number. If they get a new number, you update the contact and every call still goes through.

Reach for it when

  • Giving every service a stable name
  • Failing over between regions or providers
  • Moving infrastructure without changing client configuration

Think twice when

  • Instant cutovers: cached answers live until their TTL expires
  • Fine-grained load balancing, since clients cache and choose records unpredictably

A real example

api.example.com has a 60-second TTL and health-checked records in two regions. When us-east-1 fails its check, Route 53 starts answering with the us-west-2 address, and most clients follow within a minute or two.

Technologies

Specific products, and what each does differently.

What each provider calls it

AWS
Route 53
Google Cloud
Cloud DNS
Azure
Azure DNS
Open source & others
BIND, CoreDNS, PowerDNS; Consul for service discovery over DNS; also Cloudflare DNS

In code · bash

$ dig +noall +answer api.example.com
api.example.com.   60   IN   A   203.0.113.10
#                  ^^ TTL: resolvers may reuse this answer for 60 s

Often confused with

CDNsLoad balancersService discovery & mesh
Where it came from1983–2026

On the early ARPANET, every host’s name and address lived in one file, HOSTS.TXT, maintained by the Network Information Center at SRI and copied by every machine over FTP. That worked while the network was a modest number of large timeshared computers. By the early 1980s it was breaking: the bandwidth spent distributing new copies grew with the square of the number of hosts, and organizations running their own local networks had to wait for the NIC to publish every change.

In November 1983 Paul Mockapetris at USC’s Information Sciences Institute proposed the Domain Name System in RFC 882 and 883. Names became a tree, split into zones that each organization runs on its own name servers, with resolvers caching answers along the way. In 1984 four Berkeley graduate students described BIND, a name server for Unix systems, and in 1987 RFC 1034 and 1035 set out the version still in use.

Later work bolted on what the original lacked. DNSSEC added signatures, and the root zone was signed in July 2010. DNS over TLS (2016) and HTTPS (2018) hid queries from eavesdroppers. Cloud services such as Route 53 (2010) turned DNS into a traffic-steering tool with health checks and latency routing, while public resolvers like Google Public DNS (2009) and Cloudflare’s 1.1.1.1 (2018) competed on speed and privacy.

Why it’s built this way

A hierarchy of delegated zones
Handing each part of the tree to its owner removed the central bottleneck: a university or company can change its own names without asking anyone, and no single server holds everything.
Caching controlled by the data’s owner
RFC 1034 says the source of the data should control the trade-off between lookup cost, update speed and accuracy. That is the TTL on every record, and why changes take time to reach everyone.
Typed records, not just host addresses
Mockapetris designed for host addresses, mailbox data and “other as yet undetermined information”. That generality is why DNS now also carries mail routing, service discovery and domain verification.
Small queries over UDP
A lookup and its answer usually fit in one UDP packet each (originally capped at 512 bytes), which keeps lookups fast and servers cheap. TCP is used for zone transfers and large answers.

Timeline

  1. 1983

    Paul Mockapetris publishes the first DNS specs, RFC 882 and 883

  2. 1984

    Four UC Berkeley graduate students describe BIND, a DNS server for Unix

  3. 1987

    RFC 1034 and 1035 define DNS as it is still used

  4. 2010

    The root zone is signed with DNSSEC in July; Route 53 launches

  5. 2018

    DNS over HTTPS standardized (RFC 8484); Cloudflare launches 1.1.1.1

  6. 2026

    ICANN opens a new round of applications for top-level domains

Sources10

Improve this page on GitHub