What is DNS and how does it work?

DNS (the Domain Name System) is the internet's naming system. It translates human-friendly names such as example.com into the numeric IP addresses, such as 192.0.2.10 or 2001:db8::10, that computers use to find each other. When you visit a website, send an email, or open an app, your device first asks DNS where the service lives, and only then connects to it. It works as a huge, distributed database: no single server holds every answer, so a lookup is passed between several servers, each responsible for one part of the name, until the right one replies.

Almost everything you do online starts with a DNS lookup, yet most people never see it happen. In this article you'll learn why DNS exists, the main parts of the system, exactly what happens during a lookup, what DNS records are, how caching keeps it fast, where it can go wrong, and how to run your own lookups from the command line so you can see it all working.

Why DNS Exists

Computers on the internet address each other by IP address. An IPv4 address looks like 203.0.113.25, and an IPv6 address looks like 2001:db8:4f2a::25. These are easy for machines but hard for people to remember, and they change whenever a site moves to a new host or cloud region.

In the early days of the ARPANET, every computer kept a single text file called HOSTS.TXT that mapped names to addresses. A central organisation maintained the master copy and everyone downloaded it regularly. That worked for a few hundred machines, but it couldn't scale: the file grew too large, updates were slow, and name clashes were common.

DNS was designed in the 1980s (the core specifications are RFC 1034 and RFC 1035) to replace that file with something that could grow with the internet. Its key ideas are:

• Hierarchy: Names are split into labels separated by dots, and each level of the tree is managed separately.
• Delegation: Whoever controls a name can hand responsibility for the names beneath it to someone else.
• Distribution: Answers are held by thousands of independent servers rather than in one place.
• Caching: Answers are remembered for a set time, so the same question doesn't have to travel across the world every time.

Your computer still has a small hosts file (/etc/hosts on Linux and macOS, C:\Windows\System32\drivers\etc\hosts on Windows), and it's usually checked before DNS. It's a handy tool for testing, but DNS does the real work.

The Main Parts of DNS

A DNS lookup involves several kinds of servers. It helps to know who does what before following a query through the system.

Component	What it does	Who typically runs it
Stub resolver	The small DNS client built into your operating system. It sends questions and receives answers.	Your OS (Windows, macOS, Linux, Android, iOS)
Recursive resolver	Does the hard work of finding an answer on your behalf and caches the result.	Your ISP, your company, or a public service such as 1.1.1.1, 8.8.8.8 or 9.9.9.9
Root name servers	The starting point. They know which servers handle each top-level domain.	Twelve independent organisations, coordinated by IANA
TLD name servers	Know which servers are responsible for each domain under a top-level domain such as .com or .uk.	The registry for that TLD
Authoritative name servers	Hold the actual records for a domain and give the final answer.	Your DNS provider, or you if you run your own

The first two are on the "asking" side. The last three are on the "answering" side, and together they form the hierarchy that every name belongs to.

How a DNS Lookup Works, Step by Step

Imagine you type www.example.com into your browser and nothing is cached anywhere yet. Here's what happens.

1. Your browser checks its own cache: Browsers keep a short-lived cache of recent lookups. If the answer isn't there, the browser asks the operating system.
2. The operating system checks its cache and hosts file: If neither has the answer, the OS stub resolver sends a query to the recursive resolver configured on your device, usually handed out by your router or network.
3. The recursive resolver asks a root server: The resolver doesn't know where www.example.com is, so it starts at the top. It asks one of the root name servers, which replies with a referral: "I don't know, but here are the servers for .com."
4. The resolver asks a .com TLD server: The .com server replies with another referral: "Here are the authoritative name servers for example.com."
5. The resolver asks the authoritative server: The example.com name server holds the actual record and replies with the IP address for www.example.com.
6. The resolver caches and returns the answer: The recursive resolver stores the answer for the length of time set by its TTL (time to live) and sends it back to your device.
7. Your browser connects: With the IP address in hand, your browser opens a connection to the web server and requests the page.

This whole process usually takes somewhere between a few milliseconds (when the answer is cached) and a couple of hundred milliseconds (when the resolver has to walk the full chain). In practice, the resolver almost always has the root and .com information cached already, so most lookups skip straight to step 5 or return immediately from cache.

