DNS Lookup Explained: How Domain Name Resolution Actually Works

Every time you type a URL into your browser, something has to turn that domain name into an IP address. That something is DNS, the Domain Name System. It maps names like zerokit.dev to the IP addresses computers actually use to talk to each other. Once you understand how DNS works, you'll be noticeably faster at debugging connectivity problems, setting up domains, and deploying services. I've lost count of how many "the site is down" incidents turned out to be DNS.

The Journey of a DNS Query

When you visit example.com, this whole sequence plays out in roughly 50 milliseconds:

1. The browser checks its own cache first. If it resolved this domain recently, it reuses the cached IP and skips everything else.
2. On a cache miss, the OS stub resolver checks its cache. On macOS you can flush it with sudo dscacheutil -flushcache; on Linux, systemd-resolved manages it.
3. If the OS cache misses too, the query goes to a recursive DNS resolver. That's usually your ISP's resolver or a public one like Cloudflare (1.1.1.1) or Google (8.8.8.8). This is the workhorse of the process.
4. The recursive resolver asks one of the 13 root nameserver clusters: "Who handles .com?" The root hands back the addresses of the .com TLD nameservers.
5. The resolver then asks the .com TLD server: "Who handles example.com?" It responds with the authoritative nameservers for the domain, something like ns1.example-dns.com.
6. Finally, the resolver asks the authoritative server for the A record of example.com. It gets back the IP address: 93.184.216.34.
7. The recursive resolver caches that answer for the duration of the record's TTL, returns it to your browser, and your browser opens a TCP connection to that IP.

All of that only happens on a cache miss. After the first lookup, subsequent requests for the same domain resolve in under a millisecond.

DNS Record Types You Need to Know

A Record

An A record maps a domain to an IPv4 address. It's the most basic and most common record type: example.com. 3600 IN A 93.184.216.34

AAAA Record

Same idea as the A record, but for IPv6: example.com. 3600 IN AAAA 2606:2800:220:1:248:1893:25c8:1946

CNAME Record

A CNAME creates an alias from one domain to another. You'll often see www.example.com with a CNAME pointing to example.com. The resolver follows the chain until it finds an A or AAAA record. One gotcha: you cannot set a CNAME on the zone apex (the bare domain) in standard DNS. Some providers offer "ALIAS" or "ANAME" records to work around this.

MX Record

MX records tell the world which mail servers handle email for your domain. They include priority values; lower numbers win. Example: example.com. 3600 IN MX 10 mail.example.com.

TXT Record

TXT records hold arbitrary text. You'll run into them constantly for domain verification (Google Search Console, email providers), SPF (which servers can send email for your domain), DKIM signatures, and DMARC policies. If you've ever added a TXT record to prove you own a domain, that's this one.

NS Record

NS records declare the authoritative nameservers for a domain. When you change nameservers at your registrar, you're really updating the NS records at the parent zone (the .com TLD, for example).

SRV Record

SRV records specify the host and port for specific services like SIP, XMPP, or custom service discovery. Format: _service._proto.name. TTL IN SRV priority weight port target.

TTL: Time To Live

Every DNS record has a TTL value in seconds. It tells resolvers how long they're allowed to cache the answer. A TTL of 3600 means "cache this for one hour." Shorter TTLs mean changes show up faster but generate more queries. Longer TTLs reduce load but slow down changes.

I always do this before a server migration: lower the TTL on the relevant records to 300 seconds (5 minutes) at least 24 hours ahead of time. That way, the old high-TTL records expire from caches before you swap the IP. Once the migration is stable, bump the TTL back to 3600 or higher.

DNS Propagation: Why Changes Are Not Instant

When you update a DNS record, the authoritative nameserver reflects the change immediately. But recursive resolvers around the world still have the old record cached. Until each resolver's cache expires, users going through those resolvers see the old IP. That's what people mean by "DNS propagation."

It's not a wave moving across the globe. Different resolvers cached the record at different times, so their caches expire independently. In practice, propagation finishes within one TTL period. But edge cases exist: resolvers that don't honor TTL strictly, users with stale browser caches. In my experience, the 24-48 hour worst case is rare, but it does happen.

Troubleshooting DNS with dig and nslookup

dig is the go-to tool for DNS debugging on Unix-like systems:

# Query the A record for example.com
dig example.com A

# Query a specific nameserver
dig @8.8.8.8 example.com A

# Query MX records
dig example.com MX

# Trace the full resolution path
dig +trace example.com

On Windows, nslookup does the same job:

nslookup example.com
nslookup -type=MX example.com

If you don't have a terminal handy or want to check resolution from a different geographic location, an online DNS lookup tool works fine.

DNS Security: DNSSEC and DoH

Standard DNS queries travel in plaintext over UDP. Anyone on the network path can see what domains you're resolving and could forge responses (DNS spoofing). Two technologies fix this.

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records. Resolvers can then verify that the response actually came from the legitimate authoritative server and hasn't been tampered with. DNS over HTTPS (DoH) and DNS over TLS (DoT) go further by encrypting the query itself, preventing eavesdropping. Cloudflare's 1.1.1.1 and Google's 8.8.8.8 both support DoH and DoT, and most modern browsers use DoH by default.

You can verify your domain's SSL configuration with the SSL certificate checker, and check WHOIS registration details with the WHOIS lookup tool.