Reading the DNS Query Log to triage a "blocked" ticket

The DNS Query Log is for “quickly finding the who, what, when, and where of any DNS query to troubleshoot filtering policies.” The default view shows the last 15 minutes; query data is retained up to the last 9 days, with the exact window depending on your DNSFilter plan. Anything older lives in the Data Export add-on (covered in the Advanced course’s incident-investigation lesson), not in the Query Log itself.

The four-question triage

Walk these in order. Don’t skip, each question tells you whether you need the next one.

flowchart TD
    Q1{What domain<br/>was queried?} --> Q2
    Q2{Why was it blocked?<br/>category? threat? list?} --> Q3
    Q3{Is the verdict correct?<br/>genuine threat or false positive?} --> A1
    A1{Right fix?}
    A1 --> F1[Genuine threat<br/>→ user stays blocked,<br/>investigate device]
    A1 --> F2[False positive<br/>→ allowlist with note,<br/>escalate if scope is wide]
    A1 --> F3[Wrong category<br/>→ submit recategorisation,<br/>temporary allowlist]

1. What was queried?

Start specific. Filter by the user’s Site or Roaming Client and narrow to the time the user reported. The exact domain matters, mail.example.com and cdn.example.com may be on different lists.

2. Why was it blocked?

The log row shows the verdict. Common reasons:

• Category, the domain falls under a Content Category that the customer’s policy blocks (e.g. Social Networking, P2P & Illegal).
• Threat feed: Malware, Phishing, Botnet, Cryptomining, or similar. DNSFilter’s heuristic engine also flags newly registered or suspicious domains, often before traditional reputation feeds catch them.
• Block list, somebody (the customer, the MSP, or a Universal list) added the FQDN explicitly.

3. Is the verdict correct?

This is the judgement call. A few cues:

• Domain is brand-new (registered days ago) and the user can’t articulate why they’re going there → trust DNSFilter, keep blocked.
• Domain is a customer’s known supplier or partner that’s somehow been categorised wrongly → false positive, headed for an allowlist.
• Domain is plausibly legitimate but you can’t tell → use DNSFilter’s Domain Report Tool to read its own classification before you decide.

4. What fix does this ticket actually need?

• Genuine threat, leave blocked, escalate to whoever runs the customer’s endpoint response. The ticket update is “DNSFilter caught a phishing attempt; no further action on DNS side.”
• False positive, narrow scope, add an allowlist entry (next lesson covers how) with a note saying who asked for it and why.
• Wrong category, submit a recategorisation request via DNSFilter’s Domain Report Tool so the fix is global, then add a per-policy allowlist as a temporary patch.
• Out of frontline scope, domain is sensitive, scope is unclear, customer has competing requirements, escalate with the query log row and your reasoning attached.

A worked ticket

Riverbend Legal, small law firm, conservative policy, opens a ticket: “I can’t open the link to a court filings portal.”

1. Filter the log

   

   Time = last 30 minutes; Site = Riverbend HQ; Status = Blocked. The query for filings.courts.example.gov is right at the top.

2. Read the verdict

   Verdict says category: Government. The customer’s policy blocks the Government category as a baseline.

3. Decide

   

   Court filings during business hours, named user, plausible request. Cross-check the FQDN in the Domain Report Tool to confirm DNSFilter’s own classification before deciding. Triage: temporary allowlist for this exact FQDN with a note linking to the ticket, and escalate to revisit the policy at the next change window. If the classification looks wrong globally, hit REPORT MISCATEGORIZATION from this page so the fix isn’t customer-local.

Loading quiz…