DNS and Domain Resolution

beginner dns networking records resolution

DNS (Domain Name System) is like the phone book of the internet. We type google.com, and DNS figures out the IP address (like 142.250.80.46) so our browser knows where to connect.

Without DNS, we’d have to memorize IP addresses for every website. Nobody wants that.

The Resolution Flow

When we type a URL in the browser, here’s what happens behind the scenes:

DNS Resolution Flow
1 Browser cache → already visited this site? ✓ done
2 OS cache → checked /etc/hosts and system cache ✓ done
3 Recursive Resolver → ISP or configured DNS (8.8.8.8, 1.1.1.1) ✓ if cached
4 Root Server → "I don't know, but ask the .com TLD server"
5 TLD Server (.com) → "Ask the authoritative server for google.com"
6 Authoritative Server → "google.com is 142.250.80.46" 🎯
Result gets cached at each level so the next lookup is faster

Most lookups never reach step 4 because caching is aggressive. The resolver already knows the answer from previous queries.

DNS Record Types

These are the building blocks of DNS configuration.

RecordPurposeExample
AMaps domain to IPv4 addresspman47.cc → 144.24.126.230
AAAAMaps domain to IPv6 addresspman47.cc → 2001:db8::1
CNAMEAlias pointing to another domainwww.pman47.cc → pman47.cc
MXMail server for the domainpman47.cc → mail.pman47.cc (priority 10)
TXTArbitrary text (SPF, DKIM, verification)v=spf1 include:_spf.google.com ~all
NSWhich nameservers are authoritativepman47.cc → ns1.hostinger.com

A CNAME can’t coexist with other records on the same name. So we can’t have a CNAME at the root domain (pman47.cc) — only on subdomains (www.pman47.cc). Some providers offer “ALIAS” or “ANAME” records to work around this.

TTL — Time to Live

Every DNS record has a TTL (in seconds) that tells caches how long to keep the answer.

  • TTL 300 → cache for 5 minutes (good for records we might change)
  • TTL 86400 → cache for 24 hours (good for stable records)
  • Before a migration, lower the TTL to 60-300 so changes propagate fast

DNS Lookup Commands

dig and nslookup are our go-to tools for DNS debugging.

# dig — the gold standard
dig pman47.cc                    # query A record
dig pman47.cc AAAA               # query IPv6 record
dig pman47.cc MX                 # query mail records
dig pman47.cc +short             # just the IP, no extra info
dig @8.8.8.8 pman47.cc          # query using Google's DNS

# nslookup — simpler alternative
nslookup pman47.cc
nslookup -type=MX pman47.cc
# Trace the full resolution path
dig pman47.cc +trace

# Check all record types
dig pman47.cc ANY +short

Common DNS Gotchas

  • Propagation delay — DNS changes can take minutes to hours to spread worldwide because of caching. Lower the TTL before making changes.
  • CNAME at root — Most providers don’t allow it. Use an A record for the naked domain.
  • /etc/hosts — Local override file. The OS checks this before DNS. Useful for testing: 127.0.0.1 myapp.local.
  • DNS caching — If things look wrong after a change, flush the local cache: sudo systemd-resolve --flush-caches (Linux) or sudo dscacheutil -flushcache (macOS).

In simple language, DNS is just a giant distributed phone book. We give it a name, it gives us back a number. The whole system is designed to be fast (caching) and reliable (multiple levels of servers).