$ dig www.example.com # RFC 1034 / 1035, 1987

DNS

The Domain Name System is the internet’s phone book: it turns a name like www.example.com into an IP address like 203.0.113.10. It is not one database but a distributed hierarchy: the root servers know who runs .com, the .com servers know who runs example.com, and that domain’s own servers hold its records. Answers are cached everywhere along the way for a time set by the record’s TTL.

Following one lookup

$ dig +trace www.example.com
Resolving a hostname from an empty cache
LAPTOP stub resolver RESOLVER 1.1.1.1 ROOT . TLD .com AUTHORITATIVE ns1.example.com OS cache: miss A? www.example.com A? www.example.com referral → .com A? www.example.com referral → ns1 A? www.example.com A 203.0.113.10 TTL 3600 A 203.0.113.10 cached for 3600 s
NO.STEPFROMTOTYPEINFO
101laptopresolverQUERYA? www.example.com (UDP 53, recursion desired)
202resolverrootQUERYA? www.example.com
302rootresolverREFERRALNS a.gtld-servers.net (+ glue IPs)
403resolvertldQUERYA? www.example.com
503tldresolverREFERRALNS ns1.example.com, ns2.example.com
604resolverauthQUERYA? www.example.com
704authresolverANSWERA 203.0.113.10, TTL 3600, AA flag set
805resolverlaptopANSWERA 203.0.113.10 (now cached)
  1. Your laptop needs the IP of www.example.com. It only knows one server: its recursive resolver.
  2. The OS cache is empty, so the stub resolver sends one query to the recursive resolver and waits.
  3. The resolver starts at a root server. Root doesn't know the answer, it returns a referral to the .com servers.
  4. The .com TLD server doesn't know either. It refers the resolver to the domain's authoritative name servers.
  5. The authoritative server owns the zone and returns the real answer: an A record with a TTL.
  6. The resolver answers the laptop and caches the record. For the next hour, the same question costs one hop.

Four roles take part:

  • Stub resolver: the tiny client inside your OS. It asks one question and expects a final answer.
  • Recursive resolver: your ISP’s, your cloud VPC’s, or a public one such as 1.1.1.1 or 8.8.8.8. It does the legwork and caches results.
  • Root and TLD servers: they never know the final answer, only who to ask next (a referral).
  • Authoritative server: the source of truth for a zone, run by your DNS provider (Route 53, Cloudflare, Cloud DNS).

Record types you will meet

Type Maps Example
A / AAAA name → IPv4 / IPv6 db.shop.com A 10.0.1.20
CNAME name → another name warehouse.shop.com CNAME abc123.snowflakecomputing.com
MX domain → mail servers shop.com MX 10 mail.shop.com
TXT name → text domain verification, SPF, DKIM
NS zone → its name servers shop.com NS ns1.provider.net
SRV service → host + port service discovery, e.g. Kafka or LDAP

DNS in data platforms

  • Service discovery. Kubernetes gives every Service a name such as kafka.data.svc.cluster.local. Kafka clients bootstrap through DNS and then connect to each broker’s advertised hostname.
  • Private DNS. Managed databases and warehouses expose private endpoints that resolve only inside your VPC. “Works on my laptop, fails in the job” is often a resolver difference.
  • Failover. Managed databases fail over by repointing a DNS name. A client that caches the old IP forever keeps talking to a dead primary.

Common mistakes

  • Ignoring TTL when migrating. Lower the TTL (say to 60 s) a day before you change a record, or clients keep the old IP for hours.
  • Clients that cache forever. The JVM’s DNS cache is configurable via networkaddress.cache.ttl; long-lived pools must re-resolve to notice a failover.
  • Assuming DNS is private. Classic DNS over UDP port 53 is plain text. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt it. DNSSEC signs records so they can’t be forged, but doesn’t hide them.
  • Blaming the network for ENOTFOUND. Check with dig against a specific resolver first; the record may simply not exist in that view.

Try it

dig +short www.example.com          # just the answer
dig +trace www.example.com          # walk root → TLD → authoritative yourself
dig @8.8.8.8 db.shop.com AAAA       # ask a specific resolver for a specific type
resolvectl query db.shop.com        # what the OS resolver (systemd) returns

Learning Resources

Books

Articles

Specifications

Videos

See also: UDP, HTTPS.

TCP/IP HTTP