🌐 Domain Configuration

You've built the app, secured it with HTTPS, and deployed it to a server with an IP address like 203.0.113.10. But nobody types IP addresses. This lesson connects a memorable name — yourapp.com — to your running server, using the internet's address book: DNS.

Week 13 · Day 5 (Friday: Production Deployment) · Lecture 3

🎯 Learning Objectives

By the end of this lesson, you will be able to:

Explain how DNS resolves a name to an IP address through recursive and authoritative servers
Choose the right record type — A, AAAA, CNAME, TXT, MX — for each job
Distinguish the apex domain from the www subdomain and handle each correctly
Use TTL deliberately to control caching and plan low-downtime changes
Point a domain at a host or load balancer using managed DNS
Verify records and diagnose propagation with dig

Estimated Time: 65 minutes

Practice: Design a complete DNS record set for a production app with a website, API, and email.

In This Lesson

DNS: The Internet's Phone Book

Computers talk to each other using IP addresses — 203.0.113.10 (IPv4) or 2606:2800:220:1:248:1893:25c8:1946 (IPv6). Humans, sensibly, prefer names. The Domain Name System (DNS) is the global, distributed directory that translates names into addresses, usually in well under 100 milliseconds.

The analogy is a phone's contacts. You tap "Mom," not a ten-digit number; your phone looks it up. DNS does the same for example.com, and like a contacts list, the answers are cached so repeat lookups are instant. Understanding this lookup — and the records that drive it — is what lets you confidently attach a domain to anything you deploy.

📖 Three roles to keep straight

A registrar (Namecheap, Cloudflare, Porkbun) is where you buy and own the domain. A DNS provider (often the same company, or Cloudflare/Route 53) hosts the records. A host (Render, a VPS, an S3 bucket) is where the app actually runs. DNS is the wiring between the name you own and the machine that answers.

How Resolution Works

When you visit a site for the first time, your browser doesn't magically know the IP. It asks a recursive resolver (usually run by your ISP or a public one like 8.8.8.8), which walks a hierarchy of servers on your behalf.

sequenceDiagram participant B as Browser participant R as Recursive Resolver participant Root as Root Server participant TLD as .com TLD Server participant Auth as Authoritative Server B->>R: What is the address for example.com R->>Root: Where are the dot com servers Root->>R: Ask the dot com TLD servers R->>TLD: Where is example.com TLD->>R: Ask the authoritative servers for example.com R->>Auth: What is the address for example.com Auth->>R: The address is 203.0.113.10 R->>B: The address is 203.0.113.10

