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

flowchart TD
  Root["Root zone &nbsp;(.)<br/>13 root nameservers"]
  Com[".com<br/>(Verisign)"]
  Tools[".tools<br/>TLD registry"]
  Io[".io<br/>TLD registry"]
  Uk["utilitykit.tools<br/>(your authoritative NS)"]
  Www["www.utilitykit.tools"]
  Blog["blog.utilitykit.tools"]
  Root --> Com
  Root --> Tools
  Root --> Io
  Tools --> Uk
  Uk --> Www
  Uk --> Blog
  classDef root fill:#1f1f1f,stroke:#f5c842,color:#e4e4e4;
  classDef tld fill:#1f1f1f,stroke:#60a5fa,color:#e4e4e4;
  classDef sld fill:#1f1f1f,stroke:#4ade80,color:#e4e4e4;
  classDef sub fill:#1f1f1f,stroke:#a8a8a8,color:#e4e4e4;
  class Root root
  class Com,Tools,Io tld
  class Uk sld
  class Www,Blog sub

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

sequenceDiagram
  participant App as Browser / OS
  participant R as Recursive resolver<br/>(1.1.1.1)
  participant Root as Root NS
  participant TLD as .tools TLD NS
  participant Auth as Authoritative NS<br/>(your DNS provider)
  App->>R: Who is utilitykit.tools? (recursive)
  Note over R: Cache miss
  R->>Root: Who handles .tools? (iterative)
  Root-->>R: Refer to .tools TLD nameservers
  R->>TLD: Who is authoritative for utilitykit.tools?
  TLD-->>R: Refer to ns1.example-dns.com
  R->>Auth: A record for utilitykit.tools?
  Auth-->>R: 104.21.55.200 (TTL 300)
  R-->>App: 104.21.55.200
  Note over R: Cache for 300 s
  App->>App: TCP connect to 104.21.55.200

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

flowchart LR
  App[Browser] --> OS[(OS cache<br/>~secs–mins)]
  OS --> R[(Recursive resolver<br/>cache<br/>respects TTL)]
  R --> Auth[Authoritative NS<br/>"source of truth"]
  Auth -. record + TTL .-> R
  R -. expires after TTL .-> R
  classDef cache fill:#1f1f1f,stroke:#fb923c,color:#e4e4e4;
  classDef src fill:#1f1f1f,stroke:#4ade80,color:#e4e4e4;
  class OS,R cache
  class Auth src

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)

flowchart TB
  subgraph Plain["Classic DNS (UDP/53, plaintext)"]
    direction LR
    C1[Browser] -- "utilitykit.tools?" --> ISP1[(ISP / network<br/>can read hostnames)]
    ISP1 --> R1[Resolver]
  end
  subgraph DoH["DNS over HTTPS (TCP/443, encrypted)"]
    direction LR
    C2[Browser] -- "TLS-encrypted query" --> ISP2[(ISP / network<br/>sees only TLS bytes)]
    ISP2 --> CF[Cloudflare<br/>cloudflare-dns.com]
  end
  classDef bad fill:#1f1f1f,stroke:#f87171,color:#e4e4e4;
  classDef good fill:#1f1f1f,stroke:#4ade80,color:#e4e4e4;
  class Plain bad
  class DoH good

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.

FAQ

What's the difference between A and CNAME records?

An A record points a hostname directly to an IPv4 address (example.com → 104.21.55.200). A CNAME points one hostname to another hostname (www.example.com → example.com). CNAMEs add a lookup hop but make it easier to change targets — update the underlying A record once and all CNAMEs pointing to it follow.

Why can't I use CNAME on the root domain?

The DNS spec forbids CNAME at the apex (the bare example.com record) because it conflicts with required NS, MX, and SOA records. To work around this, providers offer "CNAME flattening" (Cloudflare) or proprietary ALIAS/ANAME records (DNSimple, Route 53) that resolve at the DNS level to the underlying A record. Use those when you need to point your apex at a service like a load balancer.

How long does DNS propagation actually take?

Whatever your TTL is, plus a small buffer for caches that disregard the TTL. If your TTL was 1 hour, expect changes to fully propagate in 1-2 hours. The "24-48 hour" rule of thumb assumes default TTLs of 86400. To make changes fast, lower TTL to 300 a few days before the change, then change records, then optionally raise TTL back.

Should I use 1.1.1.1 or 8.8.8.8?

Both are reliable public resolvers. Cloudflare's 1.1.1.1 has the better privacy story (no logging, audited by KPMG) and is generally faster in benchmarks. Google's 8.8.8.8 is more widely known and has been around longer. Either is dramatically faster than most ISP resolvers; pick one or use both for redundancy in /etc/resolv.conf.

What does DNS over HTTPS actually protect?

DoH encrypts your DNS queries from your local network observers (ISP, coffee shop, school proxy). It doesn't hide which sites you're visiting from the DoH provider itself (Cloudflare, Google, NextDNS). It also doesn't hide the destination IP from your ISP — they still see the TCP connection. DoH is privacy improvement, not privacy panacea.

Why are there always two or more nameservers for a domain?

Redundancy. If your single nameserver goes down, your domain becomes unreachable for everyone whose cache has expired. Best practice is two NS records at different providers (e.g., one at Cloudflare, one at Route 53) so a single provider outage doesn't take you offline. Most registrars require at least 2 NS records.

What's the difference between an A record and an AAAA record?

A is IPv4 (192.0.2.1), AAAA is IPv6 (2001:db8::1). Both can coexist for the same hostname; clients prefer AAAA when available and they have working IPv6 (Happy Eyeballs algorithm). Most modern hosting platforms set up both automatically. If your site only has A records and no AAAA, IPv6-only clients can't reach you — though they're still rare in 2026.

How do I check if my DNS records are correct?

Use dig +trace example.com to walk the full resolution chain from root to authoritative server. dig @8.8.8.8 example.com queries a specific resolver to bypass your local cache. For non-CLI users, dnschecker.org and whatsmydns.net show what records different global resolvers see — useful for confirming propagation across regions.