Turn sinkhole logs into clear operational effectiveness metrics. Balance redirection, remediation speed, and data quality. Make smarter takedown decisions with comparable scores today, quickly.
| Component | Definition | Why it matters |
|---|---|---|
| Redirection rate (R) | R = redirected / total × 100 | Shows how much malicious traffic reaches your sinkhole for observation and control. |
| Containment rate | (redirected + blocked) / total × 100 | Tracks overall control of malicious traffic, including non-sinkhole blocks. |
| Domain coverage (C) | C = sinkholed_domains / known_domains × 100 | Measures how much of your known domain set is routed to the sinkhole. |
| Endpoint capture (E) | E = captured_endpoints / observed_endpoints × 100 | Indicates whether you can identify which assets are affected. |
| Visibility (V) | V = (log_completeness + attribution_success) / 2 | Ensures sinkhole data is usable for investigations and reporting. |
| Speed (P) | P = 0.4·MTTS + 0.2·MTTN + 0.4·MTTR (scaled) | Rewards faster rerouting, notification, and endpoint remediation. |
| False-positive penalty | Penalty = FP_rate × penalty_weight | Prevents “high score” systems that redirect too much benign traffic. |
| Final score | Score = (wR·R + wE·E + wC·C + wV·V + wP·P) − Penalty | One number for trending, benchmarking, and prioritization. |
Sinkhole effectiveness is measured as controlled visibility over malicious destinations, not just blocked queries. This calculator converts telemetry into a 0–100 score so teams can trend performance over time. The score blends redirection, domain coverage, endpoint capture, log quality, and response speed, then subtracts a false‑positive penalty. Use one reporting window and consistent counting rules to keep comparisons defensible. for stakeholders and auditors.
Redirection rate shows what portion of malicious attempts reaches your controlled sinkhole. For example, 120,000 total attempts with 82,000 redirected yields 68.3% redirection. If 21,000 additional attempts are blocked upstream, containment becomes 85.8%, revealing stronger control than sinkhole reach alone. Track bypass causes such as roaming clients, split DNS, encrypted resolvers, or direct‑IP connections, and verify sinkhole responses avoid business disruption.
Coverage compares sinkholed domains to the known malicious domain set. With 340 known domains and 220 sinkholed, coverage is 64.7%, leaving 120 domains un-routed and unobserved. High performers match onboarding cadence to threat‑intel churn, confirm DNS ownership or resolver policy, and monitor TTL behavior. A practical target is 75–90% coverage for active campaigns, with exceptions documented for legal or stability constraints.
Endpoint capture rate indicates how often sinkhole events can be mapped to a responsible asset. In the example, 410 captured endpoints out of 640 observed gives 64.1%. Raising this rate usually requires richer context: DHCP and IPAM lookups, NAT and proxy mappings, device identifiers from EDR, and identity signals from directory logs. Better attribution reduces “unknown source” cases and improves remediation reporting.
Speed is modeled from mean time to redirect, notify, and remediate, with caps of 48 hours, 240 minutes, and 168 hours to normalize extremes. Faster MTTS and MTTR typically correlate with fewer reinfections and lower analyst workload. Noise is tracked through the false‑positive rate; 120 false positives against 82,000 redirected is 0.15%, usually acceptable, while rates above 5% deserve staged rollouts and tighter allowlists. Review metrics weekly and adjust weights to match priorities.
It estimates operational effectiveness of a sinkhole program by combining redirection, containment, domain coverage, endpoint capture, visibility, and response speed into a comparable 0–100 score.
Use the same log sources each period. Count DNS queries or proxy requests classified as malicious, including those later blocked or sinkholed. Avoid mixing multiple detection rules unless you normalize them first.
If redirection increases due to misclassification, false positives rise and the penalty subtracts points. The goal is controlled, accurate redirection with low noise, not maximum rerouting.
Enable it when you want a broader “control of traffic” view that rewards upstream blocking. Leave it off when you specifically want to measure sinkhole reach and collection quality.
Use the weight profile or custom weights to match priorities. If your organization has different time expectations, adjust the MTTS, MTTN, and MTTR scaling caps in the code comments.
The exports summarize counts, percentages, and scores. If you add domain lists or endpoint identifiers later, redact them before sharing outside security operations or external auditors.
| Month | Total attempts | Redirected | Blocked | Known domains | Sinkholed domains | Observed endpoints | Captured endpoints | False positives | Effectiveness (example) |
|---|---|---|---|---|---|---|---|---|---|
| 2025-11 | 98,400 | 61,200 | 18,600 | 280 | 170 | 520 | 300 | 160 | 66.8% |
| 2025-12 | 112,900 | 74,500 | 20,900 | 310 | 195 | 590 | 365 | 140 | 71.4% |
| 2026-01 | 120,000 | 82,000 | 21,000 | 340 | 220 | 640 | 410 | 120 | 76.2% |
Important Note: All the Calculators listed in this site are for educational purpose only and we do not guarentee the accuracy of results. Please do consult with other sources as well.