DNS Resolution: How Names Become IP Addresses

What DNS Resolution Does (and What It Does Not)

DNS (Domain Name System) resolution is the process of translating a human-friendly domain name (like api.example.com) into an IP address (like 203.0.113.10 for IPv4 or 2001:db8::10 for IPv6). Computers route packets to IP addresses, not to names, so DNS is the “phone book” layer that makes names usable on the network.

DNS resolution is separate from making an HTTP request. DNS only answers questions like “What IP should I connect to for this name?” It does not fetch web pages, negotiate TLS, or decide which URL path you want. It also does not guarantee that the returned IP is reachable or that the service is healthy; it only provides records according to the DNS zone configuration and the resolver’s view of the world.

Key Actors in DNS Resolution

Stub Resolver (Your Device)

Your operating system typically includes a “stub resolver.” Applications ask it to resolve a name, and it forwards the question to a recursive resolver (usually configured via DHCP, router settings, or enterprise policy). The stub resolver may also maintain a small cache.

Recursive Resolver (Caching Resolver)

A recursive resolver performs the heavy lifting: it queries other DNS servers on your behalf, caches results, follows referrals, and returns a final answer. Examples include resolvers run by ISPs, enterprises, or public services. This is the component that usually performs “recursion” (walking the DNS hierarchy) and caching.

Root Name Servers

Root servers are the starting point for the public DNS hierarchy. They don’t know the IP for www.example.com, but they know where to find the authoritative servers for top-level domains (TLDs) like .com, .org, and country codes.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

TLD Name Servers

TLD servers (for example, for .com) provide referrals to the authoritative name servers for a specific domain (like example.com).

Authoritative Name Servers

Authoritative servers host the DNS zone for a domain and provide the final answers for records in that zone (or delegate to child zones). They are the source of truth for that domain’s DNS data.

DNS Records You’ll See in Web Server Setups

DNS stores different record types. For web services, these are the most common:

• A: Maps a name to an IPv4 address.

• AAAA: Maps a name to an IPv6 address.

• CNAME: Alias from one name to another name (the target must resolve to A/AAAA or other usable records). Example: www.example.com CNAME example.com.

• NS: Delegates a zone (or indicates authoritative servers for a zone). Example: example.com has NS records pointing to ns1.dnsprovider.net, ns2.dnsprovider.net.

• SOA: “Start of Authority” record describing zone metadata (primary server, serial number, timers). Important for zone transfers and cache behaviors.

• MX: Mail routing (not used for web traffic, but often present).

• TXT: Arbitrary text; commonly used for domain verification, SPF/DKIM/DMARC, and some security policies.

• SRV: Service discovery (less common for basic websites, common in some internal systems).

For a typical website, the critical path is usually A/AAAA (or CNAME leading to A/AAAA).

The Hierarchical Nature of DNS Names

DNS is hierarchical. The fully qualified domain name (FQDN) ends with a dot that represents the root, even if you don’t type it. For example, www.example.com. is the absolute name. The hierarchy is read right-to-left: root (.) → TLD (com) → domain (example) → subdomain (www).

This hierarchy enables delegation: example.com can delegate api.example.com to different authoritative servers, or keep it within the same zone.

Step-by-Step: What Happens When You Resolve a Name

Assume your browser needs to connect to api.example.com. Here is a practical, step-by-step view of a typical resolution path.

1) Application Asks the OS to Resolve

The application calls the OS resolver APIs (for example, getaddrinfo()). The OS stub resolver checks local sources first, which may include:

• Its own DNS cache (if enabled).

• Static mappings like /etc/hosts (Linux/macOS) or C:\Windows\System32\drivers\etc\hosts (Windows).

• Local network naming systems (in some environments), before or alongside DNS depending on configuration.

If it can’t answer locally, it forwards the query to a configured recursive resolver.

2) Stub Resolver Sends a Query to a Recursive Resolver

The stub resolver sends a DNS query (often UDP port 53) to a recursive resolver IP address. The query asks for a record type (commonly A and/or AAAA) for api.example.com.

Many clients request both A and AAAA to support IPv4 and IPv6. Some systems perform “Happy Eyeballs” behavior: they may try IPv6 and IPv4 in parallel or with a slight delay to reduce connection latency.

3) Recursive Resolver Checks Its Cache

The recursive resolver first checks whether it already has a valid cached answer. If so, it returns it immediately. Caching is central to DNS scalability and performance.

If it does not have the answer, it begins iterative queries through the DNS hierarchy.

4) Resolver Queries a Root Server

The resolver asks a root server: “Where can I find information about api.example.com?” The root server does not return the final IP. It returns a referral: a list of TLD name servers for .com, along with “glue” A/AAAA records when needed so the resolver can reach those TLD servers.

5) Resolver Queries a TLD Server

