What Is DNS and How Does It Work?

IPAddress-Lookup.com · June 28, 2025

Every time you type a website name into your browser, an invisible system springs into action to figure out where that site actually lives. That system is the Domain Name System, or DNS, and it is one of the most important pieces of infrastructure on the internet. Without it, you would have to memorize long strings of numbers for every website you visit instead of friendly names like example.com. In this guide we will explain exactly what DNS is, trace a real lookup from start to finish, break down every major record type, and show you how to inspect and troubleshoot DNS yourself.

What is DNS?

DNS is the internet's phonebook. Computers do not communicate using human-readable names; they communicate using numerical addresses. When you want to reach a friend by phone, you do not dial their name, you dial their number, but you probably remember the name and let your contacts list translate it into digits. DNS does the same thing for the internet: it translates a domain name that people can remember, such as www.example.com, into the numerical what is an IP address that machines actually use to route traffic, such as 93.184.216.34 for IPv4 or a longer hexadecimal string for IPv6.

This translation matters because IP addresses change. A website might move to a new server, switch hosting providers, or spread its content across dozens of data centers around the world. Names give us a stable, memorable label that stays the same even when the underlying address moves. DNS is the layer that keeps that promise, resolving names to addresses billions of times per second across the globe. It is also a distributed system, meaning no single computer holds the whole phonebook. Instead, responsibility is spread across a vast hierarchy of servers, which is exactly what makes DNS fast, resilient, and able to scale to the entire planet.

The actors involved in a DNS lookup

Before we trace a query, it helps to meet the players. Each has a specific job, and a single lookup can touch all of them:

• Stub resolver — the small piece of software built into your operating system. When an application needs an address, the stub resolver forwards the request onward. It does very little thinking of its own.
• Recursive resolver — the workhorse, usually run by your internet service provider or a public provider such as a well-known 8.8.8.8 or 1.1.1.1 service. It takes your question and does whatever legwork is necessary to find the final answer, then hands it back to you.
• Root name servers — the top of the hierarchy. They do not know the address of any website, but they know where to find the servers responsible for each top-level domain.
• TLD name servers — responsible for a top-level domain like .com, .org, or .net. They know which authoritative servers handle each domain registered under them.
• Authoritative name servers — the final source of truth. These servers hold the actual records for a specific domain and give the definitive answer.

Tracing a real query: resolving www.example.com

Let us follow a single request step by step. Imagine you type www.example.com into your browser and press Enter. Here is what happens behind the scenes, assuming nothing is cached yet:

1. The browser asks the stub resolver. Your operating system's stub resolver receives the request for www.example.com. It first checks its own local cache. If it has recently looked up this name, it returns the answer immediately and the journey ends here.
2. The stub resolver contacts the recursive resolver. With no cached answer, the stub resolver forwards the query to your configured recursive resolver.
3. The recursive resolver queries a root server. The recursive resolver does not yet know where .com lives, so it asks one of the root servers. The root server does not know www.example.com, but it replies with a referral: "I do not have that answer, but here are the servers responsible for .com."
4. The recursive resolver queries the .com TLD server. Following that referral, the resolver asks a .com TLD server about www.example.com. The TLD server replies with another referral: "I do not know the address, but here are the authoritative name servers for example.com."
5. The recursive resolver queries the authoritative server. Finally, the resolver asks the authoritative name server for example.com. This server holds the real records and answers definitively: "www.example.com is at 93.184.216.34."
6. The answer travels back to you. The recursive resolver caches this answer, hands it to your stub resolver, and your browser opens a connection to that IP address. The whole process typically finishes in tens of milliseconds.

Recursive versus iterative queries

The walkthrough above illustrates two different querying styles, and understanding the distinction clears up a lot of confusion. When your device asks the recursive resolver a question, it expects a complete final answer. That is a recursive query: the resolver takes on the responsibility of doing whatever it takes to return a full result. Your device sits back and waits.

