DevOps
DNS
The internet's phone book, resolving human names to IP addresses through a hierarchy of records — A/AAAA, CNAME, MX, TXT — cached according to their TTL. It also underpins load balancing, email authentication (SPF/DKIM) and domain verification. The gotcha is propagation: TTLs mean changes take time, so lower them before a migration.
Purpose
DNS translates human-readable names into IP addresses through a global, hierarchical, heavily cached database. Beyond simple lookup it carries service metadata — mail routing (MX), ownership proofs and email authentication (TXT: SPF, DKIM, DMARC) — and is a routing layer in its own right.
When to Use It
Pointing domains at servers and CDNs (A/AAAA, CNAME/ALIAS), verifying domain ownership for certificates and SaaS, geo- and latency-based routing, and blue-green cutovers by flipping records. Every outage postmortem eventually mentions it — 'it is always DNS' is a joke because it is half true.
Trade-offs
Caching gives DNS its scale and its lag: a record with a long TTL keeps resolving to the old value until caches expire, so changes 'propagate' slowly. Very short TTLs make changes fast but raise query load and dependence on your DNS provider's availability.
Implementation
Know the record types (A/AAAA, CNAME, MX, TXT, NS) and how TTLs govern caching. Before a planned migration, drop the TTL in advance, move, verify, then raise it again. Host zones with a reliable provider, and remember the apex domain cannot be a true CNAME — use ALIAS/ANAME where needed.