DNS Triage Lab for Beginners (White-Hat, Defensive Workflow)

This lab runs in an authorized environment you control — your own VMs, a sample pcap, or test DNS logs. The goal is to compare normal resolver behavior with something suspicious and decide what evidence to collect next.

Do not capture traffic from systems you do not own or explicitly control. If you are using a school or work network, check that you have permission before running any captures.

Before you start, write down what you expect to see. This is not busywork — if the result surprises you, the gap between your hypothesis and what you got is what you actually learned.

Collect a short packet capture or DNS log during normal browsing or update activity. Note the resolver IPs, the common domains queried, typical query frequency, and whether responses come back clean. That sample is your baseline.

Then introduce one controlled variation — repeated lookups of the same domain, a typo domain, or a forced NXDOMAIN — and compare what changes. Look at timing, query names, NXDOMAIN rates, and which host generated the traffic.

If something looks suspicious, correlate with host logs and process context before drawing conclusions. DNS alone points in a direction; it rarely proves intent or impact by itself.

Log timestamps, source host, resolver IP, query names, and any repeated patterns. Write what is observed separately from what is inferred. Mixing the two is the most common mistake in analyst notes and the hardest habit to unlearn later.

End the exercise with a short triage note: hypothesis, evidence checked, confidence level, and next action. The options are usually: close the lead, monitor for recurrence, capture more data, or investigate the host and process context further.

Run the same lab a few more times with different variations. Normal DNS behavior varies more than most beginners expect across different OS versions, browsers, and update services.