Domain Name System (DNS)

What is DNS?

DNS is often described as the phone book of the internet. When you type example.com, DNS resolvers look up which IP address (or CDN endpoint) should receive your request.

How a lookup works (simplified)

Browser checks local cache
Query goes to a recursive resolver (often your ISP or 1.1.1.1 / 8.8.8.8)
Resolver walks the hierarchy: root → .com TLD → authoritative nameserver for example.com
Returns an A record (IPv4), AAAA (IPv6), or CNAME (alias)

Common record types

Record	Purpose
A / AAAA	Points name to IP address
CNAME	Alias to another hostname
MX	Mail server routing
TXT	Verification, SPF, DKIM
NS	Delegates zone to nameservers

DNS in cloud architecture

Route 53, Cloud DNS, and Azure DNS host zones and health-checked routing
TTL (time to live) controls how long resolvers cache answers — lower TTL speeds up failover changes
Geo routing sends users to regional endpoints

Security note

DNS is unauthenticated by default. DNSSEC adds cryptographic signatures. Cloud teams also monitor for hijacking and use short TTLs during migrations.

What people get wrong

High TTLs before a migration. A 24-hour TTL means a day of traffic split between old and new servers; drop TTLs to 60s days before the cutover, raise them after.
Forgetting DNS is cached everywhere. Your change propagating “instantly” in your terminal says nothing about a resolver in another country still holding the old answer.
Dangling records. CNAMEs pointing at deleted cloud resources are a subdomain-takeover vulnerability, not just clutter — audit records when tearing infrastructure down.

The DNS Resolution Chain

A single DNS lookup typically involves several servers working together in sequence: a recursive resolver (often provided by an ISP or a public service like Google’s 8.8.8.8) receives the initial query and, if it doesn’t already have the answer cached, queries a root server to find the appropriate top-level domain (TLD) server, then queries that TLD server to find the domain’s authoritative name server, and finally queries that authoritative server for the actual record. This entire chain typically completes in milliseconds thanks to aggressive caching at every level, but it’s worth understanding when diagnosing DNS propagation delays or debugging why a DNS change isn’t taking effect as quickly as expected somewhere in that resolution chain.

Time To Live (TTL) values attached to each DNS record control how long each layer of this chain is allowed to cache the answer before checking again, which is the direct mechanism behind DNS propagation delays whenever a record changes.