The resolver queries a .com TLD server: “Where are the authoritative name servers for example.com?” The TLD server responds with NS records for example.com (for example, ns1.dnsprovider.net, ns2.dnsprovider.net) and often includes glue records if the NS names are within a domain that requires them for reachability.

6) Resolver Queries the Authoritative Server for the Domain

Now the resolver asks one of the authoritative servers for example.com: “What is the A record for api.example.com?” (and similarly for AAAA).

The authoritative server responds in one of several ways:

• Direct answer: It returns an A/AAAA record for api.example.com.

• CNAME chain: It returns a CNAME like api.example.com → api.edge-provider.net. The resolver must then resolve the target name, potentially involving additional authoritative servers.

• Delegation: It returns NS records delegating api.example.com (or a subzone like api.example.com) to different authoritative servers. The resolver follows that delegation and continues.

• Negative answer: It returns NXDOMAIN (name does not exist) or NODATA (name exists but not that record type). These can also be cached.

7) Resolver Returns the Final Answer and Caches It

The recursive resolver returns the final IP address(es) to the stub resolver, and caches the result for the duration of the record’s TTL (time to live). The stub resolver may also cache it.

From the application’s perspective, it receives one or more IP addresses and can proceed to connect to one of them.

TTL and Caching: Why DNS Changes Take Time

Every DNS record has a TTL, expressed in seconds. TTL controls how long resolvers are allowed to cache the answer. A TTL of 300 means “cache for 5 minutes.” A TTL of 86400 means “cache for 24 hours.”

When you change a DNS record, you are updating the authoritative source of truth, but many resolvers may still be using cached data until their TTL expires. This is why DNS changes can appear to “propagate” gradually.

Practical Guidance for TTL Planning

• Before a planned migration: Lower TTL (for example, from 3600 to 300) at least one TTL period in advance, so caches refresh more quickly when you switch IPs.

• After the migration stabilizes: Raise TTL again to reduce query volume and improve cache hit rates.

• Don’t set TTL too low by default: Very low TTLs can increase load on authoritative servers and may not improve real-world behavior as much as expected (some resolvers apply minimum caching policies).

CNAMEs, Aliases, and Common Web Patterns

CNAME records are widely used to point a friendly name to a provider-managed hostname. For example, you might configure:

• www.example.com CNAME example.com

• app.example.com CNAME myapp.hosting-provider.net

When a resolver encounters a CNAME, it must resolve the target name. This can add extra DNS lookups and latency, especially if the target is not cached.

Important Constraints

• A CNAME generally cannot coexist with other record types at the same name (for example, you typically can’t have both a CNAME and an A record for app.example.com).

• Some DNS providers offer “ALIAS” or “ANAME” pseudo-records at the zone apex (like example.com) to behave like a CNAME while still allowing other records. This is provider-specific behavior, not a standard DNS record type.

Multiple IPs, Load Balancing, and Geo Behaviors

A single name can resolve to multiple IP addresses. This is common when you run multiple servers or use a load balancer fleet. DNS can return several A/AAAA records in one answer.

Round-Robin DNS

With “round-robin,” the authoritative server returns multiple IPs and may rotate their order. Clients often try the first IP first, so rotation can spread load somewhat, but it is not a full load balancer: it does not perform health checks, and clients may cache results.

GeoDNS and Latency-Based Answers

Some DNS providers return different answers based on the resolver’s location (or perceived location). This can direct users to a nearby region. Note that the decision is often based on the recursive resolver’s IP, not the end user’s IP, which can produce surprising results in corporate networks or with certain public resolvers.

Negative Caching: Caching “Not Found”

DNS can cache negative results too. If a resolver receives NXDOMAIN for missing.example.com, it may cache that response for a period defined by the zone’s SOA record (the negative caching TTL). This reduces repeated queries for nonexistent names but can also cause confusion if you create a record shortly after users have cached NXDOMAIN.

DNS Transport Details That Affect Reliability

UDP vs TCP

Most DNS queries use UDP for speed. If a response is too large or requires reliability, DNS can fall back to TCP. Larger responses can occur with DNSSEC, many records, or large TXT records.

EDNS(0) and Response Size

EDNS(0) extends DNS to support larger UDP payloads. Without it, responses may be truncated, forcing TCP retries. Misconfigured firewalls that block DNS over TCP can cause intermittent resolution failures.

DNS over TLS (DoT) and DNS over HTTPS (DoH)

Some clients and networks use encrypted DNS transports (DoT/DoH) to protect DNS queries from passive observation and some forms of tampering. This changes the path (queries go to a DoT/DoH endpoint) but the logical resolution process and caching concepts remain similar.

Hands-On: Inspecting DNS Resolution from the Command Line

Being able to observe DNS answers is essential when debugging web server reachability. The following tools show what resolvers return and help you see CNAME chains, TTLs, and which server answered.

