DNS translates domain names into IP addresses. But how does DNS work behind this translation? A DNS query travels through a hierarchy of servers, and caching determines how answers are stored and reused. When DNS records change, these cached answers also determine how quickly the changes become visible across different networks. This guide explains the key aspects of how DNS works: how DNS is structured, how DNS resolution works, and how DNS propagation works.
What is DNS?
The Domain Name System (DNS) is a distributed, hierarchical system that translates human-readable domain names into machine-readable IP addresses. It allows devices and applications to locate network resources by name instead of requiring users to remember IP addresses.
Web browsing, email delivery, API calls, authentication, and cloud services all depend on DNS to resolve hostnames to the destinations they need to reach. Internal enterprise resources, such as application servers, file shares, and VoIP systems, also rely on DNS for hostname-based access.
With millions of domains and billions of connected devices, a single centralized system to store and resolve every domain name would not scale. Instead, DNS distributes responsibility across multiple levels of the namespace, with different servers managing different portions of it. This hierarchical structure allows DNS to scale while distributing authority and resolution across the global network.
DNS architecture: The namespace hierarchy
The DNS namespace is structured as an inverted tree, with the root at the top and domains branching into progressively smaller levels. At the top of the hierarchy is the root, represented by a single dot (.). Below the root are top-level domains (TLDs), second-level domains, and subdomains.
How the DNS namespace is structured
- Root (.) is the top of the DNS hierarchy.
- Top-level domains (TLDs) are generic TLDs such as .com, .org, and .net, country-code TLDs such as .uk and .de, and newer TLDs such as .io and .cloud.
- Second-level domains include manageengine.com, google.com, bbc.co.uk.
- Subdomains examples are www.manageengine.com, mail.corp.local, api.service.internal.
Each level of the hierarchy delegates authority to the level below it. For example, the root zone provides information about the authoritative nameservers for .com. The .com TLD nameservers then provide information about the authoritative nameservers responsible for manageengine.com. Those authoritative nameservers hold the DNS records for the domain's hostnames and subdomains.
This delegation model makes DNS scalable. No single DNS server needs to store information about every domain. Instead, authority is distributed across different levels of the namespace, with each level directing queries toward the servers responsible for the next part of the domain.
DNS zones: The administrative unit
A DNS zone is an administrative portion of the DNS namespace managed by a specific organization or administrator. A zone contains DNS records that define how names within that portion of the namespace are resolved, including records that map hostnames to IP addresses, route email, and support reverse DNS lookups.
A namespace can also be divided into multiple zones through delegation. For example, an organization managing example.com can delegate engineering.example.com to a separate zone managed by its engineering team, with its own authoritative nameservers. This allows different teams to manage portions of a large DNS namespace without centralizing every record.
How DNS resolution works
DNS resolution is the process of translating a domain name into an IP address. When a cached answer is unavailable, a recursive resolver works through the DNS hierarchy to find the authoritative answer. This can involve the root, TLD, and authoritative nameservers. In practice, caching allows many queries to be answered directly by the recursive resolver without repeating the full lookup process.
Step 1: The client sends a query to a recursive resolver
When you enter a domain name, your device's stub resolver which is a DNS client built into the operating system, sends the query to the recursive resolver configured on the device. This resolver is typically assigned through DHCP or configured manually.
The recursive resolver first checks its cache. If it has a valid cached answer, it returns the answer to the client. If the answer is not cached or the cached record has expired, the resolver continues through the DNS hierarchy to find the answer.
Step 2: The recursive resolver queries a root nameserver
If the answer isn't available in its cache, the recursive resolver queries a root nameserver. The root server does not provide the IP address for the requested domain. Instead, it identifies the appropriate TLD nameservers for the domain's extension and returns a referral to them.
Step 3: The recursive resolver queries the TLD nameserver
The recursive resolver then queries a TLD nameserver for the domain. The TLD nameserver does not contain the domain's individual DNS records. Instead, it identifies the authoritative nameservers responsible for that domain and returns a referral to them.
Step 4: The recursive resolver queries the authoritative nameserver
The recursive resolver then queries the authoritative nameserver for the requested domain. The authoritative nameserver holds the DNS records for that domain and returns the requested record, such as an A record for an IPv4 address, an AAAA record for an IPv6 address, or an MX record for email routing.
This is the authoritative answer to the DNS query.
Step 5: The recursive resolver returns and caches the answer
The recursive resolver returns the answer to the client's stub resolver. It also stores the response in its cache according to the record's TTL (Time to Live).
When another client requests the same domain before the cached record expires, the recursive resolver can return the cached answer without querying the root, TLD, or authoritative nameservers again. This reduces the number of DNS queries that need to travel through the hierarchy and improves resolution efficiency.
DNS caching and TTL
Every DNS record has a Time to Live (TTL) value, expressed in seconds, that determines how long a resolver can cache the record before it needs to retrieve a fresh copy from the authoritative nameserver.
For example, a TTL of 3,600 seconds means a resolver can cache the record for one hour. During that period, it can return the cached answer for subsequent queries without contacting the authoritative nameserver. Once the TTL expires, the resolver must obtain a fresh answer when the record is requested again.
TTL affects both DNS resolution and propagation:
- Higher TTLs allow records to remain cached for longer, reducing repeated queries and resolver load. However, changes to those records may take longer to become visible because older cached answers can remain available until they expire.
- Lower TTLs cause records to be refreshed more frequently, allowing changes to become visible sooner. However, they can increase the number of queries sent to DNS system.
The appropriate TTL depends on how frequently a DNS record changes and how quickly updates need to become visible. Records that rarely change can generally use longer TTLs, while records that change frequently may use shorter TTLs.
For planned DNS changes, administrators may lower the TTL in advance so that existing cached records expire sooner after the change. Once the change is confirmed, the TTL can be increased again.
How DNS propagation works
DNS propagation describes how a DNS record change becomes visible to users as cached copies of the previous record expire and resolvers retrieve the updated record. Despite the term “propagation,” DNS does not push a changed record from the authoritative nameserver to every resolver across the internet. Instead, each recursive resolver independently refreshes its cached DNS data based on the record's TTL.
This is why DNS changes can appear to take time to become visible and why different users may temporarily receive different DNS answers for the same domain.
What happens when you update a DNS record
When you modify a DNS record on an authoritative nameserver, the updated record is available there immediately. However, recursive resolvers that previously cached the old record can continue returning that cached answer until its TTL expires.
The process works as follows:
- You update the DNS record on the authoritative nameserver.
- Recursive resolvers that have the old record cached continue serving it until the cached TTL expires.
- Once the cached record expires, the resolver performs a fresh recursive lookup and queries the authoritative nameserver for the current record.
- The resolver receives the updated record and caches it according to the new TTL.
- Clients using that resolver then receive the updated DNS answer.
As a result, different users can temporarily receive different DNS answers for the same domain. This is normal behavior in a distributed, cached DNS system rather than an indication that the DNS change has failed.
What determines DNS propagation time?
The most important factor affecting how quickly a DNS change becomes visible is the TTL of the old record.
For example:
- If the old record has a TTL of 86,400 seconds (24 hours), a resolver that cached the record one hour before the change could continue serving the old answer for up to another 23 hours.
- If the old record has a TTL of 300 seconds (5 minutes), a resolver may retrieve the updated record after its existing cache expires within five minutes.
- Lowering the TTL after making the change does not accelerate propagation for resolvers that already cached the old record. The lower TTL needs to be in effect before the change.
Other factors can also influence how DNS changes appear to users. Negative caching, for example, allows resolvers to temporarily cache negative responses such as NXDOMAIN. In some environments, forwarding resolvers can also introduce additional caching between the client and the recursive resolver.
What DNS propagation checkers actually show
DNS propagation checkers query a domain from DNS resolvers in different locations and report which resolvers are returning the new record. They can help verify whether a DNS change is becoming visible across different resolvers, but they do not accelerate propagation or force other resolvers to refresh their caches.
If a propagation checker still shows the old record from a particular resolver, that generally means the resolver is still serving its cached answer.
Flushing the local DNS cache on a device can force the device to request the record again from its configured recursive resolver. For example, ipconfig /flushdns can be used on Windows, while macOS provides DNS cache-flushing commands that vary by OS version. However, flushing the local cache does not clear the cache maintained by the upstream recursive resolver. If that resolver still has the old record cached, the device can continue to receive the old answer.
Propagation vs. resolution: Key differences
DNS resolution and DNS propagation describe different processes that are often confused.
DNS resolution is the process of finding the DNS answer for a hostname. When a resolver does not have a valid cached answer, it queries the DNS hierarchy to obtain the required record from an authoritative nameserver.
DNS propagation describes what happens after a DNS record changes. Recursive resolvers that have cached the previous answer continue serving it until their cached data expires. They then perform a new resolution and retrieve the updated record.
The relationship between the two is important: DNS propagation relies on DNS resolution. When a resolver's cached copy of a record expires, it performs a new DNS resolution to retrieve the current record. Propagation is therefore not a separate mechanism that pushes updates across the internet; it is the gradual replacement of cached DNS data as resolvers refresh their records.
What DNS behavior means for network administrators
Understanding how DNS resolution, caching, TTL, and propagation work helps network administrators plan changes and troubleshoot unexpected DNS behavior in enterprise environments.
Plan DNS changes around TTL
The TTL of a DNS record determines how long recursive resolvers can continue serving a cached answer. For planned changes such as server migrations, IP address changes, failover testing, or cloud moves, administrators can lower the TTL in advance so that cached copies of the old record expire sooner.
For example, if a record normally uses a 24-hour TTL, lowering it before a planned change can reduce the time during which resolvers may continue serving the previous answer. After the change is confirmed and stable, the TTL can be increased again.
The key point is that changing the TTL after updating a record does not immediately clear existing cached copies. The previous TTL still determines how long those cached answers can remain available.
Validate DNS after infrastructure changes
DNS can be affected by infrastructure changes even when no DNS records are modified. Firewall changes, VLAN reconfigurations, DHCP scope updates, routing changes, and server migrations can affect which DNS resolvers clients can reach or which DNS records they receive.
After an infrastructure change, verify that:
- Clients can reach their configured DNS resolvers.
- Forward lookups return the expected addresses.
- Reverse lookups return the expected hostnames where reverse DNS is configured.
- Updated records are being returned after cached copies expire.
- DNS records do not continue pointing to decommissioned or migrated resources.
These checks help distinguish a DNS configuration issue from a problem caused by caching, connectivity, or other infrastructure changes.
Why understanding DNS behavior matters
DNS issues are not always caused by a failed DNS server. A resolver can be reachable and responding while clients still receive an outdated answer because that answer is cached. Similarly, a DNS record can be correctly updated on an authoritative nameserver while some users continue receiving the previous record until their recursive resolvers refresh their caches.
Understanding these interactions helps administrators interpret DNS behavior correctly and identify where in the resolution process an issue is occurring.
Manage DNS with ManageEngine OpUtils
ManageEngine OpUtils provides DNS monitoring and management from a centralized console. For DNS monitoring, OpUtils continuously checks DNS resolution to help administrators identify resolution failures and unexpected responses across their DNS infrastructure. For DNS management, OpUtils lets administrators manage Microsoft DNS zones and records and manage AWS Route 53 hosted zones and DNS records from the same console. This brings DNS visibility and administration together with IP address and DHCP management, helping administrators maintain consistent DNS and network data across their environment.
Try OpUtils for free for the next 30 days or schedule a free, personalized demo and we will connect you with the right product expert.
Closing note:
DNS works through a combination of hierarchical delegation, recursive resolution, and caching. Recursive resolvers find authoritative answers when needed, cache those answers according to TTL, and refresh them when cached data expires. Understanding this process helps explain why DNS queries are usually fast, why DNS changes can take time to become visible, and where administrators should look when DNS behavior is unexpected.
FAQs: How DNS works
How does DNS work?
When you enter a domain name, your device sends a DNS query to a recursive resolver. If the resolver has a valid cached answer, it returns the answer directly. If the answer is not cached, the resolver queries the DNS hierarchy, starting with a root nameserver, followed by the appropriate TLD nameserver and the authoritative nameserver for the domain. The authoritative nameserver returns the requested DNS record, and the recursive resolver sends the answer back to the client and caches it according to the record's TTL. This combination of hierarchical delegation, recursive resolution, and DNS caching allows DNS to translate domain names into IP addresses efficiently at global scale.