Read it top to bottom: the resolver climbs from the root (which knows where every TLD lives), to the .com TLD servers (which know your domain's nameservers), to your authoritative nameservers (which hold the actual records you configured). Each step's answer is cached, so the next visitor's lookup skips most of the journey.

💡 Authoritative = your control point

The authoritative nameservers are the ones your DNS provider runs. When you edit an A record in Cloudflare's dashboard, you're editing what those authoritative servers return. Everything upstream just points the way to them.

DNS Record Types

A DNS zone is a list of records, each mapping a name to some value. You'll use a handful constantly.

Type	Maps a name to…	Example value
A	An IPv4 address	`203.0.113.10`
AAAA	An IPv6 address	`2606:2800:220:1::1946`
CNAME	Another name (an alias)	`myapp.onrender.com`
TXT	Arbitrary text (verification, SPF)	`"v=spf1 include:_spf.google.com ~all"`
MX	A mail server (with priority)	`10 mail.example.com`
NS	The authoritative nameservers	`ns1.provider.com`

A and AAAA — the destination

These are the workhorses: they point a name directly at a server's IP. Provide both an A (IPv4) and an AAAA (IPv6) record when your host supports IPv6, so every client reaches you the fastest way.

# Zone-file style. "@" means the apex (example.com itself).
@       IN  A       203.0.113.10
@       IN  AAAA    2606:2800:220:1::1946

CNAME — an alias to another name

A CNAME says "for this name, go look up that other name instead." It's how you point at a managed host whose IP you don't control (and which may change).

# www is an alias for the app's platform hostname
www     IN  CNAME   myapp.onrender.com.

⚠️ The CNAME-at-apex problem

The DNS spec forbids a CNAME on the apex (example.com with no subdomain), because the apex must also carry other records like MX and NS. This is a classic gotcha — you can't simply CNAME your root domain to a platform. See the next section for the fix.

TXT — text for machines

TXT records hold plain text that other services read. Two everyday uses:

Ownership verification — a host or CA asks you to add a specific TXT value to prove you control the domain (this is also the DNS-01 challenge from the SSL lesson).
Email authentication — SPF, DKIM, and DMARC records that tell the world which servers may send mail as your domain.

# SPF: only Google's servers may send mail for this domain
@       IN  TXT     "v=spf1 include:_spf.google.com ~all"
# Domain verification token from a hosting provider
@       IN  TXT     "site-verification=abc123def456"

MX — where email goes

MX records route email for your domain to a mail provider. The number is a priority — lower is preferred, so backups can be listed.

# Google Workspace mail routing
@       IN  MX      1 smtp.google.com.

Apex vs www

Users type both example.com and www.example.com, and both must work. But they're technically different names and are configured differently.

Apex (a.k.a. root, naked, or bare domain): example.com with nothing in front. Needs an A/AAAA record — or a provider's special ALIAS/ANAME record — because CNAME is illegal here.
www: the www subdomain. Can be a plain CNAME to the apex or to your host.

Both names should land on the same app. Pick one as canonical and redirect the other for clean URLs and SEO.

Decide which form is canonical (say, the apex) and 301-redirect the other to it at the app or proxy level. This avoids duplicate-content SEO penalties and keeps analytics tidy. Many managed platforms offer a one-click "redirect www to apex" toggle.

TTL & Propagation

Every record carries a TTL (Time To Live) in seconds — how long resolvers are allowed to cache the answer before asking again. TTL is the single biggest lever over how fast a change takes effect.

TTL	Trade-off	Good for
`300` (5 min)	Fast changes, more lookups	Records you're about to change
`3600` (1 hr)	Balanced	Most everyday records
`86400` (1 day)	Fewer lookups, slow to change	Stable records (MX, TXT)

So-called "propagation" isn't records physically spreading across the world — it's simply old cached answers expiring. If a record had a 24-hour TTL, some resolvers may serve the stale value for up to 24 hours after you change it.

✅ The low-downtime migration trick

Planning to move a domain to a new server? Lower the TTL to 300 a day or two before the switch. Caches worldwide will then hold the record for only 5 minutes, so when you flip the IP the change is nearly instant. Raise the TTL back afterward to cut lookup load.

⚠️ Nameserver changes are slower

Changing a record's value obeys that record's TTL. Changing your domain's nameservers at the registrar is governed by the parent zone and can take far longer — often quoted as "up to 24–48 hours." Do that step first when setting up a new provider.

Pointing at Your Host

How you point the domain depends on what you're pointing at. Here are the three common shapes.

graph TD A["yourapp.com"] --> B{"What is the target?"} B -->|"A fixed server IP"| C["A / AAAA record to the IP"] B -->|"A managed platform hostname"| D["CNAME to the platform
ALIAS at the apex"] B -->|"Behind a load balancer"| E["A record to the LB IP
or CNAME to the LB name"] C --> F["Traffic reaches your app"] D --> F E --> F

1. A VPS with a fixed IP

# Point both apex and www straight at the server
@       IN  A       203.0.113.10
www     IN  CNAME   example.com.

2. A managed platform (Render, Vercel, Netlify)

These give you a hostname, not an IP, and expect a CNAME. For the apex — where CNAME is illegal — use the provider's ALIAS/ANAME record (which behaves like a CNAME but returns an A record), or the flattened-CNAME feature offered by Cloudflare and others.

www     IN  CNAME   myapp.onrender.com.
@       IN  ALIAS   myapp.onrender.com.   # provider-specific apex alias

3. Behind a load balancer

Cloud load balancers (AWS ALB, GCP LB) usually provide a DNS name. Point www at it with a CNAME; for the apex use your provider's ALIAS (or, on Route 53, an "alias A record" to the ELB).

💡 Managed DNS is worth it

Providers like Cloudflare or AWS Route 53 run globally distributed anycast nameservers, so lookups resolve from a nearby location fast, with high uptime and DDoS resilience. Cloudflare's free tier also solves the apex-CNAME problem via "CNAME flattening." For production, prefer managed DNS over your registrar's basic service.

Verifying with dig

Never assume a DNS change worked — check it. dig is the standard tool for querying DNS from the command line.

# The A record for a domain (just the answer)
dig A example.com +short

# See the TTL and full answer section
dig A example.com

# Query a specific resolver (Google's) to bypass your local cache
dig @8.8.8.8 A example.com +short

# Check other record types
dig AAAA example.com +short
dig CNAME www.example.com +short
dig MX example.com +short
dig TXT example.com +short
dig NS example.com +short

# Follow the whole resolution path from the root down
dig +trace example.com

Output

$ dig A example.com +short
203.0.113.10

$ dig CNAME www.example.com +short
example.com.

To watch worldwide propagation, the web tool whatsmydns.net queries dozens of resolvers around the globe at once — handy for confirming a change has reached everyone before you announce a launch.

Practice & Quiz

🏋️ Exercise 1: A production record set

Goal: Write the DNS records for shop.dev so that: the apex points to the server IP 198.51.100.7, www aliases the apex, api points to the same IP, and mail is handled by smtp.google.com.

💡 Hint

Apex and api need A records (both use IPs). www can be a CNAME to the apex. Mail uses an MX record with a priority number.

✅ Solution

@       IN  A       198.51.100.7
api     IN  A       198.51.100.7
www     IN  CNAME   shop.dev.
@       IN  MX      1 smtp.google.com.

🏋️ Exercise 2: Plan a zero-surprise IP change

Goal: Your apex A record currently has a TTL of 86400. You're migrating to a new IP tomorrow. List the steps that minimize downtime, and give the dig command to confirm the new value from a public resolver.

✅ Solution

Now: lower the A record's TTL to 300 and wait for the old 86400 cache to expire (up to a day).
At migration time: change the A record to the new IP — caches refresh within ~5 minutes.
Verify, then raise the TTL back to 3600+.

dig @8.8.8.8 A example.com +short   # should show the new IP

🎯 Quick Quiz

Question 1: Why can't you put a CNAME record on the apex domain?

Question 2: You lowered a record's TTL to 300 yesterday. What does that buy you?

Question 3: Which record maps a name directly to an IPv6 address?

Best Practices & Pitfalls

✅ Do

Provide both A and AAAA records when your host supports IPv6
Make both apex and www work; pick one canonical and 301-redirect the other
Lower the TTL before a planned migration, then raise it back
Use managed DNS (Cloudflare, Route 53) for anycast speed and resilience
Always verify with dig against a public resolver after a change

❌ Don't

Try to CNAME the apex — use ALIAS/ANAME or CNAME flattening instead
Assume a change is instant; respect the record's TTL
Forget to enable registrar auto-renewal and 2FA (an expired or hijacked domain is game over)
Leave stale A records pointing at decommissioned servers (subdomain-takeover risk)

⚠️ The expired-domain outage

The most avoidable production disaster is a domain that quietly expires. Turn on auto-renewal, keep the registrar contact email current, and enable a registry/registrar lock to block unauthorized transfers. Your certificate and DNS mean nothing if you lose the name itself.

Summary

🎉 Key Takeaways

DNS resolves names to IPs via recursive → root → TLD → authoritative servers, with caching at every hop
A/AAAA point at IPs, CNAME aliases a name, TXT verifies and authenticates, MX routes mail
The apex needs A/AAAA (or ALIAS); only subdomains can use CNAME
TTL controls caching — lower it before a migration for near-instant changes
Use managed DNS and always confirm changes with dig

📚 Additional Resources

🚀 What's Next?

You've now assembled every production piece: a readiness checklist, HTTPS certificates, and a domain wired to your host. In the capstone, you'll bring it all together — Deploy and Monitor a Full-Stack Application — taking a real app live and watching it run.

🌐 On the map

Your app has a name the world can find, an address that resolves fast, and a padlock that keeps it safe. That's a real production presence.