Using dig (Linux/macOS, and available on Windows via packages)

Query A records:

dig A api.example.com

Query AAAA records:

dig AAAA api.example.com

Show the full resolution path (iterative trace from root to authoritative):

dig +trace api.example.com

Query a specific resolver (useful to compare ISP vs public resolver):

dig @1.1.1.1 api.example.com

Using nslookup (widely available)

nslookup api.example.com

Specify a resolver:

nslookup api.example.com 8.8.8.8

Using host (simple output)

host api.example.com

Interpreting Common Output Fields

• ANSWER SECTION: The records you asked for (A/AAAA/CNAME) and their TTLs.

• AUTHORITY SECTION: NS records indicating delegation or authoritative info.

• ADDITIONAL SECTION: Extra helpful records (often glue A/AAAA for name servers).

• status: NOERROR: Query succeeded (even if there is no data for that type).

• status: NXDOMAIN: Name does not exist.

Practical Step-by-Step: Debugging “Site Not Reachable” with DNS Checks

When a user reports that a domain “doesn’t work,” DNS is one of the first layers to verify. Here is a practical sequence that isolates common DNS issues without mixing in HTTP/TLS details.

1) Confirm the Name Resolves at All

Check whether you get an IP address:

dig A yourname.example.com

If you get NXDOMAIN, the record is missing or you’re querying the wrong domain. If you get NOERROR but no A/AAAA answers, you may have a record type mismatch (for example, only AAAA exists but the client is IPv4-only, or vice versa).

2) Check Both A and AAAA

Dual-stack issues are common:

dig A yourname.example.com; dig AAAA yourname.example.com

If AAAA exists but points to an unreachable IPv6 address, some clients may experience delays or failures depending on their fallback behavior. If only AAAA exists, IPv4-only networks will fail.

3) Look for CNAME Chains and Validate the Target

If the answer includes a CNAME, resolve the target name too:

dig yourname.example.com

Then:

dig A target.provider.net

A broken CNAME target (NXDOMAIN) will break the original name as well.

4) Compare Answers from Different Resolvers

Sometimes the authoritative data is correct but a resolver has stale cache or a filtering policy. Compare:

dig @8.8.8.8 yourname.example.com; dig @1.1.1.1 yourname.example.com

If answers differ, check TTLs and whether you recently changed records. Also consider split-horizon DNS (internal vs external views) if you’re in a corporate environment.

5) Verify Authoritative Servers Directly

Identify authoritative name servers:

dig NS example.com

Then query one directly:

dig @ns1.dnsprovider.net yourname.example.com

If the authoritative server returns the expected record but public resolvers do not, caching or propagation timing is likely. If the authoritative server does not return it, the zone is misconfigured or you edited the wrong DNS provider/zone.

6) Check TTL Expectations Against Your Change Timeline

If you changed an A record from IP1 to IP2 and TTL is 3600, some users may still see IP1 for up to an hour (or longer if intermediate caches ignore TTLs). Plan changes accordingly, and avoid repeatedly flipping records during an incident unless you understand the caching impact.

Delegation and Subdomains: When DNS Zones Split

Organizations often delegate subdomains to different teams or providers. For example, example.com might be managed by one DNS provider, while dev.example.com is delegated to another. Delegation is done with NS records at the parent zone.

In practice, this means:

• The parent zone (example.com) contains NS records for dev.example.com.

• The child zone (dev.example.com) must exist on the delegated authoritative servers and contain its own SOA and records.

• If delegation is misconfigured (wrong NS names, missing glue when required, or child zone not created), resolution for names under that subdomain will fail.

Glue Records: Solving the “Chicken-and-Egg” Problem

Glue records are A/AAAA records provided in a parent zone to help resolvers reach a child zone’s name servers when those name servers are within the child zone itself.

Example scenario: You want example.com to be served by ns1.example.com and ns2.example.com. A resolver trying to reach ns1.example.com would need to resolve ns1.example.com, but that information is inside the example.com zone—creating a loop. The parent (TLD) provides glue IPs for ns1.example.com and ns2.example.com so resolvers can contact them.

Glue is managed at the delegation point (often via the domain registrar for public domains). Misconfigured glue can cause intermittent or total resolution failures depending on resolver behavior and cached data.

DNSSEC in One Practical Picture (Integrity, Not Privacy)

DNSSEC adds cryptographic signatures to DNS data so resolvers can validate that answers have not been tampered with and truly come from the zone’s authoritative servers. It does not encrypt queries; it provides integrity and authenticity.

In practice, DNSSEC introduces additional records (like DNSKEY and DS) and larger responses. If DNSSEC is partially misconfigured (for example, DS record at the parent doesn’t match the child zone keys), validating resolvers will treat answers as bogus and fail resolution, even though non-validating resolvers might still work. This can look like “some users can reach the site, others cannot.”