DNS Resolution Explained

When you enter a domain such as example.com into a browser, the browser needs to discover which server should receive the request. Humans prefer domain names because they are easier to remember, while networks communicate using IP addresses. DNS, or the Domain Name System, provides the mechanism that connects these two worlds.

DNS resolution is the process of finding the DNS information associated with a domain name. In the common case, this means resolving a hostname such as www.example.com to an IPv4 address through an A record or to an IPv6 address through an AAAA record.

The process can involve several layers of caching and multiple DNS servers. Understanding those layers makes it much easier to troubleshoot problems such as stale records, failed lookups, incorrect nameservers, missing records, and apparent DNS propagation delays.

What Is DNS Resolution?

DNS resolution is the process of determining the DNS data associated with a domain name. When an application needs to connect to a hostname, it usually asks a DNS resolver for the required information.

www.example.com
        ↓
DNS resolution
        ↓
IP address
        ↓
Network connection

The returned result is not necessarily just an IP address. DNS can provide many different types of information, including mail servers, aliases, nameservers, text records, service information, and other data.

Why Do We Need DNS?

IP addresses are useful to computers and network infrastructure, but they are not convenient names for people. DNS allows services to be identified by stable, human-readable names while their underlying infrastructure can change.

A domain can also point to different infrastructure over time. DNS allows administrators to change the destination without requiring users to remember a new address.

The Main Parts of DNS Resolution

A typical DNS lookup can involve several components. The exact path varies depending on caches and configuration, but the important participants are the client, recursive resolver, root servers, TLD servers, and authoritative nameservers.

Step 1: The Application Needs a Hostname Resolved

Suppose a browser needs to connect to www.example.com. The browser or operating system first needs an IP address for that hostname.

The application usually does not communicate directly with a root DNS server. Instead, it uses the operating system's DNS configuration, which typically points to one or more recursive resolvers.

Application
    ↓
Operating system DNS resolver
    ↓
Configured recursive DNS resolver

The operating system and other local components can also have cached DNS information, allowing the lookup to finish without contacting a remote DNS server.

Step 2: Check Local DNS Information

Before a recursive resolver needs to search the DNS hierarchy, cached information may already exist on the client or network. Browsers, operating systems, local DNS services, and other components can cache DNS results.

If a valid cached result exists, the system can reuse it until its TTL expires. This is one of the main reasons DNS resolution is usually much faster than performing a complete lookup through the DNS hierarchy every time.

Step 3: Ask a Recursive Resolver

If the local system does not already have a usable answer, it sends a DNS query to a recursive resolver. The recursive resolver is responsible for finding the answer on behalf of the client.

A recursive resolver may be operated by an internet service provider, public DNS provider, organization, cloud platform, or another network administrator.

The client generally expects the recursive resolver to return the final answer rather than having to understand the entire DNS hierarchy itself.

Recursive vs Authoritative DNS Servers

This distinction is important. A recursive resolver may know an answer because it previously queried an authoritative server and cached the result. The authoritative server is the source of the DNS data for the zone.

Step 4: Contact a Root DNS Server

If the recursive resolver does not already know where to find the domain's authoritative servers, it can query the DNS root system.

The root DNS system does not normally provide the IP address for www.example.com. Instead, it knows where to find servers responsible for top-level domains such as .com, .org, .net, and country-code TLDs.

Root DNS
    ↓
.com TLD servers

Step 5: Query the TLD Servers

The top-level domain, or TLD, is the part of a domain such as .com, .org, or .net. After receiving information from the root system, the recursive resolver can query the appropriate TLD servers.

The TLD server knows which authoritative nameservers are responsible for the requested domain. It does not normally provide the final A or AAAA record for the hostname.

.com TLD
    ↓
Authoritative nameservers for example.com

Step 6: Query the Authoritative DNS Server

The recursive resolver can now query an authoritative nameserver for the domain. The authoritative server contains the DNS records that define how the domain should resolve.

Authoritative DNS
    ↓
www.example.com → A → 93.184.216.34

The authoritative response may contain an A record, AAAA record, CNAME record, or another type of DNS information depending on the query.

Step 7: Return the Result to the Client

After obtaining the required information, the recursive resolver returns the result to the requesting client. The client can then use the returned address to establish the appropriate network connection.

