DNS Analysis in a PCAP: A Defender's Guide
How to read DNS in a packet capture: queries and responses, result codes, rare and random-looking domains, and high-level signs of DNS tunnelling, with limits.
TL;DR. DNS is the best first stop in almost any capture: it is small, mostly unencrypted, and it tells you what every host intended to reach. Start by identifying the resolvers, then read the queried names, their result codes and answers, and tie answers to the conversations that follow. Watch for names looked up only once, bursts of NXDOMAIN for random-looking names, and many long, unique subdomains under a single domain. Those patterns point at domain generation algorithms and DNS tunnelling, but CDNs, security products and browsers produce look-alikes, so treat them as leads to confirm.
DNS in a capture: the basics
A DNS exchange is normally one query and one response over UDP port 53, matched by a 16-bit transaction ID. Large responses and zone transfers use TCP. RFC 1035 defines the message format and the limits worth remembering: a label (the text between two dots) is at most 63 octets, and a full name at most 255.
The fields you will read most:
| Field | What it tells you |
|---|---|
| Query name (QNAME) | What the client wanted to reach |
| Query type | A / AAAA (addresses), CNAME (alias), MX, TXT, NS, PTR, SRV... |
| Result code (RCODE) | NOERROR, NXDOMAIN (name does not exist), SERVFAIL, REFUSED |
| Answers | Addresses, aliases or text returned, each with a TTL |
| Client and server | Which host asked, and which resolver answered |
Because resolvers cache answers for the TTL, a capture shows the first lookup of a name, not every visit. A host that reuses a cached address produces connections without a matching query in the capture.
A reading order that works
1. Identify the resolvers
List the servers answering on port 53. In a managed network, clients should use the internal resolvers. A workstation sending queries straight to an external resolver bypasses logging and filtering. Also look for DNS over TLS on port 853 (RFC 7858) and remember that DNS over HTTPS (RFC 8484) looks like ordinary HTTPS; the TLS SNI of known DoH providers is often the only visible clue.
2. Read the names, grouped by registrable domain
Group queries by the registrable domain (mega.co.nz rather than gfs270n.userstorage.mega.co.nz) and count them. Most of the list will be operating system, browser and business services. What remains is where the story usually is: file-sharing services, newly registered look-alikes of your own domains, dynamic DNS providers.
3. Check the result codes
A few NXDOMAIN answers are normal (typos, stale search suffixes). A cluster of them from one host, for names that look machine-generated, is not.
4. Tie answers to conversations
For each interesting name, take the returned addresses and look for the conversations to them right after the lookup. A name that resolved and was then contacted is stronger evidence than a lookup alone. The reverse matters too: connections to public addresses with no preceding lookup may use a hard-coded IP.
Spotting unusual domains
Rarely seen names
Frequency is a surprisingly good filter. A registrable domain that appears once in a capture, and is not a common background service, is worth reading. PCAP Parser flags these as Rarely-seen domain, excluding local suffixes such as .local or .corp and a short list of common services. In a short capture, however, everything is rare, so this flag is more useful on longer recordings.
Long and random-looking names
Human-chosen names are made of words; machine-generated ones are not. A simple way to measure this is Shannon entropy: the average number of bits needed per character. English-like labels score lower than labels of evenly mixed letters and digits. PCAP Parser flags a name as Random-looking / long when a label of 12 characters or more has an entropy of at least 3.4 bits per character, or when the full name exceeds 60 characters.
The fictional sample capture in the tool shows the pattern. The workstation looks up two names that fail:
q3v9x7kz2m8w4t1r0p6y.info A NXDOMAIN
k7f2p9x4w1q8z3m6hd0s.top A NXDOMAIN
Both are flagged random-looking and rarely seen. Neither resolved, so no connection followed, but the host that sent them is now a priority.
Domain generation algorithms
Some malware families compute a list of candidate domains from a seed, often the date, and try them until one resolves. MITRE ATT&CK describes this as Dynamic Resolution: Domain Generation Algorithms (T1568.002). In traffic it looks like the sample above, at larger scale: many random-looking names, mostly NXDOMAIN, from a single host, often at regular intervals.
DNS tunnelling indicators, at a high level
DNS tunnelling abuses the protocol to carry data: the client encodes data in the labels of queries to a domain whose authoritative server is controlled by the other party, and the server answers with encoded data in the responses. MITRE ATT&CK lists DNS as an application-layer command-and-control channel under T1071.004.
From a defender's seat, the indicators in a capture are:
- Many unique subdomains under one registrable domain, each queried once.
- Long labels and long names, close to the 63 and 255 octet limits, with high entropy or hex/base32-like alphabets.
- Unusual record types in volume, such as
TXT,NULLorCNAMEresponses carrying long values. - Volume and regularity: a steady stream of queries to one domain from one host, including when the user is idle.
- Query and response sizes well above what the rest of the network sends.
None of these is proof on its own. The strongest signal is several of them together, for one domain, from one host.
Common false positives
- CDNs and cloud services use long, hashed hostnames for load balancing.
- Security and reputation services often query hashes or encoded data as DNS names by design.
- Browsers: Chromium probes random single-label names at start-up to detect DNS hijacking; they return
NXDOMAINand look like DGA traffic. - Service discovery and local name protocols such as mDNS and LLMNR produce broadcast or multicast queries for local names.
- Telemetry from operating systems and agents can be frequent and regular.
Before concluding, check which process on the host generated the traffic, using endpoint or host logs.
Limits of DNS evidence in a capture
- Vantage point. A capture taken upstream of the recursive resolver shows the resolver asking, not the client.
- Encrypted DNS. DoH and DoT hide the names; only the resolver's address and the TLS metadata remain.
- Caching. Repeated visits within a TTL produce no new query.
- Snaplen and loss. Truncated or dropped packets lose answers. Check the capture's snaplen and any warnings.
Doing it in the browser
PCAP Parser's DNS view lists every query with its type, result code, answers and resolver, flags random-looking and rarely seen names, and feeds every name and address into the IOC list, which you can export as CSV or JSON. Filter on a registrable domain to see all its subdomains at once. The walkthrough explains the other views, and JA3 and JA4 fingerprinting covers what to read in the TLS sessions that follow a lookup.
FAQ
How do I see DNS queries in a pcap file?
Open the capture in a tool that decodes DNS: Wireshark with the display filter dns, tshark with -Y dns, or an in-browser viewer such as PCAP Parser, which lists each query with its type, result code and answers in a DNS view.
What does a lot of NXDOMAIN mean?
Many names that do not exist can come from typos, misconfigured software or stale search domains, but a burst of random-looking names that all fail is also a classic sign of a domain generation algorithm trying candidate domains. Check which process and host sent them before concluding.
Can you detect DNS tunnelling from a single capture?
You can spot indicators: many unique, long, random-looking subdomains under one domain, unusual record types such as TXT in volume, and regular timing. None of these proves tunnelling on its own, and legitimate services produce some of them, so confirm with host evidence.