DNS (Domain Name System): Resolution, Records & TTL

Q: What's the difference between an A record and a CNAME?

An A record maps a name directly to an IPv4 address (AAAA does the same for IPv6) — it's the terminal answer, "this name lives at this IP." A CNAME maps a name to another name (an alias), so the resolver then looks up that name's records. CNAMEs are useful for pointing www.example.com at example.com, or pointing your domain at a CDN/host's domain whose IPs you don't control and which may change. A key rule: you generally can't put a CNAME at the apex/root of a domain (use an A record or a provider's "ALIAS/ANAME"), and a name with a CNAME shouldn't have other records.

DNS (Domain Name System)

DNS is the internet's phone book — the system that translates human-friendly domain names (example.com) into the IP addresses (93.184.216.34) that machines actually use to find each other. Nobody memorizes IP addresses; we type names, and DNS does the lookup behind the scenes, billions of times a second. It's invisible when it works and catastrophic when it doesn't: a huge share of "the site is down" incidents are actually DNS problems, which is why understanding it is essential for anyone deploying anything on the internet.

Beyond name resolution, DNS quietly underpins much more — it routes traffic, directs email (MX records), verifies domain ownership (TXT records), and even enables global load balancing and failover. And its caching behavior, governed by TTL, is the source of both its scalability and its most famous frustration: changes don't take effect instantly ("DNS propagation"). Grasping records, resolution, and TTL covers most of what you'll need in practice.

TL;DR

DNS resolves domain names → IP addresses so machines can connect.
Record types do different jobs: A/AAAA (IP), CNAME (alias), MX (mail), TXT (verification).
Caching + TTL make DNS fast — but mean changes take time to "propagate."
DNS issues cause a surprising share of outages — it's a critical dependency.

Quick Example

A domain's records map names to addresses and services:

How Resolution Works

When you request example.com, a chain of lookups finds its IP:

Browser/OS cache — checked first; if known, done instantly.
Recursive resolver (your ISP's or e.g. 8.8.8.8) — does the work on your behalf.
Root servers → point to the TLD servers (.com).
TLD servers → point to the domain's authoritative nameservers.
Authoritative nameserver → returns the actual record (the IP).

The resolver caches the answer (per its TTL), so subsequent lookups skip most of this. This hierarchy + caching is what lets DNS scale to the entire internet.

Common Record Types

Caching & TTL

Every record has a TTL (time to live) — how long resolvers may cache it before re-querying. This is the key operational lever:

High TTL (hours/days) — fewer lookups, faster, cheaper; but changes take that long to take effect.
Low TTL (minutes) — changes propagate fast; more lookups.

💡 Before a planned DNS change (e.g. moving to a new server), lower the TTL in advance so the switch propagates quickly. "DNS propagation delay" is really just caches honoring the old TTL.

DNS for Routing & Reliability

DNS does more than static lookups:

Global load balancing / GeoDNS — return different IPs based on the user's location or server health.
Failover — health-checked DNS can route away from a down server.
CDN integration — a CNAME points your domain at a CDN that serves from edge locations.

Because DNS is a critical path, use a reliable managed DNS provider with redundancy — a DNS outage takes everything down with it.

Best Practices

Lower TTL before planned changes, then raise it back after.
Use a reliable, redundant DNS provider — it's a single point of failure for everything.
Set SPF/DKIM/DMARC TXT records for email deliverability.
Prefer CNAME/alias to a host/CDN over hardcoding IPs that may change.
Monitor DNS — resolution failures present as total outages.

Common Mistakes

Expecting DNS changes to be instant

Treating DNS as not-your-problem

FAQ

How does DNS resolution actually work?

When you request a domain, your system first checks local caches (browser, OS). On a miss, it asks a recursive resolver (your ISP's, or a public one like 8.8.8.8), which walks the hierarchy: it queries a root server to find the TLD servers (e.g. for .com), queries those to find the domain's authoritative nameservers, and queries those to get the actual record (the IP). The resolver caches the answer for its TTL, so repeat lookups are near-instant. This hierarchical, cached design is how a single system reliably resolves names for the entire internet.

What is TTL and why does "DNS propagation" take time?

TTL (time to live) is how long a DNS record may be cached by resolvers before they must re-query the authoritative source. "DNS propagation delay" — the lag between changing a record and everyone seeing the change — is really just caches around the world continuing to serve the old value until its TTL expires. There's no central push; each resolver refreshes on its own schedule per the TTL. That's why, before a planned change like migrating servers, you lower the TTL in advance (so caches expire quickly), make the change, and the switch then propagates in minutes instead of hours or days.

What's the difference between an A record and a CNAME?

An A record maps a name directly to an IPv4 address (AAAA does the same for IPv6) — it's the terminal answer, "this name lives at this IP." A CNAME maps a name to another name (an alias), so the resolver then looks up that name's records. CNAMEs are useful for pointing www.example.com at example.com, or pointing your domain at a CDN/host's domain whose IPs you don't control and which may change. A key rule: you generally can't put a CNAME at the apex/root of a domain (use an A record or a provider's "ALIAS/ANAME"), and a name with a CNAME shouldn't have other records.

Why are DNS problems such a common cause of outages?

Because DNS sits on the critical path of essentially every request — if a name can't be resolved, the service is unreachable even when the servers are perfectly healthy. Common failure modes are surprisingly mundane: an expired domain registration, a misconfigured or deleted record, a too-aggressive TTL change, or an outage at a single DNS provider taking down everything that depends on it. Because it's invisible when working, DNS is easy to neglect, then it fails dramatically. Mitigate with a redundant managed DNS provider, monitoring of resolution, and careful, deliberate record and TTL management.