The resolver usually caches the response according to its TTL, meaning future requests can often be answered without repeating the entire recursive process.

DNS Resolution Example

Consider a request for www.example.com. A simplified resolution sequence looks like this:

Client
    ↓
Recursive resolver
    ↓
Root DNS
    ↓
.com TLD
    ↓
Authoritative DNS for example.com
    ↓
A record
    ↓
IP address

In practice, some or all of these steps may be skipped because the recursive resolver already has cached information. DNS caching is therefore an essential part of the system's performance.

DNS Caching

DNS caching stores previously obtained DNS results so that they can be reused for a period of time. Caching exists at multiple levels, including applications, operating systems, local networks, recursive resolvers, and other infrastructure.

Caching reduces DNS traffic and latency. It also means that a DNS change does not necessarily become visible everywhere immediately.

What Is DNS TTL?

TTL stands for Time to Live. In DNS, the TTL specifies how long a cached DNS record may generally be retained before it needs to be refreshed.

example.com. 3600 IN A 93.184.216.34

In this example, 3600 represents a TTL of 3600 seconds, or one hour.

TTL is not a guarantee that every client will observe a change at exactly the specified time. Different layers can have their own caching behavior, and some systems may not behave exactly as expected.

Why DNS Changes Can Take Time

When a DNS record changes, recursive resolvers that already cached the previous value may continue using it until the cached entry expires.

This is commonly described as DNS propagation. Strictly speaking, DNS does not continuously push every change to every resolver. Instead, different caches refresh their data over time.

DNS Propagation Is Not a Single Global Event

There is no central process where a DNS change is simultaneously copied to every device on the internet. Different resolvers can have different cached values and different refresh times.

For example, one resolver may already have refreshed a record while another still has the previous value cached. This explains why two users can temporarily receive different DNS answers for the same hostname.

DNS Records Used During Resolution

DNS resolution is not limited to A records. Different DNS record types serve different purposes.

A Records

An A record maps a hostname to an IPv4 address. It is one of the most common records involved in normal web browsing.

www.example.com. 300 IN A 192.0.2.10

The value 192.0.2.10 is an IPv4 address. The 300 value represents the record's TTL in seconds.

AAAA Records

An AAAA record performs a similar function for IPv6 addresses.

www.example.com. 300 IN AAAA 2001:db8::10

A hostname can have both A and AAAA records. A client with IPv6 connectivity may be able to use the IPv6 address, while another client may use IPv4.

CNAME Records

A CNAME record makes one hostname an alias for another hostname.

www.example.com. 300 IN CNAME example.com.

The resolver can follow the CNAME and continue resolving the target hostname until it obtains the information needed by the client.

NS Records

NS records identify the authoritative nameservers for a DNS zone. Delegation information at the parent zone tells resolvers which nameservers are responsible for the child zone.

example.com. 86400 IN NS ns1.example-dns.com.
example.com. 86400 IN NS ns2.example-dns.com.

If nameserver delegation is incorrect, recursive resolvers may be unable to reach the authoritative DNS service containing the expected records.

MX Records

MX records identify mail servers responsible for receiving email for a domain. They are not normally involved when a browser resolves a website hostname, but they are an important part of DNS-based service discovery.

example.com. 3600 IN MX 10 mail.example.com.

The number before the mail server is the preference value. Lower values have higher preference when multiple MX records are available.

TXT Records

TXT records contain text associated with a domain. They are widely used for domain verification and email-related policies such as SPF, DKIM-related configuration, and DMARC records.

TXT records are also used by many third-party services to prove control over a domain or configure service-specific settings.

SOA Records

The Start of Authority record contains administrative information about a DNS zone. It identifies the primary nameserver and includes values related to zone management and serial information.

SOA records are particularly useful when troubleshooting DNS zones because they provide information about the zone's authoritative configuration.

Reverse DNS Resolution

Normal DNS resolution commonly maps a hostname to an IP address. Reverse DNS performs the opposite kind of lookup: it attempts to find a hostname associated with an IP address.

Hostname
    ↓
A / AAAA
    ↓
IP address

IP address
    ↓
PTR
    ↓
Hostname

Reverse DNS uses PTR records. IPv4 reverse lookups use the in-addr.arpa namespace, while IPv6 reverse lookups use ip6.arpa.

