Understanding block policies and threat categories

Bouncer's core job is simple to state and hard to do well: check every DNS lookup against live threat intelligence, and block the ones that shouldn't resolve — before a connection ever opens. This article covers the main threat categories Bouncer watches for and how block decisions show up in the console.

Why blocking at the resolver matters

Most network security controls (firewalls, proxies, EDR) act after a connection has already been attempted — sometimes after it has already succeeded. DNS resolution happens first, before any of that. If a malicious domain is blocked at the resolver, the malware or the compromised process behind the lookup never gets an IP address to connect to in the first place. This is a cheap, early, and highly effective place to intervene, and it's why Bouncer treats resolver-level blocking as a first line of defense rather than an afterthought.

Threat categories Bouncer checks against

• Ransomware callback domains — domains known to be used by ransomware payloads to reach command infrastructure, request encryption keys, or exfiltrate data. Blocking the lookup can stop an active infection before it can complete its attack chain.
• Newly-registered domains (NRDs) — domains registered very recently are disproportionately used in phishing and malware campaigns, because attackers frequently burn through short-lived infrastructure. Bouncer applies extra scrutiny to lookups against NRDs.
• Command-and-control (C2) traffic — domains associated with known C2 frameworks and infrastructure, used by attackers to control already-compromised systems. Blocking C2 domain resolution can sever an attacker's remote control channel.

Threat intelligence backing these categories is kept live and current, rather than being a static blocklist that goes stale — new malicious domains are added, and domains that are cleaned up or reclassified are removed, on an ongoing basis.

What you'll see when something is blocked

In the console, a blocked lookup shows the domain, a blocked status, and the reason (for example, NRD or C2) — this mirrors the same real-time visibility pattern used in Understanding the admin console on the Broker side. Blocked lookups are logged, not silently dropped, so you always have a record of what was attempted and why it didn't resolve.

Per-identity policy

Because policy is bound to certificate identity (see Setting up DNS-over-HTTPS (DoH)), block policy can also be tuned per identity where your organization's needs call for it — for example, a research or security-testing device might legitimately need to resolve domains that would be blocked for a general-purpose corporate laptop. Consult your organization administrator if you believe a lookup was blocked incorrectly.