Threat Intelligence

Navigation: DNS Security → Threat Intelligence

Threat intelligence blocks lookups to domains that are already known — or newly seen — as malicious. The check happens at resolve time, so the client never receives a usable IP for malware, phishing, C2, botnet, or ransomware infrastructure.

What is blocked

Threat class Why it matters
Malware Payload hosts, droppers, and update servers
Phishing Credential-harvest and look-alike sites
C2 Command-and-control callbacks after infection
Botnet Join / beacon domains for coordinated bots
Ransomware Payment, leak, and key-exchange infrastructure
Newly observed domains Names first seen recently — often used once and discarded

Verdicts are stored in the local Redis-backed reputation cache so repeated queries for the same FQDN reuse the last result. That cache is the same class of local store TOORCE already uses for rating and custom signatures.

Reputation levels

reputation Meaning Typical action
clean No threat match Allow (category policy may still apply)
suspicious Weak or aging indicator Log or challenge per policy
malicious Confirmed bad Block
critical Active C2 / ransomware / high-confidence intel Block

Malicious request example:

{
  "src_ip": "192.168.1.55",
  "domain": "bad-domain.example",
  "qtype": "A",
  "dnssec": "unsigned",
  "category": "malware",
  "reputation": "critical",
  "action": "block",
  "reason": "C2 domain"
}

How a lookup is rated

Query FQDN
   →  Redis reputation cache (hit → reuse verdict)
   →  Threat intel feeds (malware, phishing, C2, botnet, ransomware)
   →  Newly observed domain check
   →  Store verdict in Redis
   →  Allow or block + log

Cache entries expire so a domain that later turns malicious is re-checked. Newly observed names stay in a stricter bucket until they age out of the “new” window.

Recommended policy

Setting Recommended Notes
Malware / phishing / C2 / botnet / ransomware Block Default-deny for known-bad classes
Newly observed domains Block or log Blocking is stricter; some brand-new SaaS names will need allow-list entries
Allow-list Required exceptions only Corporate CDNs, update hosts, and lab domains
Block response Sinkhole or NXDOMAIN Prefer a consistent response so clients fail closed

Relationship to other engines

Engine Difference
DNS Filtering Policy categories (gambling, adult, dynamic DNS) — not necessarily malware
Web Security URL / HTTP(S) after the connection starts
Anti-DGA Detects generated names that are not yet on a feed
FQDN Policy Firewall L3/L4 rules on resolved IPs — complementary, not a replacement

Related topics