DNS
Beginner 12 min read DNS

DNS Fundamentals

The internet's global telephone book

DNS maps human names (app.example.com) to IPs through a hierarchy of resolvers. Every cloud service touchpoint — LBs, databases, endpoints — is ultimately an A/AAAA/CNAME record.

DNSresolvernameserverA recordCNAMETLDauthoritative
Prerequisites: Cloud Networking
Before we start

What you will learn

  • Explain the resolver → root → TLD → authoritative chain
  • Distinguish A, AAAA, CNAME, NS, SOA records
  • Debug resolution with dig/nslookup
In 60 seconds

A recursive resolver asks the root and TLD servers for the address of the authoritative nameserver, then asks it for the record. Caches along the way make repeat lookups fast — and TTL controls how fast changes propagate.

Introduction

What is this?

DNS records: A (IPv4), AAAA (IPv6), CNAME (alias), NS (nameservers), SOA, MX, TXT, SRV. Resolution: stub → recursive resolver → root (.), TLD (com.) → authoritative nameserver that holds hostnames. Record lifecycle: DNS queries cached per TTL; changes take effect only after caches expire. Cloud offerings: Route 53 (public + private hosted zones), Azure DNS, Cloud DNS.

Motivation

Why do you need it?

  • Changing a service endpoint (new LB IP) is a DNS edit — the front door to any migration.
  • DNS is the first place 'where is this app?' is answered; slow/failing DNS stalls everything.
  • Health checks + failover policies in managed DNS give simple multi-region routing.
  • CNAME/alias records let you repoint a hostname to a cloud resource cleanly.
Think about it

Mental model

Imagine

Asking a phone operator to look up a business in a city directory

Think of

DNS resolution

Your call goes to the operator (resolver); they check the directory hierarchy (root/TLD), find the business's listed number (authoritative record), and give it to you after verifying (answer).

Mechanics

How it works

  • The client asks a recursive resolver (usually your ISP or 8.8.8.8) for app.example.com.
  • Resolver walks root → .com TLD → example.com's authoritative nameservers (NS records).
  • Authoritative server answers with the current A/AAAA (or CNAME→the real host).
  • The answer is cached at the resolver for the record's TTL (seconds to days).
  • Mismatches/expirations cause lookup failures — the eternal 'it works locally but not here' class.

Resolution path.

Client
Resolver
Root + TLD
Authoritative
Answer
Hands-on

Examples

Inspect DNS with dig

Inspect DNS with dig
dig app.example.com A +short
dig +trace example.com    # walk root -> TLD -> auth
dig example.com NS        # who is authoritative
dig @8.8.8.8 example.com  # force a specific resolver

dig shows the exact chain and TTL; +trace walks the hierarchy to prove where an answer comes from.

Real world

In production

  • Route 53 public hosted zone carries the app's A record aliased to an ALB.
  • Azure custom domain DNS validates with TXT + CNAME before the CDN serves it.
  • Private hosted zones resolve internal service names to private LBs within a VNet.
Guidelines

Best practices

  • Keep TTL short (30-60s) on records you may change (load balancers, failover).
  • Use alias/CNAME to resources so IP changes don't require a DNS edit.
  • Monitor resolution with synthetic queries from the regions that matter.
  • Never point traffic to an IP that can change (EIPs are the exception, not the norm).
Watch out

Common mistakes

  • Long TTL on a record you'll flip at deploy → outage while caching matches it out.
  • CNAME at the zone apex (invalid per RFC for many setups) instead of alias.
  • Forgetting NS/RFC glue when moving hosts — delegation silently breaks.
  • Relying on cached DNS instead of updating the authoritative zone to fix an outage.
Root cause analysis

Common issues

Error
Clients in some networks see an old IP
Root cause

A cached TTL + those networks' resolvers

Fix

Lower TTL, wait out old caches, and confirm the new record at the authoritative server.

Error
Zone won't update in Route 53
Root cause

Change batch syntax or insufficient IAM

Fix

Validate the change-batch JSON and IAM route53:ChangeResourceRecordSets permission.

When things break

Debugging tips

  • dig +trace pinpoints which layer misbehaves (root/TLD/auth/resolver).
  • Different answers by resolver = caching TTL or split-horizon view — compare with @target.
  • 'Name not found' when the zone exists: check NS delegation and SOA.
  • Record updated but clients stuck: wait TTL + retry; lower TTL next time.
Interviews

Interview checkpoint

Practice

Hands-on lab

Traverse and Debug the DNS Chain
20 min · beginner
In progress
Objectives
  • Trace resolution with dig/nslookup
  • Inspect NS/SOA/TTL of a real domain
  • Diagnose slow propagation

Traverse and Debug the DNS Chain

20 min · beginner

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/1
1

Which record type maps a hostname directly to an IPv4 address?

Go deeper

Official documentation

AWS — Route 53
docs
Azure — DNS service
docs
GCP — Cloud DNS
docs