DNS Process

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.

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.

CheckWhy 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.

CheckWhat 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.

CheckWhat 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.

CheckWhat 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.

CheckWhat does DNSSEC validation not provide?

Summary

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.

Practice

Watch the first step of name resolution happen. Add a name of your own to /etc/hosts, then resolve it. In the practice terminal, run: echo '127.0.0.1 myapp.test' >> /etc/hosts getent hosts myapp.test getent should print 127.0.0.1 myapp.test: the resolver found it in /etc/hosts, so it never needed DNS.

Use >> to append; a single > would replace the whole /etc/hosts file.