Forward and Reverse DNS Are Different

A forward lookup and a reverse lookup do not necessarily produce a perfect two-way mapping. A domain can resolve to an IP address while the IP address has no PTR record, or a PTR record can point to a hostname that does not resolve back to the same address.

This is especially important when troubleshooting mail servers and infrastructure where reverse DNS configuration may be used as one part of reputation or validation checks.

What Is DNS Delegation?

DNS delegation is the mechanism that tells resolvers which nameservers are authoritative for a particular DNS zone. A parent zone can delegate responsibility for a child domain by publishing NS information.

.com
    ↓
example.com
    ↓
Authoritative nameservers

Delegation allows DNS administration to be distributed. The organization managing a domain can operate its authoritative nameservers or use a DNS provider to host the zone.

What Are Root Servers?

The DNS root system sits at the top of the public DNS hierarchy. Root servers provide referrals to authoritative infrastructure for top-level domains rather than storing the complete set of records for every domain.

There are 13 named root server identities, commonly identified by letters from A through M. Each identity is served by multiple instances distributed around the world using techniques such as anycast.

This means the internet does not depend on only 13 physical machines. The root system consists of many distributed server instances operated by different organizations.

What Is a TLD Server?

TLD servers are authoritative for top-level domains such as .com, .net, .org, and country-code domains. Their role in normal recursive resolution is to provide information about where the authoritative nameservers for a specific domain can be found.

For example, a .com TLD server can provide delegation information for example.com. The actual A record for www.example.com normally comes from the authoritative servers for example.com.

What Is an Authoritative DNS Server?

An authoritative DNS server hosts the DNS data for a zone and provides authoritative answers for names within that zone. It does not need to recursively search the DNS hierarchy to answer for the data it controls.

Authoritative DNS hosting can be provided by a domain registrar, dedicated DNS provider, cloud platform, CDN provider, or an organization's own infrastructure.

Recursive DNS Resolution vs Iterative Queries

The terminology around recursive and iterative DNS queries can be confusing. A client can ask a recursive resolver to obtain the final answer on its behalf. The resolver may then perform a series of queries where each server provides the best information it has, often referring the resolver to another server.

DNS Cache Poisoning

DNS cache poisoning is an attack in which incorrect DNS information is introduced into a resolver's cache. If successful, clients using that resolver could receive a malicious destination instead of the intended one.

Modern DNS infrastructure uses measures such as transaction identifiers, source-port randomization, and DNSSEC in environments where DNS data authenticity needs cryptographic protection.

What Is DNSSEC?

DNSSEC, or Domain Name System Security Extensions, adds cryptographic signatures to DNS data so validating resolvers can verify that the data originated from the expected DNS zone and was not modified in transit.

DNSSEC does not encrypt DNS queries. Its primary purpose is authenticity and integrity of DNS data rather than confidentiality.

DNS Over HTTPS and DNS Over TLS

Traditional DNS commonly uses UDP or TCP on port 53. DNS over HTTPS, or DoH, carries DNS queries through HTTPS. DNS over TLS, or DoT, uses TLS to protect DNS traffic.

DoH and DoT primarily address the confidentiality and transport security of DNS queries. They do not replace DNSSEC's role in validating the authenticity of DNS data.

DNS and HTTPS Are Different Layers

DNS and HTTPS solve different problems. DNS determines where a hostname should resolve, while HTTPS protects the subsequent application connection using TLS.

example.com
    ↓
DNS resolution
    ↓
IP address
    ↓
HTTPS connection
    ↓
HTTP request

A successful DNS lookup does not mean the website itself is working. DNS can resolve correctly while the server is offline, the TLS certificate is invalid, or the HTTP application returns an error.

DNS and DHCP Are Different

DNS resolves names to DNS records, while DHCP automatically provides network configuration such as IP addresses, gateways, and often DNS server information to devices on a network.

A device can receive its DNS resolver configuration through DHCP and then use that resolver for hostname lookups.

Why DNS Lookups Sometimes Fail

A DNS failure can occur at several points in the resolution process. The problem may be local to the client, related to the recursive resolver, caused by incorrect delegation, or caused by missing or invalid authoritative records.

NXDOMAIN vs SERVFAIL