Seeing It With dig

You can watch this chain yourself with dig, which is installed on macOS and most Linux systems (on Debian and Ubuntu it's in the dnsutils or bind9-dnsutils package). The +trace option makes dig follow the referrals itself, starting at the root:

dig +trace www.example.com

The output is long, but trimmed down it looks like this:

.                       518400  IN  NS  a.root-servers.net.
.                       518400  IN  NS  b.root-servers.net.
;; Received 239 bytes from 192.0.2.53#53(192.0.2.53) in 12 ms

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) in 24 ms

example.com.            172800  IN  NS  ns1.example.net.
example.com.            172800  IN  NS  ns2.example.net.
;; Received 286 bytes from 192.5.6.30#53(a.gtld-servers.net) in 31 ms

www.example.com.        300     IN  A   203.0.113.10
;; Received 60 bytes from 198.51.100.53#53(ns1.example.net) in 18 ms

Each block is one step down the tree: the root tells you about .com, .com tells you about example.com, and the authoritative server finally gives you the A record.

Domain Names and the DNS Tree

DNS names are read from right to left. In www.example.com.:

• The final, usually invisible dot is the root.
• com is the top-level domain (TLD).
• example is the second-level domain, the part you register.
• www is a subdomain or host name chosen by the domain's owner.

Each dot-separated part is called a label. A label can be up to 63 characters long, and a full name can be up to 253 characters in its usual written form. Names are case-insensitive, so Example.COM and example.com are the same.

The owner of each level controls what exists directly beneath it. The root delegates com to its registry, the com registry delegates example.com to whoever registered it, and that owner can create www, mail, api or anything else without asking anyone.

DNS Records: What DNS Actually Stores

The answers DNS gives are called resource records. Each record has a name, a type, a TTL, a class (almost always IN for internet) and some data. A handful of types cover most everyday needs:

Type	Purpose	Example data
A	Maps a name to an IPv4 address	203.0.113.10
AAAA	Maps a name to an IPv6 address	2001:db8::10
CNAME	Makes one name an alias of another	shop.example.net.
MX	Says which servers accept email for the domain	10 mail.example.com.
TXT	Holds free-form text, often used for verification and email security	"v=spf1 -all"
NS	Lists the authoritative name servers for a zone	ns1.example.net.
SOA	Holds administrative details for the zone	Serial number, timers, contact

Here's how a small set of records for a domain might look in the standard text format:

example.com.      3600  IN  A      203.0.113.10
example.com.      3600  IN  AAAA   2001:db8::10
www.example.com.  3600  IN  CNAME  example.com.
example.com.      3600  IN  MX     10 mail.example.com.
mail.example.com. 3600  IN  A      203.0.113.20
example.com.      3600  IN  TXT    "v=spf1 mx -all"

You don't need to memorise every type. The important point is that DNS isn't just for websites. It also tells mail servers where to deliver email, lets services prove domain ownership, and helps other systems discover where things are.

Caching and TTL

If every lookup had to visit the root, the TLD and the authoritative server, the internet would be slow and those servers would be overwhelmed. Caching is what makes DNS fast.

Every record carries a TTL in seconds. When a recursive resolver fetches a record, it keeps a copy for that long. Anyone else using the same resolver during that window gets the cached answer instantly. Your operating system and browser cache answers too, usually for shorter periods.

You can see the TTL counting down by asking the same resolver twice:

dig @1.1.1.1 www.example.com A +noall +answer

www.example.com.        300     IN      A       203.0.113.10

Run it again a minute later and the TTL will have dropped, for example to 241, because you're now seeing the resolver's cached copy.

The trade-off is that changes don't appear everywhere instantly. If you change a record with a one-hour TTL, some users may keep seeing the old value for up to an hour. That delay is what people usually mean when they talk about "DNS propagation".

UDP, TCP and Encrypted DNS

Traditional DNS uses port 53. Most queries are sent over UDP because it's quick: one small packet out, one back. When an answer is too large for a UDP response, or when servers copy whole zones between themselves, DNS switches to TCP on the same port. Modern DNS uses EDNS(0), an extension that allows larger UDP responses, which is what the udp: 1232 or udp: 4096 value in dig output refers to.

