DNS (Domain Name System)

What it is (Definition)

DNS is the naming system that maps human-friendly names (like example.com) to network information such as IP addresses. Most users experience DNS as “the thing that must work for the internet to feel alive.” When DNS resolution fails, web pages, APIs, and many apps appear broken even if the underlying IP connectivity is fine.

DNS is distributed and hierarchical. Clients usually ask a recursive resolver (often provided by an ISP, enterprise network, or public service). The resolver may query authoritative servers, cache results, and return answers with a time-to-live (TTL) that determines how long they can be reused.

Where it sits in the stack (Layer & usage)

L7 DNS is an application-layer protocol (commonly over UDP and sometimes TCP).

Transport: UDP/53 for most queries; TCP/53 for large responses, zone transfers, or retries.
Used by: Web browsing, email routing, service discovery, and many internal enterprise systems.
Where seen: Client ↔ recursive resolver, resolver ↔ authoritative servers, caches everywhere.

Modern variants also exist: DNS over TLS (DoT) and DNS over HTTPS (DoH) encrypt DNS queries. But classic DNS over UDP/53 remains widespread and is the common focus in packet analysis.

Header overview (Fields at a glance)

DNS messages are structured as a header plus sections: Question, Answer, Authority, and Additional. The header has a transaction ID to match responses to requests and flags that describe query/response behavior.

Field	Size	Purpose	Common values / notes
Transaction ID	2 bytes	Matches response to query	Key for correlating in captures
Flags	2 bytes	Query/response metadata	QR, RD, RA, AA, TC; “NoError”, “NXDOMAIN” in response code
QDCOUNT	2 bytes	Number of questions	Usually 1 for typical client queries
ANCOUNT / NSCOUNT / ARCOUNT	2 bytes each	Counts for sections	Helps spot empty answers vs referrals
Question section	variable	Name/type being asked	A/AAAA/CNAME/TXT and more; includes QNAME, QTYPE, QCLASS
Resource Records	variable	Answers and related data	Includes TTL and RDATA; avoid full value lists here—Fields page later

How it works (Typical flow)

Common resolution path for a browser opening a website:

The client checks local caches (OS, browser, application).
If not cached, it queries a configured recursive resolver (often UDP/53).
The resolver checks its cache; if needed it queries authoritative servers via the DNS hierarchy.
The resolver returns an answer (A/AAAA/CNAME chain, etc.) with TTL values.
The client uses the returned IP address to open TCP/TLS connections to the service.

Caching matters: Many “DNS issues” are really stale caches or inconsistent TTL behavior.
Fallback to TCP: Large responses or truncated UDP replies may trigger TCP retry.

How it looks in Wireshark

Display filter example:

dns

What you typically see:

Standard query/response pairs with matching Transaction ID.
Query names (QNAME) and response codes (NoError, NXDOMAIN).
Answer records (A/AAAA/CNAME), TTL, and additional records (like EDNS0 or OPT records).

Quick read tip: If responses look incomplete, check for truncation (TC flag) and whether the client retries over TCP. Many “mystery” failures are just a client that never successfully performs the TCP fallback.

Common issues & troubleshooting hints

1) NXDOMAIN vs “no data” confusion

Symptom: Name resolution fails for a specific record type (for example, AAAA) but not others. Some applications work while others that prefer IPv6 fail, or logs show repeated attempts to resolve the same name.
Likely cause: The domain itself exists, but the requested record type is missing (“no data”), or resolver policies differ by type (DNS64, filtering, or split-horizon design). From the application’s perspective this can look similar to a full failure.
How to confirm: Inspect the response code (NoError vs NXDOMAIN) and the answer section. Compare A vs AAAA queries for the same name and check whether the resolver returns synthetic or filtered answers for particular types or clients.

2) Slow browsing due to DNS latency

Symptom: First page load is slow while subsequent loads are fast. Users may describe this as “the first click hangs, then everything is fine” or see delays before any TCP connection is attempted.
Likely cause: Cache misses causing recursive resolution, timeouts to an upstream resolver, or path issues between the resolver and authoritative servers. Misconfigured forwarders or overloaded resolvers can add hundreds of milliseconds or more.
How to confirm: Compare query and response timestamps in the capture. Look for repeated queries, retries, or long gaps before responses. Check whether queries are sent to multiple resolvers, and whether one of them consistently responds slower or times out.

3) DNS hijacking / filtering

Symptom: Clients receive unexpected IP addresses, blocked domains resolve to “walled garden” hosts, or search pages appear instead of standard NXDOMAIN errors. Security tools may also flag connections to suspicious or unwanted endpoints.
Likely cause: Captive portals, ISP or enterprise filtering, malware altering DNS settings, or misconfigured DNS forwarding. Some environments intentionally rewrite NXDOMAIN to a search or advertising page, which can confuse troubleshooting.
How to confirm: Compare answers from multiple resolvers (local vs public) for the same names. Look for unusual TTL values, private IP answers for public domains, or consistent rewriting of NXDOMAIN into synthetic responses. Verify the client’s configured DNS servers and whether encrypted DNS is in use.

Security notes (if relevant)

Classic DNS is usually unencrypted and can be observed or modified on the path. DNSSEC can provide authenticity for signed zones, but deployment and validation vary. Encrypted DNS transports (DoT/DoH) protect privacy and integrity on the local path, but they also reduce visibility for network troubleshooting unless you capture at the endpoint before encryption.

Related pages (internal links)

Back to Dictionary Index
Key fields (Field Index) — planned: DNS flags/rcode (Soon), DNS resource record fields (Soon)
Related topics (Topic Index) — planned: NXDOMAIN vs NODATA (Soon), DNS cache behavior (Soon)