Before your servers do anything, before a load balancer sees a byte, one question must be answered: where is example.com?
Computers cannot route to names. They route to IP addresses like 93.184.216.34. DNS is the system that turns one into the other, and it runs before every single request to your system.
This makes it the first component in every architecture — and, if you get one setting wrong, the reason an outage lasts four hours instead of thirty seconds.
The lookup
You type example.com. Four parties are consulted, in order:
Diagram, as text
- Browser leads to Resolver your ISP
- Resolver your ISP leads to Root server
- Root server leads to .com server
- .com server leads to Authoritative nameserver
- Authoritative nameserver leads to Resolver your ISP (93.184.216.34)
The resolver is the workhorse, usually run by your ISP or a public service such as 8.8.8.8. Your browser asks it once and it does the rest.
A root server knows nothing about example.com, but it knows who handles .com. There are 13 root server addresses worldwide, served by many machines.
The TLD server for .com knows which nameservers are authoritative for example.com.
The authoritative nameserver is the one holding your actual records. It answers 93.184.216.34.
Four round trips sounds slow, and it would be — except almost none of them usually happen.
Caching is what makes it work
Every answer carries a TTL (time to live) saying how long it may be cached. Answers get cached at every level: your browser, your operating system, your resolver.
The practical effect: the first person on an ISP to look up a domain triggers the full walk. Everyone after them gets an instant cached answer. In reality the overwhelming majority of lookups never leave the resolver.
This is a very deliberate design. The internet's naming system handles enormous volume because it is read-heavy, tolerant of staleness, and cached aggressively — a pattern you will meet again and again in this course.
TTL is an operational decision
Here is where DNS stops being trivia and becomes something that affects your incident response.
TTL is a promise you make: nobody needs to ask again for this long. That promise is also a constraint, because you cannot recall a cached answer.
Suppose your server dies and you need to point the domain elsewhere. You update the record immediately. But every resolver that cached the old address keeps serving it until its copy expires.
| TTL | Lookups | Time to fail over |
|---|---|---|
| 60 seconds | High volume on nameservers | ~1 minute |
| 1 hour | Moderate | Up to 1 hour of outage |
| 24 hours | Very low | Up to a day pointing at a dead server |
The records that matter
You will meet a handful in practice:
| Type | Maps | Example use |
|---|---|---|
| A | Name to IPv4 | example.com to 93.184.216.34 |
| AAAA | Name to IPv6 | The IPv6 equivalent |
| CNAME | Name to another name | www to example.com |
| MX | Mail routing | Where email for the domain goes |
| TXT | Arbitrary text | Domain verification, SPF records |
| NS | Delegates a zone | Which nameservers are authoritative |
DNS as an architectural tool
Beyond naming, DNS is used to make routing decisions, because it sits before every request.
Geographic routing. Return different addresses depending on where the query came from, so European users get the European datacentre. This is how global services reduce latency at the coarsest level.
Load distribution. Return several A records for one name and clients spread across them. This is crude — DNS has no idea which server is healthy or loaded — but it costs nothing and works as a first layer, typically in front of real load balancers.
Failover. Health-checking DNS providers stop returning the address of a datacentre that fails. Note the constraint from earlier: failover is only as fast as your TTL.
What DNS costs you
Two effects worth designing around.
The first visit is slower. An uncached lookup can add 20–120ms before any request is sent. That is why dns-prefetch and preconnect hints exist — they start the lookup for third-party domains early, in parallel with page rendering.
Every extra domain is another lookup. A page pulling fonts, analytics and images from six different domains pays six lookups. Consolidating domains is a real, if unglamorous, performance win.
Check your understanding
Common mistakes
Treating DNS as instant. "Propagation" is not a push; it is caches expiring at their own pace. Plan changes around TTL.
Leaving a long TTL in place permanently. Convenient until the day you need to move quickly.
Forgetting DNS is a single point of failure. If your nameservers are unreachable, your service is unreachable even though every server is healthy. Use multiple nameservers, ideally across providers.
Assuming DNS load balancing is load balancing. It distributes names, not load. It cannot see server health, connection counts or response times — use it in front of a real load balancer, not instead of one.
Practice
You must move a busy service to new infrastructure with no downtime and no split-brain — writes must never land in both places at once. Design the DNS side of the cutover, with timings.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
Work backwards from the longest a stale answer can survive.
Show a strong answer
DNS alone cannot give you a clean switch, so the plan has to make DNS approximately right and something else exactly right.
Days before: lower the TTL, in stages. If it currently sits at 3600, drop it to 300, wait a full hour so every cached copy of the old TTL has expired, then drop to 60 and wait five minutes. Lowering straight to 60 does not help resolvers that already hold the 3600-second answer.
At cutover: do not point the name at a different set of servers and hope. Instead:
- Put both old and new behind a stable entry point — a load balancer or anycast address — so the address in DNS never changes.
- Make the old side read-only or forwarding the moment the new side takes writes. This is what actually prevents split-brain; DNS timing cannot.
- Shift traffic at the load balancer, which is immediate and uniform.
If you truly must change the address: accept a window of at least one old TTL where both addresses receive traffic, and keep the old address serving — forwarding to the new one — for far longer than the TTL suggests. Some resolvers and client libraries cache far beyond the TTL, and some pin an address for the life of the process.
Afterwards: raise the TTL again. A permanently low TTL costs a lookup on nearly every connection and makes your resolver a hard dependency of every request.
A team proposes round-robin DNS — several A records for one name — as their load balancing strategy. Give three reasons this distributes load poorly, and say when it is nonetheless the right choice.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
Ask who decides which address gets used, and what happens when one of them dies.
Show a strong answer
Three reasons it distributes poorly:
- You do not control the choice. The resolver and the client library pick, and many pick the first address, or cache one for the process lifetime. Traffic ends up lumpy rather than even.
- It has no idea what load is. Round-robin hands out addresses in turn regardless of how many connections each server already has or how heavy those connections are. One address can receive all the expensive requests.
- It cannot remove a dead server. There is no health check. A failed address stays in rotation until a human edits the zone, and then stays cached afterwards. Clients that retry may get the same dead address again.
When it is right anyway: distributing across entry points rather than servers — several load balancers, or several regional endpoints. At that level you are not trying to balance precisely; you are spreading traffic across independent failure domains and letting each one balance properly behind its own address. It is also the only option when there is no layer to put in front, such as distributing an anycast set across continents.
Key takeaways
- DNS turns names into addresses, and it runs before every request your system ever receives.
- The lookup walks resolver → root → TLD → authoritative, but caching means it usually stops at the resolver.
- TTL is an operational decision: it trades lookup volume against how fast you can fail over, and a cached answer cannot be recalled.
- Lower TTLs a day before planned changes, then raise them again.
- A CNAME cannot sit on the root domain, which is why providers offer ALIAS/ANAME records.
- DNS enables geographic routing and coarse failover, but it cannot see server health — it complements load balancers rather than replacing them.
Next: once DNS has told the client where to go, something must decide which of your servers actually handles the request.
Further reading
- RFC 1034 and RFC 1035, Domain Names — Concepts and Facilities / Implementation and Specification — the original design, still authoritative.
- RFC 8499, DNS Terminology — the precise meanings of resolver, authoritative server, zone and delegation.
- RFC 7766 and RFC 7858 — DNS over TCP and DNS over TLS, and what they change about latency.
- Paul Mockapetris and Kevin Dunlap, "Development of the Domain Name System" (SIGCOMM 1988) — why caching and hierarchy were chosen.
- Cricket Liu and Paul Albitz, DNS and BIND, fifth edition (O'Reilly, 2006) — the practical operations reference.