Networking
DNS
How names become addresses, which record types matter, how caching and TTLs shape change speed, and why DNS failures look like outages of everything else.
The Domain Name System (DNS) maps names like api.example.com to records, most often IP addresses. Nearly every request your service handles starts with a DNS lookup, and nearly every failed deploy involves a DNS record somewhere. Engineers forget DNS as a system until something breaks. Then it's the first place to look.
DNS is a distributed, cached database. Each zone is owned by someone, the answers are cached at many layers, and each answer carries a time-to-live (TTL) that controls how long it can be reused.
The big idea
A lookup for api.example.com walks down a hierarchy. The resolver asks the root servers, which point to the .com servers, which point to the example.com name servers. The authoritative server gives the answer. Each step is cached, and the cache is what makes DNS fast and also what makes changes slow.
Live example
A real lookup shows the record types and TTLs. Run this twice, a few seconds apart, and the TTL counts down:
$ dig +noall +answer example.com A
example.com. 201 IN A 104.20.23.154
example.com. 201 IN A 172.66.147.243
$ dig +noall +answer www.github.com CNAME
www.github.com. 3600 IN CNAME github.com.Two numbers in the first answer matter. 201 is the TTL: how long a resolver may keep the answer. The IN is the class, Internet. The second answer is a CNAME, an alias that points one name at another. Your resolver follows the alias, then looks up github.com as well.
Concepts in this topic
| Step | Concept | What it answers |
|---|---|---|
| 1 | DNS resolution walk | What happens between a name and an IP address? |
| 2 | TTLs and caching | How fast does a change reach users? |
| 3 | Traffic steering and anycast | How do DNS and IP routing send users to the right place? |
| 4 | Outages and ndots | Why do DNS failures spread across services? |
| 5 | DNS security | How do you trust an answer, and keep it private? |
Record types you'll use
| Type | Holds | Notes |
|---|---|---|
| A | IPv4 address | The most common answer |
| AAAA | IPv6 address | Use alongside A for dual-stack hosts |
| CNAME | Alias to another name | Cannot sit at the zone apex, and can't coexist with other records on that name |
| MX | Mail server, with a priority | Used for email delivery |
| TXT | Free text | Verification tokens, SPF, DKIM policy |
| NS | Name servers for a zone | Set at the parent and in the zone |
| SOA | Zone metadata | Serial number and negative-cache TTL |
Common mistakes
- Treating a DNS change as instant. Caches hold the old answer until the TTL runs out, and some resolvers ignore small TTLs.
- Putting a CNAME on the bare domain, which DNS forbids, so a load balancer or CDN endpoint has to be reached through an A record or ALIAS-style record.
- Forgetting that a failing DNS server looks like a failing application, because every request starts with a lookup.
Key takeaways
- DNS is a hierarchy with caches at every layer, and TTLs control how long each answer lives.
- A change propagates only after the old TTL expires everywhere, so plan migrations around that.
- Know the record types, especially CNAME's limits at the apex.
- DNS problems look like outages of everything else, so monitor resolution directly.
Further learning
Next, see the resolution walk to trace each step of a lookup.
Related
Networking: IP, TCP and UDP
Packets, addresses, ports, and the handshakes and congestion control that decide how fast your bytes arrive. Explains why a new connection is slow and how to check it on the wire.
Life of a request
Every step between typing a URL and seeing a page, with a latency budget for each hop, why the second request is faster, and a method for finding where a slow request loses its time.
Load balancers, DNS and the edge in the cloud
Configuring the traffic layer, from DNS and cloud load balancers through TLS, WAF and CDN to a regional traffic shift. Start here for the map of edge pages.
Caching
Where to put a cache, how to read and write through it, how to size it from hit-rate math, and how to keep it from serving stale data or melting down.