Detectors
How anomalies and friction are found, and what each one refuses to claim.
Every detector reports whether it had enough history to be meaningful, rather than reporting a confident nothing. An empty section reads as “all clear”, and claiming all-clear on a baseline that does not exist is the one failure mode these pages must not have.
In plain terms
Two pages look for things worth your attention: a device that suddenly started talking to somewhere it never did before, or a lookup being retried over and over because something is stuck.
They all obey one rule. If there is not enough history yet to know what normal looks like, they say “not enough history” rather than showing nothing. A blank page looks like good news, and on a fresh install it would be a lie.
Anomalies#
Encrypted-DNS bypass#
Devices looking up a public DoH or DoT resolver. Before anything can route around this box it has to ask this box where that resolver lives, which is the one query it cannot hide.
Stated as intent, not proof: software frequently checks whether a resolver is reachable without going on to use it. The page says so on its face. It also tracks the Firefox canary, use-application-dns.net, which being blocked is the correct outcome, since that is how Firefox is told to keep using your resolver.
Every detector on this page works identically on both resolvers, because all of them read this product’s own store rather than anything resolver-shaped. They need a device, a domain, a timestamp and a verdict, and both resolvers report all four. Nothing here depends on answer addresses, which is why the detectors are the part of the product that loses nothing at all on Pi-hole.
Beaconing#
Detected by evenness rather than by frequency. A browser is bursty; a beacon is a metronome. The measure is the spread of intervals between a device’s lookups of one name, so something asking every 300 seconds all day scores high regardless of volume.
A browser
15 lookups
clustered · long gaps · irregular
A beacon
14 lookups
every 300s · gaps almost identical
New device, new domain, gone silent#
All three rest on first_seen and last_seen on the dimension rows, which is why retention never deletes dimensions. “Gone silent” is the one people find most useful and the one most likely to be innocent: a laptop that went on holiday looks identical to a camera that died.
Tunnelling shapes#
Long labels, high entropy, unusual record types. The page is explicit that this is also the shape of a CDN that hashes hostnames, and asks the reader to look at the names before acting.
Friction#
A blocklist is a trade, and until this page existed the interface only reported one side of it. Nothing here argues for blocking less; it argues for knowing which eleven of four thousand refusals were the ones somebody noticed.
Episodes, not queries#
Consecutive lookups of the same name by the same device, each within a few seconds of the last, are one episode. Everything past the first lookup in an episode is a retry. This collapse is the single biggest way the analysis could be wrong: a resolver answers A, AAAA and HTTPS for one name, and counting those as three would make every ordinary block look like a storm.
Shape#
| Shape | Means | What you would do |
|---|---|---|
| loop | Most retries sit in one long episode | One client got stuck. Fix the client |
| recurring | Retries spread across many episodes | It happens every time the thing is used. Reconsider the rule |
| occasional | A few short episodes | Noted, not urgent |
The distinction matters because the two have completely different answers: reinstall the app, or reconsider the list.
The moment view#
Each row opens the worst episode it produced, at the second it happened, with every lookup either side of that instant on one timeline. It will not claim the blocked names caused a visible problem: DNS records that a device asked for names in a certain order and nothing about what any of them were for. It puts the sequence in front of the reader and lets them do the inference, which they can, because it is their house.