concept Domains & DNS
DNS resolution
Follow a DNS lookup from a device to a recursive resolver and authoritative answer, before any HTTP request begins.
What it means
DNS resolution is the process of finding DNS information for a name. When a browser needs the address of www.example.com, its operating system or browser normally asks a configured recursive resolver for an A or AAAA record. The resolver may already have an unexpired answer, or may consult other DNS servers to obtain one. The answer helps the client decide where to connect; DNS does not fetch the page or perform the HTTPS request. DNS elements DNS terminology
A browser can also use its own cache, a hosts file, or another configured lookup path. The following is the common DNS-server path, deliberately simplified; it is not a trace from a live device.
Try it
Example — follow a first lookup, then a cached lookup. All names and actions below are illustrative, not a live check.
Browser / OS stub -- A? www.example.com --> Recursive resolver
| cache miss
v
Root DNS server
| referral to .com
v
.com server
| delegation referral
v
example.com authority
| A record answer
v
Recursive resolver -- cached A answer --> Browser / OS
Browser -- HTTPS request ---> Web endpoint (separate step)
Later lookup: stub -> same resolver -> valid cache hit -> answerA referral normally tells the resolver which name servers to ask next; the authoritative server for the relevant zone supplies the zone's data. A resolver may already know delegation information, so real queries do not always start at the root or follow every arrow. The complete traversal is a teaching example, not a guarantee of query count or latency. Resolution algorithm
The participants have different jobs
| Participant | Responsibility | Typical outcome |
|---|---|---|
| Client stub | Requests DNS information through a configured interface | Gets answer or error |
| Recursive resolver | Looks up or caches results on the client's behalf | Returns an RRset and TTL or an error |
| Root and parent servers | Point toward delegated child zones | Referral data |
| Authoritative server | Answers for data in a zone it serves | Authoritative RRset or negative answer |
| Web endpoint | Handles HTTP/TLS after address selection | Website response |
The answer is tied to both a name and record type. Asking for AAAA is not identical to asking for A; a name can have one, both, or neither. A CNAME can introduce another name that must be resolved. The DNS response can also be negative: for example, NXDOMAIN means the queried name does not exist according to the answering DNS data and context. Negative answers may be cached. Record format Negative caching
In practice
If a page fails to load, first separate the layers. A DNS error can prevent the browser from finding an address, but a successful DNS response does not prove the server accepts connections, presents a valid TLS certificate or serves the right site. Compare DNS answers for the exact hostname and type before debugging the hosting layer. Do not interpret an IP address from DNS as proof that the site is healthy.
For a focused view of the other participants, see authoritative nameservers and recursive resolvers. DNS TTL explains a single-resolver cache model without pretending to measure worldwide propagation.
Sources & model boundaries
Primary references used for this explanation. The example above is illustrative; it is not a live check.
- RFC 1034 — Domain Names: Concepts and Facilities
Sections 2.4, 3.1, 4.3.2 and 5. DNS tree, zones, referrals, resolvers and caching.
Checked .
- RFC 1035 — Domain Names: Implementation and Specification
Sections 3.2, 3.3 and 4. RR formats, TTL, A, NS, SOA, CNAME and MX records.
Checked .
- RFC 9499 — DNS Terminology
Sections 2–7. Terminology for authoritative servers, recursion, caching, and delegation.
Checked .
- RFC 2308 — Negative Caching of DNS Queries
Sections 3–6. NXDOMAIN and NODATA negative cache behavior and TTL.
Checked .