NXDOMAIN means that the queried DNS name does not exist according to the relevant DNS authority. SERVFAIL means the resolver could not successfully produce an answer.

These responses should not automatically be treated as the same problem. NXDOMAIN can result from a genuinely nonexistent name, while SERVFAIL can indicate DNSSEC validation failures, unavailable authoritative servers, broken delegation, or other resolution problems.

Troubleshooting DNS Resolution

A systematic troubleshooting process is more effective than repeatedly refreshing a browser. Start by determining whether the problem exists locally or is visible to independent DNS resolvers.

• Check the hostname for spelling mistakes.
• Inspect the local DNS configuration.
• Query the hostname using a known recursive resolver.
• Check the authoritative nameservers.
• Inspect the relevant A, AAAA, CNAME, or other records.
• Check the record TTL and cached results.
• Verify nameserver delegation.
• Check DNSSEC status when applicable.
• Compare answers from multiple resolvers.
• Verify that the resolved IP actually hosts the expected service.

Use DNS Lookup Tools

A DNS Lookup tool can quickly show the records returned for a domain or hostname. This is useful when checking A, AAAA, CNAME, MX, NS, TXT, and other records.

When troubleshooting a specific problem, compare the result from a public recursive resolver with the result from an authoritative server. This can help determine whether the issue is related to cached data or the authoritative configuration itself.

Use Reverse DNS Lookup When Investigating IP Addresses

If you start with an IP address rather than a hostname, a reverse DNS lookup can reveal whether the address has an associated PTR record.

Reverse DNS is useful for network administration, mail-server configuration, infrastructure investigations, and troubleshooting. However, the presence of a PTR record should not automatically be interpreted as proof that the associated hostname is trustworthy.

Check Domain Registration Separately

DNS records and domain registration information are related but different. WHOIS or RDAP information can provide registration and registrar-related data, while DNS queries show the records used for name resolution.

A Whois Lookup can therefore be useful when investigating a domain's registration information, but it does not replace a DNS lookup.

DNS and Ping Are Different

Ping can test network reachability using ICMP, while DNS resolves hostnames into DNS records. A successful DNS lookup does not guarantee that ping will work, and a failed ping does not necessarily mean DNS is broken.

ping example.com

A host may block ICMP while still serving HTTP or HTTPS normally. Conversely, a hostname can resolve correctly while the destination service is unavailable.

DNS Load Balancing

DNS can return multiple addresses for a hostname. Applications and network infrastructure can use this to distribute traffic among multiple endpoints.

www.example.com. 300 IN A 192.0.2.10
www.example.com. 300 IN A 192.0.2.11

DNS-based distribution is not the same as a dedicated load balancer. DNS caching means different clients and resolvers may retain different address sets, and DNS alone does not continuously observe the health of every connection.

DNS Failover

DNS can also be involved in failover systems where different answers are returned depending on endpoint health or other policies. However, cached DNS responses can delay the effect of a change.

For applications requiring rapid failover, DNS should be considered as one component of the architecture rather than assuming that changing a record instantly redirects every client.

DNS-Based Geolocation

Some DNS providers can return different addresses based on the approximate location of the client or recursive resolver. This can help route users toward geographically distributed infrastructure.

Because recursive resolvers can be located differently from end users and because DNS responses can be cached, DNS geolocation is an approximation rather than a perfect representation of the user's physical location.

DNS Security Best Practices

• Use reputable authoritative DNS infrastructure.
• Keep nameserver delegation accurate.
• Protect access to DNS management accounts.
• Use strong authentication and MFA for DNS provider accounts.
• Review DNS records regularly.
• Remove obsolete records.
• Use appropriate TTL values.
• Consider DNSSEC where its operational requirements can be maintained.
• Monitor important DNS changes.
• Protect domain registrar accounts because registrar-level changes can affect nameserver delegation.

Protect the DNS Management Account

DNS records can control where users are directed, so access to the DNS provider and domain registrar should be treated as sensitive administrative access.

An attacker who gains control of a domain's DNS management can potentially redirect traffic, interfere with email, or create misleading verification records. Strong passwords, MFA, limited administrative access, and monitoring are therefore important.

Remove Obsolete DNS Records

Old DNS records can remain after infrastructure has been decommissioned. These records can create confusion and, in some situations, increase the risk of subdomain takeover or accidental exposure.

