<aside> 🧭
Module 08 · DNS in the Cloud & in Kubernetes
Seven modules of DNS as a protocol. This is DNS as a DevOps engineer actually meets it: Route 53 alias records and routing policies, private hosted zones and split-horizon, then CoreDNS — where Module 06's ndots arithmetic becomes the notorious five-second Kubernetes timeout.
🧠 concept → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (answers hidden)
Prerequisite: Modules 01–06. You need CNAME-at-apex (02 C3), delegation (03), TTLs and caching (03 B), the ndots rule (06 B3), and getent versus dig (06 A).
</aside>
<aside> 🧹
The analogy. Think of hiring a cleaning service instead of buying a mop.
The floors end up equally clean. What you actually bought was not owning the equipment, the rota, or the cover when someone is off sick.
A hosted zone is the same trade: the records are identical, and what you have handed over is the servers, the copies, and the version numbers — along with the ability to inspect any of it.
</aside>
<aside> 📖
Official docs: Amazon Route 53 — Supported DNS record types · Choosing between alias and non-alias records
</aside>
A hosted zone is a zone file with an API in front of it. Everything from Module 02 still applies — RRsets, TTLs, the CNAME rules — and Module 05's operational burden is what you are paying to avoid: no named.conf, no serial numbers, no zone transfers, no secondaries to keep in sync.
<aside> 🔑
Module 02 D1 read seamless.se's four awsdns nameservers and concluded "this is Route 53". That inference is the practical value of knowing the protocol: the NS record set names your provider, and from there you know which console, which API, which quirks, and which of this module's sections apply.
And Module 05 explains what you gave up. Route 53's SOA serial is a constant 1 because it replicates internally rather than by AXFR. There are no secondaries to fall out of sync, so the entire class of failure in Module 05 C3 simply cannot happen — and neither can you inspect or control the replication.
</aside>
<aside> 🤝
The analogy. Think of a receptionist who quietly looks something up and reads the answer back to you as if she had always known it.
From where you are standing nothing unusual happened — you asked a question and got a normal answer. The looking-up happened behind the counter.
Which explains the two catches: you cannot tell from outside that it happened, and if you change receptionist, the new one has to be taught all the same lookups by hand.
</aside>
<aside> 📖
Official docs: Choosing between alias and non-alias records · Values specific for simple alias records · RFC 2181 §10.1
</aside>
Module 02 C3 established the rule: a CNAME cannot sit at a zone apex, because the apex must carry SOA and NS. Every provider sells a way around it.
| Provider | Name for it |
|---|---|
| Route 53 | alias record |
| Cloudflare | CNAME flattening |
| DNSimple, easyDNS | ALIAS |
| DNS Made Easy and others | ANAME |
<aside> 🔑
None of them is a DNS feature, and understanding that tells you every consequence. The authoritative server resolves the target internally and answers with a genuine A or AAAA. What leaves the server is an ordinary address record, so nothing non-standard ever appears on the wire and no resolver needs to know.
Three things follow:
dig shows a plain A. The only way to know is the provider's console or API — which is why an inherited estate hides them<aside> ⚠️
The Route 53 detail worth knowing: alias records to AWS targets are free and health-aware. Queries against an alias pointing at an ELB, CloudFront distribution or S3 website endpoint are not billed, and Route 53 tracks the target's address changes automatically. That is why the AWS-native answer to "point the apex at the load balancer" is always an alias and never a CNAME on www with a redirect.
</aside>