The conversations the recursive resolver has with the root, TLD, and authoritative servers are iterative queries. Each of those servers does not chase the answer on your behalf. Instead, they respond with the best information they have, which is usually a referral pointing one step closer to the destination. The recursive resolver then repeats the process, iterating down the hierarchy until it reaches an authoritative answer. In short: your device asks recursively, and the resolver works iteratively.

Caching and TTL at every layer

If every lookup had to travel all the way to an authoritative server, the internet would be painfully slow and the root servers would collapse under the load. Caching prevents that. At nearly every layer, answers are stored temporarily so they can be reused. Your browser caches, your operating system caches, and the recursive resolver caches heavily.

How long a record may be cached is controlled by its TTL, or time to live, measured in seconds and set by the domain owner. A record with a TTL of 3600 may be cached for one hour before a resolver must fetch a fresh copy. Short TTLs let you change records quickly, which is handy during a server migration, but they increase query volume. Long TTLs improve performance and reduce load but mean changes take longer to propagate across the world. This is why administrators often lower a record's TTL a day before a planned change and raise it again afterward.

The DNS hierarchy and the root servers

DNS is organized as an inverted tree. At the very top sits the root, written as a single dot that is usually invisible. Below the root are the top-level domains such as .com, .org, and country codes like .uk or .de. Below each TLD are the second-level domains that individuals and organizations register, like example.com. Below those sit subdomains such as www or mail. Reading a domain name from right to left walks you down the hierarchy from the general to the specific.

The root is served by a system famously described as the "13 root servers." In reality these are 13 named clusters, labeled A through M, each operated by a different organization. Behind each of those 13 addresses stands hundreds of physical servers distributed worldwide using a technique called anycast, which routes your request to the nearest available instance. That is how a handful of named entry points can reliably answer the entire planet's queries with low latency and high resilience against outages and attacks.

DNS record types explained

A domain's DNS zone is a collection of records, and each record type serves a distinct purpose. Understanding them is essential for anyone who runs a website or manages email. The table below summarizes the most important types with an example of each.

A and AAAA records

These are the workhorses that connect names to addresses. An A record points to an IPv4 address, while an AAAA record points to an IPv6 address. A domain can have both so that clients on either protocol can reach it. When your browser asks "where is example.com," it is usually one of these two records that provides the final answer.

CNAME records

A CNAME creates an alias, forwarding one name to another canonical name. It is commonly used to point www at the bare domain, or to point a custom subdomain at a hosting provider's address. A key rule is that a CNAME cannot coexist with other records at the same name, which is why the root of a domain usually uses A or AAAA records instead of a CNAME.

MX and email records

MX records tell the world which servers accept mail for your domain, with a priority number determining the order in which they are tried. Lower numbers are preferred, so a server with priority 10 is tried before one with priority 20. But MX records are only part of email's DNS story.

TXT records: SPF, DKIM, and DMARC

TXT records store free-form text, and the email world relies on them heavily for three interlocking authentication mechanisms. SPF lists the servers permitted to send mail on behalf of your domain, helping receivers reject forgeries. DKIM publishes a cryptographic public key so receivers can verify that a message was signed by your domain and not altered in transit. DMARC ties the two together, telling receivers what to do with messages that fail SPF or DKIM checks and where to send reports. Together they form the backbone of modern email deliverability.

NS and SOA records

NS records delegate authority, naming the servers responsible for a zone. The SOA record sits at the top of every zone and carries administrative details such as the primary name server, the responsible contact, a serial number that changes when the zone is edited, and timers that govern how secondary servers refresh their copies of the zone.

CAA and PTR records

A CAA record restricts which certificate authorities are allowed to issue certificates for your domain, adding a layer of protection against unauthorized certificates. If you want to understand how those certificates secure your traffic, see our guide to SSL certificates explained. A PTR record handles reverse DNS, mapping an IP address back to a hostname, which is frequently checked by mail servers to gauge a sender's legitimacy.

DNS and email deliverability

