How DNS Works: A Step-by-Step Journey from Domain to IP

Why DNS Exists

IP addresses are how the internet actually routes traffic. When your browser connects to a server, it's connecting to something like 104.21.55.200 — not utilitykit.tools. DNS (Domain Name System) is the lookup service that translates human-readable domain names into the IP addresses machines use.

Before DNS, that translation was handled by a single text file called HOSTS.TXT, maintained by the Stanford Research Institute. Every machine on the internet downloaded updates periodically. By 1983, with hundreds of hosts on ARPANET and growth accelerating, that clearly wasn't going to scale. Paul Mockapetris designed DNS in RFC 1034 and RFC 1035 as a distributed, hierarchical, cacheable replacement. It's been the foundation of internet naming ever since.

The DNS Hierarchy

DNS is a tree structure. At the top is the root zone, represented as a single dot (.). Below that are top-level domains (TLDs) like .com, .net, .io, .tools. Below those are second-level domains like utilitykit in utilitykit.tools. Subdomains like www go further down.

Each level of the tree is managed by different organizations:

• Root zone: 13 sets of root nameservers (labeled a through m), operated by organizations like ICANN, Verisign, and NASA. Technically 13 IP addresses, but anycast routing means hundreds of physical servers answer on those addresses.
• TLD nameservers: Managed by TLD registries. Verisign runs .com and .net. Your country's registry runs its ccTLD.
• Authoritative nameservers: Run by you, your registrar, or your DNS provider (Cloudflare, Route 53, etc.). These hold the actual records for your domain.

The Resolution Chain, Step by Step

Type utilitykit.tools into your browser. Here's everything that happens before a TCP connection is made:

1. Local lookup. Before making any network request, the OS checks two things in order: first, the /etc/hosts file (or C:\Windows\System32\drivers\etc\hosts on Windows), which maps names to IPs statically and always takes priority over DNS. Second, the OS DNS cache. If either has a recent answer for utilitykit.tools, it's returned immediately. You can inspect the DNS cache with ipconfig /displaydns on Windows; on macOS, sudo dscacheutil -cachedump -entries Host.

2. Stub resolver → recursive resolver. If there's no cached answer, your OS sends the query to a recursive resolver — usually your ISP's DNS server or a public one you've configured like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare). The stub resolver in your OS just asks this one server and waits for an answer.

3. Recursive resolver → root nameserver. The recursive resolver checks its own cache. If it doesn't have an answer either, it asks a root nameserver: "Who handles .tools domains?" The root server responds with the IP addresses of the .tools TLD nameservers.

4. Recursive resolver → TLD nameserver. The resolver asks the .tools TLD nameserver: "Who's authoritative for utilitykit.tools?" The TLD nameserver responds with the nameserver hostnames (like ns1.example.com) for that specific domain.

5. Recursive resolver → authoritative nameserver. Finally, the resolver asks the authoritative nameserver: "What's the IP address for utilitykit.tools?" The authoritative server returns the actual A record: 104.21.55.200.

6. Answer travels back. The recursive resolver caches the answer and returns it to your stub resolver. Your OS caches it too. Your browser connects.

The whole chain typically completes in 20–100ms for uncached lookups, and in under 1ms when it's already cached.

Recursive vs Iterative Queries

The difference is who does the legwork. In a recursive query (what your computer makes to the recursive resolver), you're saying "figure this out for me and give me the final answer." The recursive resolver takes responsibility for following the chain.

In an iterative query (what the recursive resolver makes to root and TLD servers), the server just responds with the best referral it can: "I don't know, but try asking this other server." The resolver keeps following referrals until it gets a real answer.

Your computer always makes recursive queries. Root servers only handle iterative queries and refuse recursion to prevent being used as amplifiers in DDoS attacks.

DNS Record Types

The authoritative nameserver stores different record types for different purposes:

CNAME records can't coexist with other records at the apex of a domain (the bare @ record). That's why CDN providers like Cloudflare offer "CNAME flattening" or proprietary ALIAS/ANAME record types for root domains.

TXT records have expanded far beyond their original purpose and now carry SPF email authorization rules, DKIM public keys, domain ownership verification tokens for Google Search Console, and more.

TTL and Caching

Every DNS record has a TTL (time-to-live) value in seconds. A TTL of 300 means resolvers cache the answer for 5 minutes before asking again. 86400 means 24 hours.

Low TTLs mean changes propagate quickly but generate more DNS traffic. High TTLs mean fast lookups (more cache hits) but slower propagation. When migrating a site: lower the TTL to 300 several days before the cutover, make the change, verify, then raise it back to something sensible like 3600.

"DNS propagation" is really just waiting for caches around the internet to expire and fetch fresh records. There's no broadcast mechanism — caches just age out.

DNS over HTTPS (DoH)

Traditional DNS queries travel in plaintext over UDP port 53. Anyone on your network — your ISP, a coffee shop router — can see every hostname you look up. DNS over HTTPS fixes this by encrypting DNS queries inside regular HTTPS traffic, sending them to a DoH resolver like https://cloudflare-dns.com/dns-query.

Cloudflare's 1.1.1.1, Google's 8.8.8.8, and most major browsers support DoH. Firefox enables it by default in the US. The tradeoff: you're shifting trust from your ISP to the DoH provider. Instead of your ISP knowing your query history, Cloudflare or Google does.

DNS over TLS (DoT) is an alternative that uses encrypted TCP on port 853 rather than piggybacking on HTTPS port 443.

Debugging with dig and nslookup

dig is the standard tool for querying DNS from the command line:

# Basic A record lookup
dig utilitykit.tools

# Look up a specific record type
dig utilitykit.tools MX
dig utilitykit.tools TXT

# Query a specific nameserver directly (bypass your resolver)
dig @8.8.8.8 utilitykit.tools

# Trace the full resolution chain
dig +trace utilitykit.tools

# Short output (just the answer)
dig +short utilitykit.tools

nslookup is available on Windows and does the same job with a different interface:

nslookup utilitykit.tools
nslookup -type=MX utilitykit.tools

When you need to inspect the structure of DNS responses that come back as JSON — particularly from DoH APIs or DNS-over-JSON services — JSON Formatter makes them much easier to read. And if you're working with international domain names or percent-encoded hostnames, URL Encoder handles the encoding conversions.

When DNS Goes Down

DNS failure is one of the most disruptive outages possible. It affects everything — websites, email, APIs, internal services. The symptoms look like the internet is down, but the network is usually fine; only name resolution is broken.

Common failure modes: your authoritative nameserver is unreachable (fix: multi-provider DNS, at least two NS records at different providers), your TTL was too high when you needed to change records quickly (fix: lower TTL before planned changes), or your resolver is the problem (fix: configure two resolvers in /etc/resolv.conf).

dig +trace is invaluable here. It walks you through the full resolution chain and shows exactly which server broke it.

For a related look at what happens after DNS resolution completes, see How TLS and HTTPS Work and Understanding HTTP Headers.