NXDOMAIN Anomaly
A client asking for names that do not exist
Traffic starts normally, then one host begins generating a steady stream of NXDOMAIN responses — the resolver's way of saying 'no such name'. A rising NXDOMAIN rate is one of the cheapest, most useful DNS signals a defender has.
- NXDOMAIN means the name does not exist, not that it was blocked
- A low background NXDOMAIN rate is completely normal
- Sustained high NXDOMAIN from one client is worth a look
Queries/minRate across all simulated clients in this scenario.
60
AllowedLookups the simulated resolver answered normally.
1
BlockedLookups a policy or feed prevented.
0
FindingsDetections raised by the simplified demonstration model.
0
NXDOMAIN %Share of lookups for names that do not exist.
0.0%
Unique domainsDistinct names seen — high cardinality is itself a signal.
1
TXT queriesTXT and NULL lookups. Normal in small amounts.
0
Avg entropyBits per character of the leftmost label. Readable names sit near 2.5.
2.00
Query flow
How each simulated lookup is handled
Device
DEMO-NAS-05
DNS query
A chat.example.com
DNS Daddy
resolver + policy
Signals
0 of 4 firing
Outcome
Allow
Event stream
Synthetic queries. Select a row to inspect it.
| Time | Device | Type | DNS query | Result |
|---|---|---|---|---|
| 13:42:00 | DEMO-NAS-05192.0.2.91 | chat.example.com | Allowed |
Devices on the simulated network
Per-device behaviour, measured over the run
DEMO-LAPTOP-01192.0.2.21
Staff laptop
- queries
- 0
- unique
- 0
- entropy
- 0.00
- nxdomain
- 0%
DEMO-DESKTOP-02192.0.2.32
Reception desktop
- queries
- 0
- unique
- 0
- entropy
- 0.00
- nxdomain
- 0%
DEMO-LAB-CLIENT192.0.2.42
Isolated lab host
- queries
- 0
- unique
- 0
- entropy
- 0.00
- nxdomain
- 0%
DEMO-PHONE-04192.0.2.70
Mobile device
- queries
- 0
- unique
- 0
- entropy
- 0.00
- nxdomain
- 0%
DEMO-NAS-05192.0.2.91
File server
- queries
- 1
- unique
- 1
- entropy
- 2.00
- nxdomain
- 0%
Detection model
Signals accumulate as behaviour changes
Signals
- High NXDOMAIN ratio+0 of 30not yet observed
- Sustained failure volume+0 of 20not yet observed
- Failures spread across many distinct names+0 of 20not yet observed
- Elevated query rate+0 of 12not yet observed
Simplified demonstration model. Each signal adds a fixed number of points; reaching 65 generates a finding. Real detection engines weigh signals dynamically — this version is written to be readable, and is not production telemetry.
Attack timeline
How the scenario unfolds
- 1Baseline traffic: nearly all lookups succeednow
- 2One client starts requesting names that do not resolve
- 3NXDOMAIN ratio for that client climbs past the background rate
- 4Volume and unique-name signals fire
- 5Risk score crosses the threshold
- 6Finding generated
- 7Analyst separates misconfiguration from probing
Threat hunting mode
Find the affected device before the model tells you
Hunting mode hides the finding and the highlighted device. You read the raw stream and per-device measurements, then name the device you think is compromised.
Keep going
Compare this against another pattern