Triage DNS and Outbound Connections with Zeek Logs

Zeek records network activity as structured logs. dns.log describes observed DNS transactions, while conn.log summarizes connections and their initiator/responder endpoints. Together they help an analyst build a timeline and identify useful pivots; they do not by themselves prove that a domain is malicious or reveal encrypted application content.

This walkthrough assumes the standard tab-separated Zeek log writer and authorized access to sensor logs. Use the incident’s actual time range and internal address plan. The sample documentation addresses use reserved example ranges.

Figure 1: Pivot from a DNS observation to connection metadata using the shared Zeek connection UID.

---

Step 1: Confirm Sensor, Time Range, and Log Format

01

Establish Which Sensor Saw the Traffic

Collection Context

Identify the sensor, monitored network, log rotation period, and time zone used by your case. Zeek’s originator is the endpoint that initiated a connection; it is not automatically a client inside your network. Confirm the local address ranges and sensor placement before labeling a connection outbound. The commands below assume the default tab-separated ASCII logs.

cd /opt/zeek/logs/current
ls -lh dns.log conn.log
head -n 8 dns.log

❯ View Expected Console Output

#separator \x09
#fields ts uid id.orig_h id.orig_p id.resp_h id.resp_p ... query ...

---

Step 2: Extract DNS Questions and Answers

02

Review Relevant DNS Transactions

DNS Triage

Use zeek-cut to select fields by name rather than counting tab-separated positions. Narrow to the case domain and a bounded log file or time window. Capture the query, query type, response code, answers, source host, event time, and UID. DNS answers can be empty for a failed lookup, truncated, or different because of caching, proxies, or resolver behavior.

zeek-cut ts uid id.orig_h id.resp_h query qtype_name rcode_name answers < dns.log \
  | grep -Fi 'updates.example.test'

❯ View Expected Console Output

2026-10-05T12:24:18Z  C4x...  10.20.0.21  10.20.0.1  updates.example.test A NOERROR 198.51.100.42

---

Step 3: Pivot from the DNS UID into Connections

03

Follow the Same Flow in conn.log

Connection Pivot

When a DNS UID is present, search the connection log for that UID. Compare the initiator, responder, port, service, duration, connection state, and byte counts. If the domain resolved to multiple addresses, search those addresses in the same case window as an additional pivot; preserve which observation came from DNS and which came from a connection record.

zeek-cut ts uid id.orig_h id.resp_h id.resp_p proto service duration \
  conn_state orig_bytes resp_bytes < conn.log \
  | grep -F 'C4x8pQ2aL1s9mY3d'

❯ View Expected Console Output

Initiator: 10.20.0.21
Responder: 198.51.100.42:443/tcp
Interpretation: a connection record is present; review surrounding telemetry.

---

Step 4: Find Other Hosts and Repeated Queries

04

Scope the Observation Across the Sensor

Scope Check

Search the relevant DNS log rotation for the domain and examine distinct source hosts, timestamps, query types, and responses. Then check the connection log for the responder address. Review a narrow case window first; expand it when repeat activity or delayed resolution supports a longer lookback.

zeek-cut ts id.orig_h query answers < dns.log \
  | grep -Fi 'updates.example.test'

zeek-cut ts id.orig_h id.resp_h id.resp_p proto service conn_state < conn.log \
  | grep -F '198.51.100.42'

❯ View Expected Console Output

Compare each source host with asset ownership, DNS resolver logs,
proxy records, endpoint telemetry, and change history.

---

Step 5: Assess What the Records Can and Cannot Show

05

Separate Metadata from Conclusions

Evidence Review

A DNS request shows that a sensor observed a lookup, not that the user intentionally visited the domain. A connection record describes flow metadata, not the payload. HTTPS, encrypted DNS, sensor loss, asymmetric routing, proxying, and log rotation can affect what is visible. Check the local asset baseline and corroborate any concerning activity with endpoint, resolver, firewall, or proxy telemetry.

Observed facts: timestamp, source, query, answer, UID, connection fields
Corroboration: endpoint process, resolver, firewall, proxy, asset owner
Gaps: packet loss, encrypted traffic, missing logs, unknown asset role

❯ View Expected Console Output

The finding distinguishes logged network metadata from analyst inference.

---

Step 6: Document a Reproducible Pivot

06

Save the Query and Case Evidence

Handoff

Record the sensor, log path or index, file rotation, query, case time zone, and relevant UIDs. Attach only approved log extracts, preserve the original records under your retention rules, and list the next data source to check. Escalate according to the response plan if corroborating evidence supports an incident.

Sensor / monitored segment:
Log rotation and event window:
Domain, source, answer, and connection UID:
Correlated connection fields:
Related endpoint / DNS / proxy records:
Finding, confidence, and next owner:

❯ View Expected Console Output

Another analyst can repeat the pivot from the saved UID and time window.

If Zeek is configured to write JSON

These examples use the standard tab-separated ASCII log format. Confirm the #fields line and active log writer first. For JSON output, use a JSON-aware parser and the field names from that deployment instead of passing the file to zeek-cut.

References

Zeek dns.log reference · Zeek conn.log reference · Zeek zeek-cut utility