A normal application asks the operating system's stub resolver, which consults local name-service policy and sends a recursive query to a configured resolver. The recursive resolver performs the hierarchy walk only when valid cache does not already answer the question.
DNS · Lesson 3
DNS Process
Learn how a stub and recursive resolver use cache, referrals, glue, and authority to answer a DNS query.
Starting with Local Policy and Cache
The system resolver can consult /etc/hosts, DNS, and other sources in the configured order. Search suffixes can transform a short name into several candidate names. A recursive resolver then checks positive and negative cache entries before sending upstream traffic.
Why might a recursive resolver not contact any authoritative server for a query?
Querying a Root Server
On a cache miss, a recursive resolver can ask a root server. The DNS root has 13 named server identities, A through M, served by many physical instances using anycast and other resilient deployment techniques. The response normally refers the resolver to authoritative servers for the relevant top-level domain rather than returning the final host address.
What does a root server normally return for an uncached www.example.com lookup?
Following TLD and Authoritative Referrals
The resolver asks a com authoritative server, which returns the delegated authoritative name servers for example.com. The referral can include glue address records when needed to reach a server whose name lies inside the delegated child. The resolver then queries an authoritative server for the requested record.
What problem does DNS glue help solve?
Following Aliases and Record Types
An answer can contain a CNAME alias requiring another name lookup, or application-specific records that lead to more queries. Asking for A returns only IPv4-address records and related chain data; a separate AAAA query retrieves IPv6 addresses. The final response carries a status such as NOERROR, NXDOMAIN, or SERVFAIL, each with different meaning.
What does NXDOMAIN report?
Validation, Caching, and Application Use
A validating recursive resolver can use DNSSEC signatures and the chain of trust to verify authenticated denial or record integrity. DNSSEC does not encrypt queries or prove that the application at the returned address is trustworthy.
The resolver caches results within TTL rules and returns them to the stub. The application then chooses an address and attempts its own network and security protocols.
What does DNSSEC validation not provide?
Lesson complete
You finished DNS Process
You can now trace a recursive DNS lookup from local policy to a cached final response.
Check local sources and resolver cache first.
Follow root and top-level-domain referrals.
Use glue to reach appropriate delegated servers.
Distinguish aliases, no-data answers, and nonexistent names.
Separate DNSSEC integrity from transport confidentiality.
Keep your learning progress
Create a free account to save this lesson and continue learning on any device.
Create a free account