DNS and Name Resolution

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

Choose a DNS resolution journey

Cold-cache recursive lookupWarm-cache answerCNAME chainAAAA lookupTruncation and TCP retryNXDOMAIN

Active exchange: Stub resolver to Recursive resolver

1. Application
2. Stub resolverSends
3. Recursive resolverReceives
4. Root server
5. TLD server
6. 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.

Cache: miss

The recursive resolver has no usable answer.

UDP 53000 → 53

DNS header fields

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.

Question entries in this message

Name	Type	Class
www.example.test.	A	IN

Answer records in this message

Owner	Type	Class	TTL	RDLENGTH	Decoded data	Purpose
No records

Authority records in this message

Owner	Type	Class	TTL	RDLENGTH	Decoded data	Purpose
No records

Additional records in this message

Owner	Type	Class	TTL	RDLENGTH	Decoded data	Purpose
No records

PreviousPlayNextRestartPlayback speed 0.5×1×1.5×2×

DNS message and header structure

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

What does the evidence show?

The name exists but has no record of the requested typeThe queried name does not existThe resolver timed out

Check diagnosis

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.