Plain DNS on port 53 is unencrypted, so anyone on the network path can see which names you look up and, in some cases, tamper with answers. Two newer protocols address the privacy problem by encrypting the connection between your device and the resolver:

• DNS over TLS (DoT), which runs on port 853.
• DNS over HTTPS (DoH), which sends DNS queries inside ordinary HTTPS traffic on port 443.

Separately, DNSSEC adds digital signatures to records so resolvers can check that answers are genuine. Encryption protects privacy in transit, while DNSSEC protects the integrity of the data itself. They solve different problems and work well together.

Querying DNS Yourself

You don't need special access to look up DNS records. These tools come with most systems.

dig (macOS and Linux)

# Look up the IPv4 address
dig example.com A +short

# Look up mail servers
dig example.com MX +short

# Ask a specific resolver
dig @9.9.9.9 example.com AAAA +short

Sample output:

203.0.113.10
10 mail.example.com.
2001:db8::10

nslookup (Windows, macOS and Linux)

nslookup example.com

Server:         192.0.2.53
Address:        192.0.2.53#53

Non-authoritative answer:
Name:   example.com
Address: 203.0.113.10

"Non-authoritative" simply means the answer came from a recursive resolver's cache rather than straight from the domain's own name servers.

PowerShell (Windows)

Resolve-DnsName -Name example.com -Type A
Resolve-DnsName -Name example.com -Type MX -Server 1.1.1.1

From Code

Most programming languages use the operating system's resolver by default. In Node.js, the dns module lets you query records directly:

const dns = require("node:dns").promises;

async function main() {
  const addresses = await dns.resolve4("example.com", { ttl: true });
  console.log(addresses);

  const mx = await dns.resolveMx("example.com");
  console.log(mx);
}

main().catch(console.error);

Running it prints something like:

[ { address: '203.0.113.10', ttl: 287 } ]
[ { exchange: 'mail.example.com', priority: 10 } ]

What Happens When DNS Goes Wrong

Because so much depends on it, DNS problems often look like "the internet is down" even when the network is fine. The most common symptoms are:

• NXDOMAIN: The name doesn't exist. This happens with typos, expired domains, or records that were deleted.
• SERVFAIL: The resolver couldn't get a valid answer, often because the authoritative servers are unreachable or DNSSEC validation failed.
• Timeouts: The resolver itself isn't responding, which points to a local network or resolver problem.
• Stale answers: An old IP address is still being returned because of caching after a change.

A quick way to tell whether the problem is your resolver or the domain itself is to ask a different resolver:

dig example.com A +short
dig @1.1.1.1 example.com A +short

If the second command works and the first doesn't, your local resolver is the likely culprit. If both fail, look at the domain's own DNS setup.

DNS outages also have a long history of taking down large services, because a single bad change to a widely used record or provider can affect millions of users at once. That's why careful TTL planning, redundant name servers and change reviews matter for anything important.

Who Controls DNS?

No single company runs DNS. Responsibility is shared:

• IANA (operated by PTI, an affiliate of ICANN) manages the root zone's contents, deciding which TLDs exist and which servers handle them.
• Root server operators, twelve organisations including Verisign, RIPE NCC, NASA and ICANN, run the root name servers.
• Registries such as Verisign for .com or Nominet for .uk run the servers for each TLD.
• Registrars sell domain names to the public and pass your chosen name servers to the registry.
• DNS hosting providers run the authoritative servers that hold your records.
• Resolver operators, such as ISPs and public DNS services, answer lookups for end users.

This split is deliberate. It keeps DNS resilient, because a failure in one place rarely affects the whole system, and it lets millions of domain owners manage their own names independently.

---

FAQ: DNS

---

Conclusion

DNS is the system that turns names into addresses, and it does so with a simple but powerful design: a hierarchy of names, delegation of responsibility at each level, and caching to keep everything fast. A lookup moves from your device to a recursive resolver, then down through the root, the TLD and finally the authoritative server that holds the record you need.

Once you understand those pieces, everyday issues such as slow changes, "site can't be reached" errors and email delivery problems become much easier to reason about. Try dig +trace on a domain you own, look at its records, and watch the TTLs count down. Seeing DNS work with your own eyes is the quickest way to make sense of it.