What's changed: Initial version
3.1DNS
Covers the division of roles between authoritative servers and caching (resolving) servers, how zones and delegation partition the domain namespace, resource records such as A/AAAA/MX/CNAME/NS/PTR, the difference between recursive queries and iterative queries, and how to triage DNS failures using forward and reverse lookups.
DNS (Domain Name System) looks like a simple mechanism for resolving domain names to IP addresses, but underneath it embodies two design principles: a hierarchy of authority and a caching mechanism for performance. A network specialist must be able to diagnose which server and which setting is at fault when name resolution fails. This section explores DNS components with an eye toward failure triage.
3.1.1Authoritative servers and caching servers
- An authoritative server holds the official answers for a specific zone. It directly manages the zone file and responds to queries about that domain with "the answer it knows to be correct."
- A caching server (caching DNS server, full-service resolver) queries the chain of authoritative servers on behalf of clients and caches the result for the duration of its TTL (Time To Live) for reuse. Operated by enterprises or ISPs, it reduces load on authoritative servers and speeds up responses.
3.1.2Zones and delegation
- A zone is a segment of the domain namespace managed by an authoritative server. When a single domain (e.g., example.co.jp) needs to be administered across multiple organizations, the parent zone uses an NS record to point to the child zone's authoritative servers—this is delegation.
- If a delegated child zone's authoritative server goes down, only subdomains under that child zone become unresolvable, while the parent zone and sibling zones are unaffected. Failure scope aligns with zone boundaries—a property that follows directly from the delegation structure.
3.1.3Resource records
| Record | Purpose |
|---|---|
| A | Resolves a hostname to an IPv4 address (forward lookup) |
| AAAA | Resolves a hostname to an IPv6 address (forward lookup) |
| MX | Specifies the mail server(s) that accept mail for the domain, with priority |
| CNAME | Aliases a name to another canonical hostname |
| NS | Identifies the authoritative servers for a zone (used for delegation) |
| PTR | Resolves an IP address to a hostname (reverse lookup) |
| TXT | Stores arbitrary text (used for SPF, domain-ownership verification, etc.) |
Most-tested: "MX points to mail servers with a priority value," "CNAME aliases a name to a canonical name and must not coexist with other records like MX or NS at the same name" (an RFC violation if it does), and "PTR is used exclusively for reverse lookups (in-addr.arpa / ip6.arpa zones)." Also note that no other record type may share a name with a CNAME.
3.1.4Recursive and iterative queries
- A recursive query is when a client asks a caching server to "return the final answer." The caching server keeps querying on the client's behalf until it obtains an answer, then returns only the final result to the client.
- An iterative query (non-recursive) is the mode a caching server uses when walking from the root servers to TLD servers to authoritative servers. Each server, if it does not know the answer, merely returns a referral to the next server to ask—it does not guarantee a final answer.
- Forward lookup resolves a hostname to an IP address (via A records, etc.). Reverse lookup resolves an IP address to a hostname (via PTR records, in-addr.arpa zone). A mail server lacking a reverse-lookup entry is often flagged as a spam signal.
Suppose an in-house systems administrator receives multiple reports that "the internal portal (portal.example.co.jp) has been unreachable since this morning." The first question is at which layer name resolution is stalling. The triage sequence: (1) run nslookup portal.example.co.jp from a client machine and check whether the internal caching (DNS) server responds at all; (2) if the query times out, suspect the caching server itself or its reachability to upstream servers; (3) if the caching server responds but returns NXDOMAIN (domain does not exist), suspect that the authoritative server to which the portal subzone is delegated (e.g., the server referenced by the NS record for portal.example.co.jp) is down, or that its A record is misconfigured. If other names such as www.example.co.jp resolve fine while only portal fails, you can infer that the failure is confined to the authoritative server delegated for the portal subzone, not the whole domain, which sharply narrows the investigation. Conversely, if name resolution fails for every internal domain at once, suspect the internal caching server itself or the path from it to upstream servers (the ISP's upstream DNS or root servers). This—working backward from "what scope is affected" to where in the zone hierarchy the fault lies—is the basic method for DNS failure triage.
Trap: "A caching server always responds to clients using iterative queries" is wrong—the typical division of labor is recursive queries between client and caching server, and iterative queries between the caching server and the chain of upstream servers. Also wrong: "it is fine to add another record (e.g., MX) at a node that already has a CNAME"—coexisting records at a CNAME node are not permitted by the specification.
3.1.5Section summary
- An authoritative server holds the official answers for a zone; a caching server reuses results for the TTL duration, reducing load on authoritative servers
- Delegation allows a zone to be split across administrators, and failure scope aligns with zone boundaries for triage
- The basic division: client-to-caching-server uses recursive queries, and caching-server-to-upstream uses iterative queries
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Running `nslookup app.example.co.jp` against the internal DNS caching server returns NXDOMAIN, while `www.example.co.jp` in the same domain resolves normally. Which inference is most reasonable given this situation?
Q2. An administrator set a CNAME record for the name `mail` in a domain, then tried to also register an MX record at the same name `mail`, and the registration failed. What is the most appropriate technical reason for this?
Q3. Which pair correctly describes the query mode used when a caching server walks through root, TLD, and authoritative servers in turn, versus the mode a client uses when asking the caching server?