This chapter covers the DNS resolution process, a fundamental networking concept that appears in roughly 10-15% of N10-009 exam questions across multiple domains. You will learn the exact steps a DNS query takes from client to authoritative server, including caching, recursion, and time-to-live (TTL) values. Mastering DNS resolution is critical because it underpins virtually all network communications, and the exam tests both the theory and practical troubleshooting scenarios.
Jump to a section
Imagine a large company with thousands of employees, each with a unique name but no assigned desk phone number. Instead, every employee has a mobile phone, but the numbers change frequently. To reach someone, you call the company's directory assistance operator. When you ask for 'Bob in Accounting,' the operator checks a constantly updated binder: if Bob is known, they read back his current mobile number. If Bob is unknown, the operator calls a higher-level directory service that covers the entire city. The operator caches recently looked-up names for 60 seconds before re-checking. If the operator is overloaded, calls are queued or redirected to a backup operator. When Bob changes his number, he must update the company directory, which then propagates to the city directory within a day. If the operator is unreachable, your call fails until a backup operator responds. This mirrors DNS: the recursive resolver (operator) queries authoritative servers (city directory) for IP addresses (phone numbers), caches results with TTL timers, and uses redundancy to ensure reliability.
What is DNS Resolution and Why Does It Exist?
DNS (Domain Name System) resolution is the process of translating human-readable domain names (like www.example.com) into machine-readable IP addresses (like 192.0.2.1). This mapping is essential because networks operate on IP addresses, but humans find names easier to remember. DNS is defined in RFC 1034 and RFC 1035, and it uses a hierarchical, distributed database to avoid a single point of failure. The resolution process involves multiple components: the DNS client (stub resolver), the recursive resolver (often provided by ISP or public DNS like 8.8.8.8), root servers, TLD servers, and authoritative name servers.
How DNS Resolution Works Internally
When a user types a URL into a browser, the operating system's stub resolver initiates a DNS query. The process follows these steps:
Check Local Cache: The stub resolver first checks its local DNS cache (maintained by the DNS Client service on Windows or systemd-resolved on Linux). If the record exists and its TTL has not expired, the cached IP is returned immediately—no network traffic occurs.
Check Hosts File: If not cached, the resolver checks the local hosts file (e.g., /etc/hosts on Linux, C:\Windows\System32\drivers\etc\hosts on Windows). This file contains static mappings that override DNS. If a match is found, that IP is used.
Query the Recursive Resolver: If no local record exists, the stub resolver sends a recursive query to the configured DNS resolver (e.g., 192.168.1.1 from DHCP, or 8.8.8.8). The recursive resolver is responsible for performing the full resolution on behalf of the client.
Root Server Query: The recursive resolver sends a query to one of the 13 root server clusters (e.g., a.root-servers.net). The root server responds with a referral to the appropriate Top-Level Domain (TLD) server (e.g., .com, .org). Root servers do not contain domain-specific records; they only know where to find TLD servers.
TLD Server Query: The recursive resolver queries the TLD server (e.g., for .com, it queries a.gtld-servers.net). The TLD server responds with a referral to the authoritative name server for the domain (e.g., ns1.example.com).
Authoritative Server Query: The recursive resolver queries the authoritative name server for the domain. This server holds the actual DNS resource records (A, AAAA, CNAME, MX, etc.). It responds with the requested record (e.g., A record 192.0.2.1).
Response to Client: The recursive resolver caches the response according to the TTL and returns the IP address to the stub resolver. The stub resolver also caches the result locally.
Connection Establishment: The client uses the obtained IP address to initiate a TCP connection (e.g., HTTP over port 80 or HTTPS over port 443) to the target server.
Key Components, Values, Defaults, and Timers
Resource Records (RR): DNS stores data in resource records. Common types include:
- A: IPv4 address (32-bit) - AAAA: IPv6 address (128-bit) - CNAME: Canonical name (alias) - MX: Mail exchange server - NS: Name server - PTR: Pointer record (reverse DNS) - SOA: Start of Authority (contains zone parameters) - TXT: Text record (often used for SPF, DKIM)
TTL (Time to Live): A 32-bit value in seconds that tells resolvers how long to cache a record. Default TTLs vary: common values are 300 (5 minutes), 3600 (1 hour), or 86400 (24 hours). The SOA record has a minimum TTL field used for negative caching (NXDOMAIN).
Port Numbers: DNS uses UDP port 53 for standard queries and responses. If the response exceeds 512 bytes (or 4096 bytes with EDNS0), it falls back to TCP port 53. Zone transfers (AXFR/IXFR) always use TCP.
Recursion Desired (RD) Flag: Set by the client to request recursive resolution. The recursive resolver processes the query fully. If not set, the resolver returns referrals only.
Recursion Available (RA) Flag: Set by the resolver to indicate it supports recursion.
Negative Caching: If a domain does not exist (NXDOMAIN), the resolver caches the negative response for a period defined by the SOA minimum TTL (default often 300 seconds).
Root Hints: A file containing the IP addresses of the root servers. Recursive resolvers use this to bootstrap the resolution process.
Configuration and Verification Commands
On Windows:
- ipconfig /displaydns – shows local DNS cache
- ipconfig /flushdns – clears local DNS cache
- nslookup – interactive DNS lookup tool
- nslookup www.example.com – returns A record
- nslookup -type=MX example.com – returns MX record
On Linux:
- systemd-resolve --statistics – shows DNS cache stats (systemd-resolved)
- systemd-resolve --flush-caches – flushes cache
- dig www.example.com – detailed DNS query
- dig +short www.example.com – short output
- dig @8.8.8.8 www.example.com – query a specific resolver
- dig -t MX example.com – query MX record
- host www.example.com – simple lookup
- nslookup – also available on Linux
How DNS Interacts with Related Technologies
DHCP: DHCP servers typically provide DNS server addresses (option 6) to clients. Without a proper DNS server, name resolution fails.
HTTP/HTTPS: Before any HTTP request, the browser performs a DNS lookup. Tools like curl --resolve can bypass DNS.
VPN: DNS queries may be routed through the VPN tunnel or split-tunnel. Misconfigured DNS can cause domain resolution failures.
IPv6: AAAA records are used for IPv6. If a client prefers IPv6, it queries AAAA first; if no AAAA record exists, it falls back to A.
DNSSEC: Adds cryptographic signatures to DNS responses to prevent spoofing. Resolvers validate signatures using RRSIG and DNSKEY records.
EDNS0: Extension Mechanisms for DNS (RFC 6891) allows larger UDP payloads (up to 4096 bytes) and supports DNSSEC.
Common Resolution Failures
NXDOMAIN: Domain does not exist. Causes: typo in domain name, expired domain.
SERVFAIL: Server failure. Causes: authoritative server down, DNSSEC validation failure.
REFUSED: Query refused. Causes: resolver not configured to answer for that domain.
Timeout: No response. Causes: firewall blocking UDP 53, resolver overloaded.
Caching: Stale cache can return old IP addresses after a server migration. Flush cache or wait for TTL to expire.
Client cache and hosts file check
The operating system's stub resolver first checks the local DNS cache for the requested domain. On Windows, this cache is managed by the DNS Client service; on Linux, by systemd-resolved or nscd. If a matching record is found and its TTL has not expired, the IP is returned immediately—this is the fastest path. If not cached, the resolver checks the local hosts file (e.g., /etc/hosts). This file provides static mappings that override DNS; it is often used for local development or to block malicious sites. If a match is found there, the corresponding IP is used without further queries. Only if both cache and hosts file miss does the resolver proceed to query a remote DNS server.
Recursive query to configured resolver
The stub resolver sends a recursive query (RD flag set) to the DNS server configured in the network interface settings, typically obtained via DHCP. The default port is UDP 53. The query contains the domain name and requested record type (usually A or AAAA). The resolver must support recursion; if it does not, it returns a referral. Common public resolvers include Google (8.8.8.8), Cloudflare (1.1.1.1), and ISP-provided resolvers. The resolver will either have the answer cached or will begin the iterative resolution process. If the resolver is unreachable, the stub resolver may try alternative DNS servers (if multiple are configured) or fail with a timeout.
Root server referral
If the recursive resolver does not have the answer cached, it queries a root server. There are 13 root server clusters (named A through M), each with multiple instances worldwide using anycast. The resolver uses root hints (a list of root server IPs) to initiate the query. The root server does not contain the requested domain's record; instead, it responds with a referral to the appropriate TLD server (e.g., for .com, it returns the list of .com TLD servers). This referral includes NS records and glue records (A/AAAA records for the TLD servers) to enable the next query. The resolver caches this referral for the TTL specified in the root server response.
TLD server referral
The recursive resolver then queries one of the TLD servers obtained from the root referral. For generic TLDs like .com, .org, .net, these are operated by registries such as Verisign. The TLD server does not have the actual domain record; it responds with a referral to the authoritative name servers for the requested domain (e.g., ns1.example.com, ns2.example.com). This referral includes NS records and glue records for the authoritative servers. The resolver caches this information. If the TLD server is unresponsive, the resolver tries another TLD server from the list.
Authoritative server response
The recursive resolver queries the authoritative name server for the domain (e.g., ns1.example.com). This server holds the zone file containing the actual resource records. It responds with the requested record (e.g., an A record with IP 192.0.2.1) along with a TTL value. The resolver caches this response for the duration of the TTL. If the record does not exist, the server returns NXDOMAIN (non-existent domain) or a referral to a subdomain. The resolver then returns the final answer to the client's stub resolver, which also caches it locally. The client can now use the IP address to establish a connection.
Client uses IP for connection
After receiving the IP address from the stub resolver, the client application (e.g., web browser) initiates a TCP connection to that IP on the appropriate port (e.g., port 80 for HTTP, 443 for HTTPS). The DNS resolution is complete. If the connection fails, the client may attempt to resolve the domain again (using a different record type or resolver) or display an error. The entire resolution process typically completes in milliseconds. Caching at multiple levels (browser, OS, recursive resolver) reduces latency for subsequent requests.
In enterprise networks, DNS resolution is critical for both internal and external name resolution. Consider a large corporation with an internal Active Directory domain (ad.example.com). Internal DNS servers are authoritative for ad.example.com and host records for all domain-joined computers, printers, and servers. When a client wants to access a file server (fileserver.ad.example.com), the stub resolver queries the internal DNS server, which returns the private IP address (e.g., 10.0.1.50). The internal DNS server may also be configured to forward queries for external domains to an ISP or public resolver (e.g., 8.8.8.8) to reduce load and leverage caching. This scenario is common in hybrid environments where on-premises and cloud resources coexist. Misconfiguration, such as a missing forwarder or incorrect delegation, can cause internal clients to fail resolving external domains or vice versa.
Another scenario is a web hosting company that manages hundreds of domains. They run authoritative DNS servers (e.g., ns1.hostingcompany.com) that host zone files for customer domains. Each zone has SOA, NS, A, MX, and TXT records. When a customer changes their web server IP, the administrator updates the A record and lowers the TTL (e.g., 300 seconds) before the change to speed up propagation. After the change, the TTL is raised back to 86400 seconds to reduce query load. If the TTL is not lowered, customers may experience downtime while old cached records persist. The company also uses secondary DNS servers for redundancy and anycast to distribute query load globally.
A third scenario involves a cloud-native startup using Amazon Route 53 for DNS. They have a web application with a CNAME record pointing to an Elastic Load Balancer (ELB). The application also uses DNS-based failover with health checks: if the primary endpoint fails, Route 53 returns the secondary endpoint's IP. The TTL is set to 60 seconds to allow quick failover. During a traffic spike, the resolver handles thousands of queries per second, but Route 53's anycast network distributes the load. A common mistake is setting too high a TTL (e.g., 86400), which delays failover and causes prolonged outages for users.
The N10-009 exam (Objective 1.3) tests your understanding of the DNS resolution process, including the order of steps, caching behavior, and common record types. You must be able to describe the flow from client to authoritative server and identify where failures occur. Expect questions that ask: 'What is the first step a client takes when resolving a domain name?' (Answer: check local cache). Another common question: 'Which server is queried after the root server?' (Answer: TLD server). The exam loves to test the difference between recursive and iterative queries—know that the client sets the RD flag to request recursion.
Common wrong answers: - 'The client queries the authoritative server directly' – Incorrect; the client queries a recursive resolver, which then queries authoritative servers. - 'The root server returns the IP address for the domain' – Incorrect; root servers only return referrals to TLD servers. - 'DNS always uses TCP port 53' – Incorrect; DNS primarily uses UDP; TCP is used for zone transfers and large responses. - 'TTL is the time it takes for a query to complete' – Incorrect; TTL is the time a record can be cached. - 'The hosts file is checked after the DNS cache' – Incorrect; hosts file is checked before the cache on some systems (e.g., Linux), but on Windows, cache is checked first. The exam may test the order: typically, cache -> hosts file -> DNS server.
Specific numbers to memorize: UDP port 53, default TTL values (300, 3600, 86400 seconds), 13 root server clusters, negative caching TTL from SOA minimum field. Edge cases: the exam may ask about what happens when a resolver does not support recursion (returns referral) or when a query exceeds 512 bytes (falls back to TCP). Also, understand that DNSSEC validation can cause SERVFAIL if signatures are invalid.
How to eliminate wrong answers: If an answer mentions the root server returning an IP address, eliminate it. If it says DNS uses TCP exclusively, eliminate it. If it claims the client queries the authoritative server directly, eliminate it. Focus on the hierarchical, iterative process with caching at each level.
DNS resolution follows a hierarchical order: local cache, hosts file, recursive resolver, root server, TLD server, authoritative server.
Root servers do not store domain records; they only direct to TLD servers.
DNS primarily uses UDP port 53; TCP port 53 is used for zone transfers and large responses (over 512 bytes without EDNS0).
TTL values determine how long a record is cached; common defaults are 300, 3600, or 86400 seconds.
Negative caching (NXDOMAIN) uses the SOA minimum TTL field, often 300 seconds.
The recursive resolver caches referrals and answers to speed up subsequent queries.
Common DNS failure codes: NXDOMAIN (domain does not exist), SERVFAIL (server failure), REFUSED (query refused), timeout (no response).
The hosts file provides static overrides and is checked after the local DNS cache on most systems.
DNSSEC uses RRSIG and DNSKEY records to validate responses; validation failure results in SERVFAIL.
Anycast is used by root and many public resolvers to distribute query load and improve redundancy.
These come up on the exam all the time. Here's how to tell them apart.
Recursive Query
Client sets RD flag to 1, requesting full resolution.
Resolver takes full responsibility; returns final answer or error.
Resolver may query multiple servers (root, TLD, authoritative).
Commonly used by stub resolvers in end-user devices.
Reduces client complexity but increases resolver load.
Iterative Query
Client does not set RD flag (or sets to 0).
Resolver returns referrals (next server to query) instead of final answer.
Client must follow referrals and query each server itself.
Used in server-to-server communication (e.g., zone transfers).
Shifts resolution burden to client; less common in user-facing scenarios.
Mistake
DNS queries always go directly to the authoritative server.
Correct
Clients do not query authoritative servers directly; they query a recursive resolver (e.g., ISP or public DNS) which performs the iterative process on behalf of the client.
Mistake
The root server contains IP addresses for all domains.
Correct
Root servers only contain referrals to TLD servers; they do not store domain-level records.
Mistake
DNS always uses TCP port 53.
Correct
Standard DNS queries use UDP port 53. TCP is used only when the response exceeds 512 bytes (or with EDNS0, 4096 bytes) or for zone transfers.
Mistake
TTL is the time it takes for a DNS query to complete.
Correct
TTL (Time to Live) is the duration in seconds that a resolver can cache a DNS record before it must be refreshed.
Mistake
The hosts file is checked after the DNS cache.
Correct
On most systems, the local DNS cache is checked first, then the hosts file. However, the exact order can vary by OS; the exam typically tests the standard order: cache -> hosts file -> DNS server.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The first step is checking the local DNS cache maintained by the operating system's stub resolver. If the requested domain record is cached and its TTL has not expired, the IP address is returned immediately without any network traffic. If not found, the resolver then checks the hosts file. Only after both local sources fail does the resolver send a query to the configured DNS server.
In a recursive query, the client sets the RD flag to 1, and the DNS resolver takes full responsibility for resolving the domain, returning either the final answer or an error. The resolver may query multiple servers (root, TLD, authoritative) on behalf of the client. In an iterative query, the client does not request recursion; the resolver returns a referral to the next server in the hierarchy, and the client must query that server itself. Recursive queries are typical for end-user devices, while iterative queries are used between servers.
DNS uses UDP by default because it is faster and lower overhead for small queries. However, if the response exceeds 512 bytes (or 4096 bytes with EDNS0 support), DNS falls back to TCP to ensure reliable delivery of the larger payload. Additionally, zone transfers (AXFR/IXFR) always use TCP to guarantee data integrity. TCP is also used when the resolver is configured to use TCP for all queries (e.g., for security reasons).
TTL (Time to Live) is a 32-bit value in seconds that tells DNS resolvers how long to cache a resource record before it must be discarded and re-queried. For example, a TTL of 3600 means the record can be cached for one hour. TTLs balance freshness and caching efficiency; low TTLs (e.g., 300) are used for records that change frequently (e.g., during migrations), while high TTLs (e.g., 86400) reduce query load for stable records.
NXDOMAIN (Non-Existent Domain) is a DNS response code indicating that the queried domain name does not exist. This can happen if the user typed the wrong domain, the domain has expired, or the DNS records have been deleted. The recursive resolver caches the negative response for a period defined by the SOA minimum TTL (often 300 seconds) to avoid repeated queries for the same non-existent domain.
DNS caching stores previously resolved domain-to-IP mappings at multiple levels: the browser, operating system, and recursive resolver. By reusing cached records, subsequent queries for the same domain are answered instantly without traversing the DNS hierarchy. This reduces latency, decreases network traffic, and offloads authoritative servers. The TTL value controls how long the cache is valid; stale caches can cause issues if IP addresses change before the TTL expires.
Glue records are A or AAAA records that provide the IP addresses of authoritative name servers when those servers are within the same domain as the queried domain. For example, if the authoritative server for example.com is ns1.example.com, the TLD server must include an A record for ns1.example.com in its referral response; otherwise, a resolver would encounter a circular dependency (it needs to resolve ns1.example.com but that domain's server is itself). Glue records break this cycle.
You've just covered DNS Resolution Process — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?