You type github.com into your browser. Within milliseconds, your computer knows the IP address to connect to. This process - translating a human-readable name into a network address - is DNS: the Domain Name System.

DNS is one of those systems that works so reliably that most developers never think about it until it breaks. When it does break - a deployment that didn’t propagate, a misconfigured record, a TTL that’s taking forever to expire - understanding how it works is the difference between fixing it in ten minutes and being confused for an hour.

The Problem DNS Solves

IP addresses are what computers use to route traffic. Humans don’t remember IP addresses. DNS is a distributed database that maps domain names to IP addresses (and other record types).

It’s distributed for good reasons: the internet has hundreds of millions of domain names, they change constantly, and any centralized system would be a catastrophic bottleneck and single point of failure. DNS distributes the work across a hierarchy of servers, each responsible for a portion of the namespace.

The Resolution Chain

When you visit github.com, here’s the complete resolution chain:

1. Local cache check

Your computer first checks its own DNS cache. If you’ve visited github.com recently and the cached record hasn’t expired, it uses the cached IP and the lookup is done. No network requests needed.

2. Recursive resolver

If there’s no cached answer, your computer asks a recursive resolver - typically one configured by your ISP or by you explicitly (Cloudflare’s 1.1.1.1, Google’s 8.8.8.8). The recursive resolver does the work of finding the answer.

3. Root nameserver

The recursive resolver asks a root nameserver: “Who knows about .com?” There are 13 logical root nameserver addresses (operated by multiple organizations, distributed globally via anycast). They don’t know the IP of github.com, but they know who’s responsible for .com.

;; Question
github.com. IN A

;; Root response (simplified)
com. 172800 IN NS a.gtld-servers.net.

4. TLD nameserver

The resolver asks the .com TLD nameserver: “Who knows about github.com?” The TLD server returns the nameservers that GitHub registered as authoritative for their domain.

github.com. 172800 IN NS ns1.p16.dynect.net.
github.com. 172800 IN NS ns2.p16.dynect.net.

5. Authoritative nameserver

The resolver asks GitHub’s authoritative nameserver: “What’s the IP for github.com?” This server has the actual records and returns the answer.

github.com. 60 IN A 140.82.121.4

6. Response returned and cached

The recursive resolver returns the IP to your computer, caching it for the duration specified by the TTL (60 seconds in this example). Your computer caches it too.

The whole process typically takes 20-100ms the first time. Subsequent lookups for cached domains are microseconds.

DNS Record Types

DNS stores more than just IP addresses. Record types determine what a query returns:

A record: maps a domain to an IPv4 address. github.com -> 140.82.121.4

AAAA record: maps a domain to an IPv6 address.

CNAME (Canonical Name): an alias. www.github.com -> github.com. The resolver then looks up the target. CNAMEs can’t coexist with other record types at the same name, which is why you can’t put a CNAME on a zone apex (e.g., on github.com itself, only on www.github.com).

MX record: specifies mail servers for a domain. github.com -> aspmx.l.google.com (with a priority). Email infrastructure uses these to route messages.

TXT record: arbitrary text. Used for domain ownership verification (proving to Google Analytics you own a domain), SPF and DKIM records for email authentication, and various other purposes.

NS record: specifies which nameservers are authoritative for a domain.

SOA (Start of Authority): metadata about a zone - the primary nameserver, the email of the responsible party, and timing parameters including TTL defaults.

TTL and Propagation

Every DNS record has a TTL - Time To Live, in seconds. When a resolver caches a record, it keeps it for TTL seconds before asking again. When you change a DNS record, you’re updating the authoritative nameserver immediately. But resolvers and computers around the world that have the old record cached will continue using the old value until their cache expires.

This is “DNS propagation” - not a mystical worldwide process, just cache expiration. If your TTL is 3600 (one hour), it can take up to an hour for a change to be seen by everyone who has the old record cached.

The practical implication: if you’re planning a migration that involves a DNS change, reduce your TTL days in advance (to 60-300 seconds). Clients will refresh more frequently. After the migration, you can increase the TTL again.

What You Can See From the Command Line

dig is the standard tool for querying DNS:

# A record lookup
dig github.com A

# Full resolution trace (shows each step)
dig +trace github.com

# Query a specific resolver
dig @8.8.8.8 github.com

# Check TTL on a cached record
dig github.com | grep -i ttl

nslookup works similarly and is available on more platforms by default.

Common DNS Problems

Record hasn’t propagated: TTL hasn’t expired for resolvers that cached the old value. Check the current authoritative answer with dig @<authoritative-ns> yourdomain.com. If the authoritative server has the right answer but you’re seeing the old one, you’re seeing a cached response.

CNAME at zone apex: you can’t put a CNAME on your root domain (yourdomain.com). This breaks because the apex needs NS and SOA records, which can’t coexist with a CNAME. Many DNS providers offer “ALIAS” or “ANAME” records that behave like CNAMEs but are implemented differently to work at the apex.

DNS-based load balancing not working as expected: when an A record returns multiple IPs (round-robin DNS), clients may cache one IP and keep using it regardless of which IP is “supposed” to serve traffic now. Round-robin DNS is not load balancing in the true sense - it just provides different starting points for different clients.

Missing AAAA records: if your server has an IPv6 address but your DNS only has A records (IPv4), IPv6-preferring clients will fall back to IPv4 but may experience a slight delay. For dual-stack deployments, add both.

The Part That’s Easy to Forget

DNS is eventually consistent. Changes propagate over time as caches expire. Any system design that requires instant DNS changes globally doesn’t match how DNS works. TTLs are the knob you control - keep them low when you expect changes, high when things are stable to reduce resolver load and improve performance for your users.

When something DNS-related breaks, dig +trace is your first tool. It shows you exactly where in the resolution chain the answer is coming from and what it says.