Review DNS records when services are removed, domains are migrated, cloud resources are decommissioned, or third-party integrations are discontinued.

Choose TTL Values Deliberately

A lower TTL can make planned DNS changes visible sooner to caching resolvers, while a higher TTL reduces the frequency of DNS queries and can provide longer cache persistence.

There is no universally correct TTL. Stable records may use longer caching periods, while records that are expected to change more frequently may use shorter values. The appropriate value depends on the service and operational requirements.

DNS Resolution and CDN Services

Content delivery networks often use DNS as part of their routing architecture. A domain may resolve to CDN infrastructure rather than directly to the origin server.

This means a DNS lookup can show an address belonging to the CDN even though the actual application is hosted somewhere else. This is normal for many modern web architectures.

DNS Resolution in Containers and Cloud Environments

Containers, virtual machines, Kubernetes clusters, and cloud platforms can have their own DNS behavior. Internal service names may resolve through private DNS zones that are not visible from the public internet.

A hostname resolving correctly on a developer's laptop does not necessarily mean it will resolve inside a container or production network. Always consider which DNS resolver and network environment the application is actually using.

DNS Timeouts and Retries

DNS clients and resolvers can retry queries when responses are lost or servers are unavailable. The exact behavior depends on the operating system, resolver implementation, protocol, and network configuration.

Repeated DNS timeouts can indicate network filtering, unreachable DNS servers, overloaded infrastructure, firewall problems, or authoritative server failures. They should be distinguished from an authoritative NXDOMAIN response, which is an explicit DNS result rather than a timeout.

Common DNS Mistakes

• Changing a DNS record and expecting every resolver to update immediately.
• Forgetting to update nameserver delegation.
• Creating an A record when a CNAME is required.
• Pointing a hostname to the wrong IP address.
• Forgetting an AAAA record that sends some clients to the wrong destination.
• Using an unnecessarily short or long TTL without a reason.
• Leaving obsolete records after infrastructure changes.
• Assuming a successful DNS lookup means the web server is healthy.
• Assuming a failed ping proves DNS is broken.
• Ignoring DNSSEC validation failures.
• Confusing recursive resolvers with authoritative nameservers.
• Forgetting that private DNS and public DNS can contain different data.
• Leaving DNS management accounts insufficiently protected.

A Practical DNS Troubleshooting Workflow

When a domain does not resolve as expected, start with the exact hostname and record type involved. A website may have a working A record while a specific subdomain is missing, or an AAAA record may direct IPv6-capable clients to a different destination.

• Confirm the hostname is correct.
• Check the expected record type.
• Query a recursive resolver.
• Query the authoritative nameserver.
• Compare the answers.
• Inspect TTL values.
• Check NS delegation.
• Check A and AAAA records.
• Inspect CNAME chains where applicable.
• Check DNSSEC if enabled.
• Compare results from multiple geographic resolvers.
• Test the destination service independently of DNS.

This approach helps separate DNS problems from application, network, TLS, and server problems. Once the hostname resolves to the expected address, the next debugging layer is usually the connection itself rather than DNS.

Frequently Asked Questions

Helpful DNS Tools

A DNS Lookup tool is useful for inspecting A, AAAA, CNAME, MX, NS, TXT, SOA, and other records. A Reverse DNS Lookup helps investigate PTR records associated with IP addresses, while a DNS Propagation Viewer can compare DNS results across different resolvers or locations. Whois Lookup provides domain registration information that can complement DNS investigation, and a Ping Command Builder can help construct basic connectivity tests after DNS resolution has been verified.

Conclusion

DNS resolution is the process that connects human-readable hostnames with DNS data used by network applications. Although a simple lookup can appear instantaneous, the underlying system is distributed across local caches, recursive resolvers, root servers, TLD infrastructure, and authoritative nameservers.

Caching and TTL values make DNS efficient, but they also explain why changes are not always visible everywhere immediately. Understanding A, AAAA, CNAME, NS, MX, TXT, SOA, and PTR records makes DNS configuration and troubleshooting much easier.

When a hostname does not behave as expected, check the DNS record itself, authoritative servers, delegation, caching, and DNSSEC before assuming the application is broken. Separating DNS problems from network, TLS, and HTTP problems is one of the most useful skills when troubleshooting web infrastructure.