---
{
  "title": "Domain Name System",
  "summary": "Follow a DNS lookup through resolvers, authoritative servers, and caches, and learn why a resolved name is not proof that a service is trustworthy.",
  "topic": "networking",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    2
  ],
  "aliases": [],
  "sources": [
    {
      "title": "IETF: Domain names, concepts and facilities",
      "url": "https://www.rfc-editor.org/rfc/rfc1034.html"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## Names need answers

The Domain Name System, or DNS, provides a distributed naming system. A familiar use is finding address records for a hostname, but DNS supports many record types and purposes. A name can have several answers, and answers can change over time.

For a beginner, distinguish the name typed into an application from the address used to reach a service. [[ip-addressing]] describes delivery addresses. DNS connects naming information to application needs without making the name a permanent identity for one computer.

## Follow a learner's lookup

Imagine a fictional learner opens a training portal. The device asks its configured resolver for information about the portal's hostname. The resolver may already have a usable cached answer. Otherwise, it can follow the naming hierarchy and consult appropriate authoritative servers.

Authoritative servers provide information for the zones they serve. A recursive resolver does the work of obtaining an answer for its client. These roles can be hosted in different places and have different operational responsibilities.

This explains why a working authoritative record does not guarantee that every learner immediately sees the same result. Resolver configuration, caching, network reachability, and the particular query all matter.

![DNS clients ask resolvers, which can answer from cache or consult authoritative infrastructure.](/diagrams/dns-roles.svg)

## Caches explain some surprises

DNS records include time-to-live information that guides how long cached information can be reused. A recent infrastructure change may therefore interact with answers obtained earlier. Troubleshooting should record the query time, resolver, name, record type, and returned information.

Suppose the academy moves a service and one learner still reaches the old address. Repeatedly refreshing the browser does not establish whether the resolver returned an older cached answer, the browser reused an existing connection, or another component retained state. Investigate the relevant layers separately.

## An answer is not a trust decision

A successful lookup does not prove that a website is legitimate or that its application is secure. A misleading domain can resolve correctly. [[tls]] can authenticate a connection endpoint according to certificate and protocol validation, while users still need to identify the service they intended to reach.

DNSSEC and encrypted DNS address different questions: authenticating DNS data and protecting particular communication paths are not interchangeable goals. The presence of one should not be described as solving every naming or privacy risk.

## Use query records with restraint

During an investigation, a DNS query can show that a system or intermediary requested naming information. It does not by itself prove a successful connection, a file transfer, or malicious intent. Caching and shared resolvers also affect what is visible.

For a safe exercise, compare address answers for a domain you control using an authorized resolver. Record the evidence without changing other people's infrastructure. Continue with [[http]] to understand the application exchange and [[network-forensics]] to combine naming records with connection and endpoint evidence.