DNS is arguably as important to email as it is to the web. When a mail server wants to deliver a message to your domain, it looks up your MX records to find the right destination. When a receiving server wants to decide whether an incoming message is trustworthy, it checks your SPF, DKIM, and DMARC records, and often verifies the sending server's PTR record too. If any of these are missing or misconfigured, legitimate mail may land in spam folders or be rejected outright. Getting your DNS email records correct is one of the highest-impact things you can do to keep your messages flowing to the inbox rather than disappearing into a junk folder.

DNS security

Because DNS is so foundational, it has become a target, and several technologies exist to harden it:

• DNSSEC adds cryptographic signatures to DNS records so that resolvers can verify an answer genuinely came from the authoritative source and was not tampered with. It protects the integrity of the data but does not encrypt it.
• DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the conversation between your device and the recursive resolver. Traditionally DNS queries traveled in plain text, allowing anyone on the network path to see and even alter them. DoH and DoT close that gap by wrapping queries in encryption.
• Cache poisoning is a classic attack in which a malicious actor tricks a resolver into caching a false answer, redirecting victims to a fraudulent server. DNSSEC and modern resolver protections such as randomized source ports make this attack far harder to pull off.

Common DNS problems and troubleshooting

When a website will not load, DNS is often the culprit. Some of the most frequent issues include:

• Propagation delays. After you change a record, old cached values may persist until their TTL expires. This is why a change can appear live for you but not yet for others.
• Typos and missing records. A misspelled hostname or a forgotten A record leads to failures that are easy to overlook.
• Mismatched name servers. If your registrar points the domain at the wrong name servers, none of your carefully crafted records will ever be consulted.
• Conflicting CNAMEs. Placing a CNAME alongside other records at the same name breaks resolution.
• Resolver caching. Sometimes the problem is a stale entry in your own device or router, which flushing the cache resolves.

How to inspect DNS records yourself

You do not need to be a network engineer to look up DNS records. Command-line tools such as dig and nslookup, available on most systems, let you query any record type directly. For example, asking for the A record of a domain returns its IPv4 address, while asking for MX records reveals its mail servers. If the command line is not your preference, an online DNS Lookup tool lets you query any domain's records from your browser with no software to install, making it easy to confirm that a recent change has propagated or to diagnose a misconfiguration.

Getting into the habit of checking DNS records demystifies the whole system. Once you can see the A, MX, and TXT records for your own domain, the abstract phonebook becomes a concrete, understandable set of entries that you control. From there, diagnosing a slow site, a bounced email, or a certificate warning becomes a matter of reading the records rather than guessing.

Frequently asked questions

What does DNS stand for?

DNS stands for Domain Name System. It is the distributed system that translates human-readable domain names into the numerical IP addresses computers use to communicate with one another.

Why is DNS called the phonebook of the internet?

Just as a phonebook lets you look up a person's phone number from their name, DNS lets your computer look up a website's IP address from its domain name. You remember the easy name, and DNS handles the translation to the number machines actually need.

How long do DNS changes take to take effect?

It depends on the TTL of the record and how aggressively resolvers along the path have cached it. Changes can appear within minutes if the TTL is short, but may take up to 24 to 48 hours to fully propagate worldwide when older cached values are still in use.

What is the difference between a recursive resolver and an authoritative server?

A recursive resolver does the legwork of finding an answer by querying other servers on your behalf and caching the result. An authoritative server is the definitive source that actually holds a domain's records and gives the final answer.

Is DNS encrypted?

Traditional DNS is not encrypted, meaning queries travel in plain text. Newer standards such as DNS over HTTPS and DNS over TLS encrypt the traffic between your device and the resolver, while DNSSEC adds signatures that verify the authenticity of the answers.

How can I check the DNS records for a domain?

You can use command-line tools like dig or nslookup, or a browser-based DNS lookup service. These let you request specific record types such as A, AAAA, MX, and TXT so you can verify configuration or troubleshoot problems.