DNS works by translating human-readable domain names into the network information computers need to reach online services. When you enter a website address such as example.com, the Domain Name System (DNS) helps your device find the IP address associated with that name. A DNS resolver obtains the necessary records, often from its cache or through a series of queries to other DNS servers, and returns the result to your device.
Your browser can then use that information to connect to the appropriate web service.
DNS makes the internet easier to use because people can remember names instead of numerical addresses. But the system is more than a simple directory. It is a distributed, hierarchical network of servers that cooperate to locate and deliver naming information.
What Is DNS?
DNS stands for Domain Name System. It is the internet’s distributed naming system, allowing applications to retrieve information associated with domain names.
A domain name is a human-readable identifier such as example.com.
An IP address is a numerical address used by networking systems to deliver packets toward their destinations.
DNS connects these two concepts by storing and retrieving records associated with names.
According to ICANN’s explanation of DNS, DNS resolution involves cooperating components, including client resolvers, recursive resolvers, and authoritative nameservers.
DNS is commonly compared to a phone book because it helps find an address associated with a name.
However, the comparison has an important limitation.
DNS is not one centrally stored directory. It is a hierarchical system in which different organizations manage different portions of the namespace.
It also stores more than IP addresses.
DNS records can identify mail servers, delegate authority to nameservers, provide service information, and support security-related functions.
How Does DNS Work Step by Step?
To understand DNS resolution, consider what happens when you enter:
https://www.example.com
This example assumes the browser needs an IPv4 address and the necessary DNS information is not already cached.
In practice, cached answers and alternative resolution methods often shorten the process.
Step 1: Your Device Requests DNS Information
When you enter a website address, your web browser identifies the hostname it needs to contact.
In this example, the hostname is:
www.example.com
The browser or operating system first checks whether usable addressing information is already available.
Depending on the system, the information might be stored in a browser cache, an operating-system cache, or another configured resolution mechanism.
If the required information is unavailable, the device sends a DNS query.
A typical query asks:
What IPv4 address is associated with www.example.com?
In DNS terminology, this is a query for an A record.
The device usually sends the query to a configured recursive DNS resolver.
Step 2: The Recursive Resolver Receives the Query
A recursive DNS resolver is a server responsible for obtaining DNS answers on behalf of clients.
It may be operated by an internet service provider (ISP), a public DNS provider, a business, or another network operator.
The resolver first checks whether it already has a valid cached answer.
If it does, it can return the information without contacting authoritative DNS infrastructure again.
If the answer is not cached, the resolver must obtain the relevant information.
This usually involves following the DNS hierarchy.
Cloudflare’s DNS resolution overview explains how recursive resolvers locate records by consulting other DNS servers.
The resolver performs this work so the original device does not need to contact every nameserver itself.
Step 3: The Resolver Contacts a Root Nameserver
When the recursive resolver lacks sufficient cached delegation information, it can query a DNS root nameserver.
The DNS root is the highest level of the public DNS hierarchy.
Its main purpose in this process is to direct queries toward the nameservers responsible for top-level domains.
For example, when resolving www.example.com, a root server can provide a referral toward the nameservers responsible for .com.
The root server does not normally return the website’s final IP address.
Instead, it provides information that helps the resolver continue the lookup.
The Internet Assigned Numbers Authority (IANA) coordinates the root zone, including technical delegation information for top-level domains, as described in its Root Zone Management documentation.
The root system is distributed across many server locations. It is not one physical computer storing every domain name.
Step 4: The Resolver Queries a TLD Nameserver
Using the referral from the root, the resolver queries an appropriate top-level domain nameserver.
A top-level domain, or TLD, is the rightmost visible portion of a domain name.
Examples include:
.com.org.net.edu
For www.example.com, the relevant TLD is .com.
The .com nameserver generally does not need to know the final IP address of every website registered under .com.
Instead, it provides information identifying the authoritative nameservers for example.com.
This is called a DNS delegation.
Delegation allows responsibility for different portions of the naming system to be distributed among different operators.
Step 5: The Resolver Contacts an Authoritative Nameserver
The recursive resolver next contacts an authoritative nameserver responsible for the relevant DNS zone.
An authoritative nameserver stores or serves DNS data for the portion of the namespace it manages.
For example, the authoritative nameservers for example.com may contain records related to:
www.example.com
The resolver requests the appropriate record type.
If the authoritative server has the requested information, it can return an answer.
For an A record lookup, that answer may contain an IPv4 address.
The distinction between recursive and authoritative servers is important:
The recursive resolver finds the answer. The authoritative nameserver provides authoritative information about the DNS data it manages.
An authoritative server can also return other responses, including a delegation, an alias, or an indication that a requested name or record does not exist.
Step 6: DNS Returns the IP Address
Suppose the authoritative nameserver returns this hypothetical DNS record:
www.example.com. 3600 IN A 192.0.2.42
The record contains several parts:
| Component | Value | Meaning |
|---|---|---|
| Name | www.example.com. | Domain name associated with the record |
| TTL | 3600 | Cache lifetime in seconds |
| Class | IN | Internet DNS class |
| Type | A | IPv4 address record |
| Data | 192.0.2.42 | IPv4 address in the record |
This is an illustrative record, not a claim about the actual DNS configuration of example.com. The IP address belongs to a range reserved for documentation.
The recursive resolver can cache the information according to the applicable caching rules.
It then returns the answer to the requesting device.
The original device now has the address information needed for the next stage of communication.
Step 7: The Browser Connects to the Website
After receiving the DNS answer, the browser can attempt to contact the destination.
Its network traffic travels through local networking equipment and other interconnected networks.
A web server or intermediary service receives the request and provides the appropriate response.
For an HTTPS connection, the browser also establishes the required secure transport and authenticates the server.
The server may return HTML, stylesheets, scripts, images, and other resources.
The browser processes these resources and displays the website.
DNS did not download the webpage.
It provided naming information used to locate the service.
The movement of data across networks is a separate process explained in How Does the Internet Work?.
What Are the Four Main Types of DNS Servers?
A conventional DNS lookup often involves four important server roles.
| DNS Component | Main Responsibility |
|---|---|
| Recursive resolver | Finds DNS answers for clients and caches results |
| Root nameserver | Refers queries toward the appropriate TLD nameservers |
| TLD nameserver | Provides delegation information for domains under its TLD |
| Authoritative nameserver | Supplies authoritative DNS data for the zones it manages |
These are functional roles, not necessarily four separate physical machines for every request.
A recursive resolver may already have all the information it needs.
In that case, it can answer immediately from cache.
Similarly, the resolver may already know the authoritative nameservers for a domain and contact them directly.
This is why not every DNS lookup reaches a root or TLD nameserver.
Recursive vs. Authoritative DNS: What’s the Difference?
The recursive resolver acts on behalf of the client.
It accepts a request and obtains the necessary answer using cached data, queries to other servers, or forwarding arrangements.
An authoritative nameserver is responsible for publishing DNS information for a particular zone.
For example, if you manage a domain, its authoritative DNS service contains the records you configure.
A recursive resolver operated by your ISP can retrieve those records and return them to people trying to reach your domain.
The DNS architecture and these distinct responsibilities are described in the original DNS concepts specification, RFC 1034.
How Does DNS Know Which Server to Ask?
DNS uses a hierarchy of names and delegation records.
Consider the domain:
shop.example.com
Reading from right to left, the DNS hierarchy includes the root, the .com top-level domain, and the example.com namespace.
A zone’s authoritative nameservers publish information about names for which that zone is responsible.
If a subdomain has been delegated to another DNS zone, the resolver may need to follow an additional referral.
This architecture allows different organizations to control their own DNS information.
The operator of the .com registry does not need to manage the individual website records of every registered .com domain.
Likewise, the administrator of example.com can manage names beneath that domain without changing the root zone.
The distributed design makes DNS scalable and allows authority to be delegated while maintaining a shared global namespace.
What Are DNS Records, and How Do They Work?
DNS records, formally called resource records, contain information associated with domain names.
Different record types answer different questions.
| DNS Record | Function |
|---|---|
| A | Provides an IPv4 address |
| AAAA | Provides an IPv6 address |
| CNAME | Identifies another domain name as an alias |
| MX | Identifies mail exchange servers |
| NS | Identifies nameservers for a DNS zone or delegation |
| TXT | Stores text information used by various services |
| SOA | Provides administrative information about a DNS zone |
| PTR | Associates an address-derived name with another domain name, commonly used in reverse DNS |
Cloudflare’s DNS record reference explains how these record types are used in practical DNS configurations.
A and AAAA Records
An A record associates a DNS name with an IPv4 address.
An AAAA record associates a name with an IPv6 address.
The distinction matters because IPv4 and IPv6 use different addressing formats.
An application may request both record types and select a suitable address based on network connectivity and connection behavior.
A domain name can have multiple A or AAAA records.
It is therefore incorrect to assume that every domain always corresponds to exactly one IP address.
CNAME Records
A CNAME record identifies another domain name as the canonical name for an alias.
For example, a hypothetical configuration might say:
www.example.com. IN CNAME web.example.net.
The resolver then needs the relevant address information for web.example.net.
The CNAME itself does not contain an IP address.
This allows administrators to point an alias toward another name instead of directly maintaining its address records.
However, standard DNS rules restrict how CNAME records can coexist with other record types at the same name.
MX Records
MX records identify the servers responsible for receiving email for a domain.
For example, email sent to an address ending in example.com can be directed toward a mail server identified through the domain’s MX records.
This demonstrates that DNS is not limited to websites.
It supports multiple types of internet services.
How Does DNS Caching Work?
DNS caching temporarily stores previously obtained DNS information so that future queries can be answered more efficiently.
Without caching, recursive resolvers would need to repeat many of the same queries to authoritative servers.
Caching reduces unnecessary network requests, lowers lookup delays, and decreases load on DNS infrastructure.
Where Is DNS Information Cached?
DNS information can be cached at multiple levels:
- Browser: Some browsers maintain their own DNS-related caches.
- Operating system: The device may temporarily store resolution results.
- Local network: A router or local DNS forwarding service may cache or relay DNS answers.
- Recursive resolver: The DNS provider typically caches records obtained from other servers.
Not every device or network uses all these caching layers.
The precise behavior depends on its software and configuration.
What Is DNS TTL?
TTL stands for Time to Live.
It tells a caching resolver how long DNS record data may normally be retained before it needs to be refreshed.
TTL values are expressed in seconds.
For example:
www.example.com. 3600 IN A 192.0.2.42
A TTL of 3,600 seconds corresponds to one hour.
If a resolver caches this record and the authoritative record changes shortly afterward, the resolver may continue using the old value until its cached answer expires.
Other resolvers that did not cache the old value may obtain the updated answer sooner.
Cloudflare’s DNS TTL documentation explains how record lifetimes influence caching and the visibility of DNS changes.
Actual caching behavior may also be affected by resolver policies and supported extensions.
Why Do DNS Changes Take Time?
Suppose a website moves from one hosting provider to another.
The site administrator updates its authoritative DNS record to point toward the new infrastructure.
The change may be available immediately on the authoritative service, but recursive resolvers could still have the previous answer cached.
As cached entries expire or are refreshed, more clients receive the updated information.
This is commonly called DNS propagation.
However, the term can be misleading.
A DNS record change is not necessarily broadcast to every DNS server around the world.
Much of the delay comes from different caches continuing to use previously obtained information.
Consequently, two users can temporarily receive different DNS answers for the same domain.
What Happens If DNS Cannot Find a Domain?
DNS does not always return an address.
A lookup can fail for several different reasons.
NXDOMAIN: The Name Does Not Exist
An NXDOMAIN response indicates that the queried name does not exist in the relevant DNS namespace, according to the answer received.
For example, a misspelled domain may produce this response.
NXDOMAIN does not necessarily mean the internet connection is broken.
It means DNS could not find the requested name.
NOERROR Without the Requested Record
A domain name can exist even when it has no record of the type requested.
For example, a name may exist without an A record.
A DNS lookup for that A record can return a successful response with no relevant answer.
This is different from saying the domain name does not exist.
SERVFAIL: The Resolver Could Not Complete the Request
SERVFAIL means the DNS server was unable to complete the query successfully.
Possible reasons include upstream server problems, configuration issues, or DNSSEC validation failures.
It does not necessarily indicate that the domain is unregistered or nonexistent.
Can Failed DNS Answers Be Cached?
Yes.
DNS supports negative caching.
This allows resolvers to temporarily remember certain negative answers instead of repeatedly asking authoritative servers about the same missing information.
The mechanism is defined in RFC 2308: Negative Caching of DNS Queries.
Negative caching improves efficiency, but it can also explain why a newly created DNS record may not become visible immediately to clients that previously received a negative answer.
How Does DNS Use UDP and TCP?
DNS exchanges information over network transport protocols.
Traditional DNS communication commonly uses UDP on port 53.
UDP has relatively little transport overhead, making it suitable for many short DNS query-and-response exchanges.
However, DNS also uses TCP.
TCP is useful or required in situations involving larger responses, certain transfer operations, and other protocol requirements.
The DNS over TCP implementation requirements explain why compliant DNS implementations must support TCP rather than treating DNS as a UDP-only protocol.
DNS communication can also use encrypted transports, including DNS over TLS and DNS over HTTPS.
The important distinction is that DNS defines the naming protocol and record format, while the transport determines how DNS messages move between communicating systems.
How Does DNS Security Work?
Traditional DNS was designed before many modern internet security threats became widespread.
Basic DNS messages do not inherently provide end-to-end confidentiality or cryptographic verification of the information they contain.
Several technologies address different security concerns.
DNSSEC: Authenticating DNS Information
DNS Security Extensions (DNSSEC) add cryptographic signatures that can help validating resolvers verify the authenticity and integrity of DNS data.
DNSSEC creates a chain of trust through signed zones and their delegations.
A properly configured validating resolver can use this chain to detect certain kinds of forged or modified DNS responses.
According to ICANN’s DNSSEC explanation, DNSSEC provides data-origin authentication and integrity protection for signed DNS information.
However, DNSSEC does not encrypt DNS queries.
It also does not make a website safe merely because its DNS records are signed.
DNS over HTTPS: Encrypting DNS Queries
DNS over HTTPS, commonly called DoH, carries DNS queries and responses over HTTPS connections.
This protects the DNS exchange between the client and the DoH resolver from straightforward observation or modification by intermediaries on that connection.
The protocol is specified in RFC 8484.
DNS over TLS (DoT) provides a related protection using TLS transport for DNS communication.
These technologies improve privacy on the protected portion of the network path.
However, they do not automatically encrypt the entire DNS resolution chain or hide all internet activity.
The DNS resolver itself still processes the queries it receives.
The provider operating that resolver may have access to information about the requested names.
DNSSEC vs. DNS over HTTPS
| Technology | Main Protection | What It Does Not Guarantee |
|---|---|---|
| DNSSEC | Authenticity and integrity of signed DNS data | Confidentiality of DNS queries |
| DNS over HTTPS | Encryption of DNS exchanges between client and DoH resolver | Authenticity of all authoritative DNS data |
| DNS over TLS | Encryption of DNS exchanges over a TLS connection | Complete anonymity or protection of unrelated traffic |
DNSSEC and encrypted DNS transports can complement one another.
They address different weaknesses of DNS communication.
Likewise, HTTPS protects web connections, not the accuracy of every DNS record used to locate a website.
Why Can a Website Use Different IP Addresses in Different Locations?
A domain name does not always resolve to the same IP address for every user.
Large websites may use multiple servers, regional infrastructure, traffic-management systems, and distributed content delivery networks.
For example, a website may serve users in North America through one group of servers and users in Europe through another.
A DNS service can return different records depending on its configuration and the available information about the requesting resolver or client.
A content delivery network (CDN) may also combine DNS-based traffic steering with network routing techniques such as anycast.
This can help users reach suitable infrastructure without requiring every request to travel to one distant origin server.
However, DNS does not directly measure and optimize every packet’s journey.
The IP routing system determines how packets actually travel between networks after the destination address is selected.
Can the Internet Work Without DNS?
Yes.
DNS is essential to the convenient operation of many internet services, but IP networking does not fundamentally require every connection to begin with a DNS lookup.
A device can communicate with another system using a known IP address if the required network path and application configuration are available.
For example, certain administrative tools and network diagnostics can contact an IP address directly.
However, accessing a website by typing only an IP address into a browser may not work as expected.
Modern web hosting commonly uses hostnames to distinguish different websites sharing the same address.
HTTPS authentication also depends on the identity of the requested server, which can complicate direct-IP access.
DNS therefore provides a naming layer that makes the internet practical for people and applications.
If DNS resolution stops working, many familiar services may become inaccessible even while the underlying internet connection remains functional.
This is why a DNS failure can feel like a complete internet outage.
Why Is DNS Important to the Internet?
DNS separates recognizable names from the underlying network addresses and service infrastructure.
This provides several important capabilities.
People can reach websites using memorable names.
Organizations can change servers or network providers without necessarily changing their public-facing domain names.
Different services can use specialized DNS records.
Recursive resolvers can cache frequently requested information, reducing repeated network queries.
The hierarchy also allows responsibility for naming information to be distributed among independent organizations.
DNS is therefore not simply a convenience feature for web browsers.
It is a fundamental naming infrastructure supporting websites, email, and many other internet services.
DNS Connects Names to Network Information
DNS works through a distributed system of recursive resolvers, root nameservers, TLD nameservers, and authoritative nameservers.
When a device needs information associated with a domain name, a resolver obtains the relevant DNS records and returns the answer.
Caching allows many lookups to finish without contacting the full hierarchy, while DNSSEC and encrypted DNS transports address different aspects of security and privacy.
DNS does not transport webpages or determine the entire route of internet packets.
Its essential function is to answer a more specific question:
What information does an application need to locate or use the service associated with this name?
That separation between human-readable names and network infrastructure is one of the key mechanisms that makes the modern internet usable.