DNS: Resolving Domain Names

Humans remember names (google.com); computers route by numbers (IP — Article 2). DNS (Domain Name System) is the Internet's "phone book," translating names into IPs. It's the first leg of the journey when you open a web page (Article 0), and the source of countless incidents ("it's DNS" is a familiar diagnosis). This article digs into how it works.

DNS is a hierarchical tree

DNS isn't one giant server holding every name — it's a hierarchy, read from a domain name right to left:

   www . example . com .
    │       │       │   └── root — the hidden trailing dot
    │       │       └────── TLD (top-level domain): .com
    │       └────────────── domain: example.com
    └────────────────────── subdomain: www

That maps to three tiers of servers:

• Root servers — know where the TLDs (.com, .org, .vn...) live. There are 13 root clusters (a through m.root-servers.net).
• TLD servers — the servers for .com know which name server manages the domain example.com.
• Authoritative servers — the "authoritative" servers for example.com itself, holding the final answer (the real IP).

No single tier knows everything; each tier only knows "where to ask next." This distributed design is why DNS scales to the whole Internet.

The recursive resolver: someone who asks on your behalf

Your machine doesn't query each tier itself. It asks a recursive resolver (your ISP's DNS server, or a public service like Google's 8.8.8.8 or Cloudflare's 1.1.1.1). The resolver handles the sequential querying for you:

   Browser needs the IP of example.com:

   (1) Already in cache? ──yes──► answer immediately
   (2) ──no──► ask the Recursive Resolver (e.g. 1.1.1.1):
           │
           ├─► Root:          "where is .com managed?"      ──► "TLD .com is at ..."
           ├─► TLD .com:      "where is example.com?"        ──► "authoritative ns at ..."
           └─► Authoritative: "what's the IP of example.com?" ──► "93.184.x.x"
   (3) Resolver returns the IP to you + CACHES it (per TTL)

You can see this chain with dig +trace:

dig +trace example.com

.        NS  a.root-servers.net.      ← starting from the root
.        NS  b.root-servers.net.
...

It queries from the root, down to the TLD, to the authoritative — exactly the sequence above. (DNS runs mostly over UDP port 53 — recall Article 6: short questions/answers, where re-asking on loss is faster than a TCP handshake.)

DNS record types

A domain can have many records of different types. The ones you'll meet most:

dig +short google.com A      # 142.250.198.206
dig +short google.com MX     # 10 smtp.google.com.
dig +short google.com NS     # ns1.google.com.
dig +short google.com TXT    # "google-site-verification=..."

   A      name → IPv4 address          e.g. example.com → 93.184.x.x
   AAAA   name → IPv6 address
   CNAME  alias, points one name to another   www → example.com
   MX     mail server for the domain          (with a priority)
   NS     name server managing the domain
   TXT    free-form text (ownership verification, SPF/DKIM for email)
   SOA    administrative info for the zone

A real CNAME example: www.github.com is an alias pointing to github.com, which then resolves to an IP:

dig +short www.github.com

github.com.          ← CNAME: www.github.com is an alias of github.com
20.205.243.166       ← then github.com resolves to this IP

CNAME is often used to point several names (www, app...) at one target, or to point at an external service (CDN, load balancer) without needing to know its IP.

TTL and cache: why DNS changes aren't instant

Each record carries a TTL (Time To Live) — the number of seconds it may be cached. In dig output:

dig +noall +answer google.com A

google.com.   152   IN   A   142.250.198.206
              └┬┘
              TTL = 152 seconds

The resolver (and your machine) keep the result for TTL seconds to avoid re-querying — DNS would be overwhelmed if every request walked from the root. Caching at multiple tiers (browser → OS → resolver) makes DNS fast.

A crucial practical consequence: when you change a DNS record (say, pointing a domain at a new server), the change isn't effective immediately — old caches still return the old IP until the TTL expires. This is why DevOps folks lower the TTL first before they plan to change DNS, so the cutover is quick. And it's why "I changed DNS but I still hit the old site" — the cache hasn't expired yet.

DNS in troubleshooting

A lot of "can't connect" incidents are really DNS:

• The name doesn't resolve to an IP → dig <name> returns empty (wrong name, or a broken DNS server).
• It resolves to an old/wrong IP → the cache hasn't hit TTL, or the record is misconfigured.
• It resolves but you still can't get in → the problem is in another layer (TCP, TLS, firewall) — DNS already did its job.

Tools: dig <name> (detailed), dig +short (terse), dig +trace (see the whole chain), and the /etc/hosts file to override DNS locally (recall Article 13 of the Linux series). Diagnosis should always start with "is DNS returning the right IP?" (Article 12).

Wrap-up

DNS translates domain names into IPs through a hierarchy (root → TLD → authoritative), with a recursive resolver doing the querying for you and then caching the result per TTL. A domain has many record types (A/AAAA for IPs, CNAME for aliases, MX for email, NS, TXT). dig is the main tool for inspection. Remember: DNS changes aren't instant because of TTL/cache — lower the TTL before a cutover.

DNS has handed you the server's IP. The next step in the journey is talking to it. Article 8 gets into the language of the web: HTTP and HTTPS.