How the Domain Name System (DNS) Works

Every time you open a website, send an email or call an API, your device first has to answer a simple question: which IP address belongs to this name? The Domain Name System (DNS) is the global, distributed directory that answers it. It is one of the oldest pieces of internet infrastructure still in daily use, and because it usually works invisibly, many site owners only learn how it operates when something breaks. This guide walks through the full journey of a DNS query in plain language, explains why caching matters so much, and shows the commands you can use to see it all for yourself.

What DNS actually does

Computers route traffic using numeric addresses such as 93.184.215.14 (IPv4) or 2606:2800:21f:cb07:6820:80da:af6b:8b2c (IPv6). People prefer names. DNS maps between the two, but it is more than a lookup table. It is a hierarchical, delegated database: no single server knows every answer. Instead, responsibility is split into zones, and each zone is managed by whoever controls it.

This design has three practical consequences:

• Scalability: the root servers do not need to know about billions of hostnames, only where to find each top-level domain.
• Autonomy: once a domain is delegated to you, you decide what records it contains without asking anyone else.
• Resilience: every level is served by multiple servers, often spread across continents with anycast routing.

The individual entries inside a zone, such as A, AAAA, CNAME and MX, are covered in detail in our guide to understanding DNS records. Here we focus on how a resolver finds those records in the first place.

The DNS hierarchy: root, TLD and authoritative servers

Read a domain name from right to left and you are reading the DNS tree from the top down. The name www.example.com. actually ends with an invisible dot that represents the root.

The link between levels is called delegation. When you register a domain and set its name servers at your registrar, the registrar passes those NS records to the registry, which publishes them in the TLD zone. If the name servers live inside the domain itself (for example ns1.example.com), the registry also publishes glue records, which are the IP addresses of those servers, to avoid a chicken-and-egg problem.

Step by step: what happens when you type a URL

Suppose you visit www.example.com for the first time on a fresh network. The lookup proceeds roughly like this:

1. Local checks. The browser checks its own cache, then asks the operating system. The OS consults its cache and the hosts file.
2. Stub resolver to recursive resolver. If nothing is cached, the stub resolver built into your OS sends a query to the configured recursive resolver: usually your ISP, your router, or a public service such as 1.1.1.1, 8.8.8.8 or 9.9.9.9.
3. Recursive resolver asks a root server. The resolver ships with a list of root server addresses (the root hints). It asks one of them about www.example.com. The root does not know the answer but replies with a referral: here are the name servers for .com.
4. Recursive resolver asks the TLD servers. A .com server replies with another referral: the authoritative name servers for example.com, plus glue if needed.
5. Recursive resolver asks the authoritative server. This server holds the zone and returns the actual answer, for example an A record with an IPv4 address, and sets the AA (authoritative answer) flag.
6. Answer returned and cached. The resolver passes the answer back to your device and stores it, along with the referrals it collected, for the duration of each record’s TTL.

The resolver performs iterative queries towards the hierarchy while answering your device’s recursive query. Your laptop asks once and waits; the resolver does the walking. In practice, steps 3 and 4 are rarely needed because the resolver already has the root and .com referrals cached.

Watching it with dig +trace

The dig utility (part of BIND tools, available on Linux and macOS) can perform the walk itself and print each referral. Output below is shortened:

$ dig +trace www.example.com A

.                 518400  IN  NS  a.root-servers.net.
.                 518400  IN  NS  b.root-servers.net.
;; Received 239 bytes from 127.0.0.53#53

com.              172800  IN  NS  a.gtld-servers.net.
com.              172800  IN  NS  b.gtld-servers.net.
;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net)

example.com.      172800  IN  NS  a.iana-servers.net.
example.com.      172800  IN  NS  b.iana-servers.net.
;; Received 361 bytes from 192.5.6.30#53(a.gtld-servers.net)

www.example.com.  300     IN  A   93.184.215.14
;; Received 60 bytes from 199.43.135.53#53(a.iana-servers.net)

Each block is one hop: root, TLD, authoritative. The number after the name is the TTL in seconds.

Caching and TTL: why DNS is fast

If every lookup walked the full tree, the root and TLD servers would be overwhelmed and browsing would feel sluggish. Caching prevents that. Every record carries a Time To Live (TTL), set by the zone owner, telling resolvers how many seconds they may reuse the answer before asking again.

• Long TTLs (hours or a day) reduce query load and make your site more tolerant of brief authoritative outages, but changes take longer to reach everyone.
• Short TTLs (60 to 300 seconds) let you switch servers quickly, at the cost of more queries.
• Negative caching: a "this name does not exist" (NXDOMAIN) answer is also cached, for a period derived from the zone’s SOA record. Creating a record right after someone queried it can therefore seem not to work for a while.

A practical habit before a migration: lower the TTL of the records you plan to change a day or two in advance, make the switch, then raise the TTL again once traffic has moved.

What "DNS propagation" really means

Nothing is actively pushed around the internet when you edit a record. "Propagation" is simply the time it takes for cached copies to expire across thousands of resolvers. Two different timers are involved:

• Changes to records inside your zone are governed by those records’ TTLs.
• Changes to your name servers involve the delegation published in the TLD zone, whose NS TTL is set by the registry and is often 48 hours or more for some TLDs. Resolvers that cached the old delegation keep using it until it expires.

Keep the old DNS provider serving the same records during a name server switch, and the transition will be invisible to visitors.

Common DNS problems and how to spot them

A lame delegation happens when the TLD points to name servers that do not actually serve your zone, often after cancelling a hosting plan without updating NS records. You can quickly see which name servers a domain is delegated to, along with its registrar and expiry date, using the TLDix WHOIS lookup.

Recursive resolvers, privacy and security

Classic DNS travels over UDP port 53 in plain text, so anyone on the network path can see and potentially tamper with queries. Several improvements address this:

• DNS over TLS (DoT) and DNS over HTTPS (DoH) encrypt the connection between your device and the recursive resolver, protecting privacy on the first hop.
• QNAME minimisation makes resolvers send only the part of the name each server needs, so the root does not learn the full hostname you are looking up.
• DNSSEC adds cryptographic signatures so resolvers can verify that answers really came from the zone owner and were not altered. Encryption hides queries; DNSSEC proves authenticity. They solve different problems and work well together.

Keeping your domain’s DNS healthy

Most DNS outages are not exotic attacks. They are ordinary oversights: an expired domain, a forgotten DNS hosting account, or a name server change nobody documented. A simple routine helps:

1. Use at least two authoritative name servers, ideally on separate networks.
2. Document which provider hosts your zone and who has access.
3. Keep the domain’s registration and the DNS hosting account renewed and on auto-renew where possible.
4. Check delegation after any provider change with dig NS and dig +trace.
5. Monitor expiry dates centrally. In the TLDix domain panel you can track domains, SSL certificates and hosting renewals in one place and get reminded before anything lapses.

Once you understand the chain from root to authoritative server, most DNS mysteries become straightforward: find which link is returning the unexpected answer, check its TTL, and fix the data at the source.