Lesson
DNS and Name Resolution
Learning objective
Trace recursive name resolution and distinguish stub resolver, recursive resolver, authoritative server, common records, caching, and response codes.
Learning objective
Trace a DNS question through clients, recursive resolvers, referrals, authoritative answers, caching, and transport evidence.
Why name resolution exists
Applications use stable, meaningful names while network delivery uses addresses. DNS is a distributed database that returns the requested kind of information for a name; resolving a name and reaching its service are separate outcomes.
DNS roles and responsibility boundaries
An application asks a local stub resolver. The stub normally requests recursive service from a configured recursive resolver. That resolver uses its cache or contacts root, TLD, and authoritative servers. The stub does not normally walk the hierarchy itself.
Domain labels, zones, and delegation
An absolute name is a sequence of labels ending at the root. A zone is an administratively served portion of that namespace. At a zone cut, parent NS records delegate responsibility; Additional records may carry address glue needed to reach the delegated servers.
Recursive service versus iterative referrals
The client asks its resolver to return a finished result. Upstream, the resolver commonly follows referrals: a root response points toward the TLD, the TLD points toward the child authority, and the authority provides the answer or authoritative negative evidence.
Interactive complete DNS resolution
Compare cold cache, warm cache, aliases, IPv6 records, TCP retry, and an authoritative negative answer. Every step keeps the server role, DNS message, cache decision, and explanation synchronized.
Interactive complete DNS resolution
Active exchange: Stub resolver to Recursive resolver
- Application
- Stub resolverSends
- Recursive resolverReceives
- Root server
- TLD server
- Authoritative server
Step 1 of 4: Application asks its resolver
The stub requests recursive service from its configured resolver.
Evidence: RD=1 and destination UDP 53.
The recursive resolver has no usable answer.
UDP 53000 → 53
| Field | Value | Meaning |
|---|---|---|
| ID | 0x4d2a | Matches a response to its query. |
| QR | Query | Distinguishes a query from a response. |
| OPCODE | 0 | Names the requested operation. |
| AA | 0 | Marks an authoritative answer. |
| TC | 0 | Marks a truncated response. |
| RD | 1 | Requests recursive service. |
| RA | 0 | Reports recursion availability. |
| AD | 0 | Reports authenticated data. |
| CD | 0 | Disables resolver checking for this request. |
| RCODE | NOERROR | Reports the DNS response status. |
| QDCOUNT | 1 | Counts Question entries. |
| ANCOUNT | 0 | Counts Answer records. |
| NSCOUNT | 0 | Counts Authority records. |
| ARCOUNT | 0 | Counts Additional records. |
| Name | Type | Class |
|---|---|---|
| www.example.test. | A | IN |
| Owner | Type | Class | TTL | RDLENGTH | Decoded data | Purpose |
|---|---|---|---|---|---|---|
| No records | ||||||
| Owner | Type | Class | TTL | RDLENGTH | Decoded data | Purpose |
|---|---|---|---|---|---|---|
| No records | ||||||
| Owner | Type | Class | TTL | RDLENGTH | Decoded data | Purpose |
|---|---|---|---|---|---|---|
| No records | ||||||
DNS message and header structure
DNS message format
Swipe sideways to see all fields
| Transaction ID · 16 bits | Flags · 16 bits | ||||||||||
| Question count · 16 bits | Answer count · 16 bits | ||||||||||
| Authority count · 16 bits | Additional count · 16 bits | ||||||||||
| Question section · variable | |||||||||||
| Answer section · variable | |||||||||||
| Authority section · variable | |||||||||||
| Additional section · variable | |||||||||||
The header contains ID, QR, OPCODE, AA, TC, RD, RA, AD, CD, RCODE, and the four section counts QDCOUNT, ANCOUNT, NSCOUNT, and ARCOUNT. The Question, Answer, Authority, and Additional sections have different jobs. A compression pointer changes encoding, not the logical name.
Common record types and selection rules
- A maps an owner to IPv4 data; AAAA carries IPv6 data.
- CNAME aliases one owner to a canonical name and must be followed to useful data.
- NS delegates or identifies authority; SOA identifies a zone and supports negative caching.
- MX selects mail exchangers by preference; TXT stores text interpreted by another convention.
- PTR supplies reverse-lookup data; SRV carries service priority, weight, port, and target.
- CAA expresses certification-authority policy.
Standard CNAME semantics conflict with other data at the same owner, making an ordinary apex CNAME problematic. Provider “flattening” is implementation behavior rather than a wire-level apex CNAME.
UDP 53, TCP 53, EDNS, and encrypted DNS
DNS commonly starts with UDP 53. A response with TC=1 can require TCP 53, and zone transfers use TCP. EDNS advertises extended capabilities and a UDP payload size; larger datagrams can still encounter fragmentation or path failure. DoT, DoH, and DoQ encrypt a particular hop but do not change record meaning, hide queries from the chosen resolver, or equal DNSSEC validation.
Caching, TTL, and negative caching
A resolver may reuse an eligible record while its TTL remains positive. The displayed TTL normally counts down from the stored value. Authoritative negative answers use SOA evidence to bound negative caching. Browser, OS, and recursive-resolver caches are distinct layers and need not expose identical controls.
Response codes and NODATA
NOERROR with requested data is a successful answer. NODATA is NOERROR where the name exists but the requested type is absent. NXDOMAIN says the queried name does not exist. SERVFAIL means the resolver could not produce a valid result, REFUSED declines the operation, and FORMERR reports malformed input. A timeout is transport behavior, not an RCODE.
Reverse DNS
Reverse DNS queries PTR data beneath in-addr.arpa. for IPv4 or ip6.arpa. for IPv6. A PTR answer is separately administered evidence; it does not prove forward resolution, identity, or authorization by itself.
Interactive DNS troubleshooting
Use the packet facts to distinguish NXDOMAIN from NODATA. Submit a prediction before revealing the decisive RCODE, section, and SOA evidence.
Interactive DNS troubleshooting
NXDOMAIN versus NODATA
Observed evidence
- RCODE is NOERROR
- ANCOUNT is 0
- Authority contains the zone SOA
Practical command and capture evidence
nslookup, Resolve-DnsName, and dig show the response returned through a selected resolver; they do not automatically reveal every upstream exchange. In Wireshark begin with dns, then correlate IDs, flags, sections, UDP/TCP ports, timing, and retries. Useful filters include udp.port == 53, tcp.port == 53, and dns.flags.response == 1.
Common DNS misconceptions
DNS does not “convert a URL into an IP”; it answers a typed question about a domain name. Every query does not visit the root because caches retain delegations. An authoritative server need not offer recursion. DNSSEC authenticates DNS data; it does not encrypt queries. A DNS answer does not prove that the application service is healthy.
Summary and next steps
Identify the question, resolver role, transport, flags, response code, four sections, TTL, and cache state. Follow referrals until authority, and separate a DNS response from a timeout or later application failure.
Cold-cache and warm-cache practice
Compare the number of upstream exchanges and remaining TTL. A warm answer is valid only while its cached lifetime remains; a shorter path is evidence of reuse, not proof that authoritative servers disappeared.
Record-selection and delegation practice
Choose the record that answers the actual question: A/AAAA for addresses, CNAME for an alias, MX for mail routing, SRV for service location, PTR for reverse data, and NS/SOA for delegation and authority evidence. Treat glue as reachability help rather than the original final answer.
DNS packet and capture practice
Correlate nslookup, Resolve-DnsName, or dig output with Wireshark fields. Inspect dns.id, QR/AA/TC/RD/RA, RCODE, section counts, TTLs, UDP versus TCP port 53, retransmissions, and elapsed time.
Interactive DNS troubleshooting
NXDOMAIN versus NODATA
Observed evidence
- RCODE is NOERROR
- ANCOUNT is 0
- Authority contains the zone SOA
Knowledge check and summary
Interactive DNS timing diagram
Compare cold and warm caches, delayed authority, truncation with TCP fallback, resolver timeout, and DNSSEC validation. Each event keeps elapsed time and cache state synchronized.
DNS timing diagram
0 ms — Stub query
The recursive resolver receives a new question.
Cache: Miss
Advanced RFC-level DNS checks
Each answer immediately reveals the governing rule, exact evidence, operational consequence, and primary RFC reference.
A UDP DNS response has TC=1. What should the resolver do to obtain the complete answer?
What provides the cache boundary for an authoritative negative answer?
What does an EDNS OPT record advertise?
DNSSEC and advanced Wireshark analysis
Trace the chain DS → DNSKEY → RRSIG and use NSEC/NSEC3 for authenticated denial awareness. DNSSEC authenticates data; it does not encrypt the query. In Wireshark correlate IDs, streams, retransmissions, TC fallback, EDNS OPT data, DNSSEC records, delegation, and timing rather than trusting one flag alone.
DS: The parent zone publishes a digest that identifies the child's trusted key material.
DNSKEY: The child publishes public keys used to validate signatures over its DNS record sets.
RRSIG: A signature covers a record set so a validating resolver can detect unauthorized change.
NSEC/NSEC3: Authenticated denial records prove that a requested name or type does not exist.
Advanced DNS operations and failure boundaries
Diagnose lame or cyclic delegation, missing or unsafe glue, bailiwick boundaries, cache-poisoning defenses, split-horizon answers, conditional-forwarding loops, and anycast path changes. AXFR and IXFR transfer zones over TCP; NOTIFY and dynamic updates have separate authorization and operational risks. EDNS can advertise larger UDP payloads, but fragmentation and path MTU still matter.
Encrypted transports—DoT, DoH, and DoQ—protect specified hops. They do not make the selected resolver blind, guarantee encrypted upstream resolution, or substitute for DNSSEC validation.
Bonus: the trailing root dot and root-server discovery
The final dot makes an FQDN absolute and represents the DNS root. Follow configured root hints to a logical root identity, see how anycast distributes service, then observe referrals and cached delegation. A–M name logical identities, not thirteen physical machines.
How a resolver finds the DNS root
Step 1 of 6: The absolute name. The final dot represents the DNS root, making the FQDN absolute. Resolver software begins with configured root hints.
Primary references: RFC 1034, RFC 1035, RFC 2308, RFC 6891, RFC 7766, RFC 4033, and RFC 8499.