I've been running a cluster of Firebox M570s in an active-passive pair for about eighteen months now, primarily serving a hybrid environment with a mix of on-prem workloads and cloud egress points. One feature I've had enabled but have always been a bit skeptical about is **DNS Watch**. The marketing materials and admin docs talk about preventing callbacks to C2 servers, data exfiltration via DNS tunneling, and blocking access to malicious domains.
My question for the community is: does it actually *prevent* anything meaningful in practice, or is it more of a basic, supplemental layer?
Here’s my experience and what I'm curious about:
* I have it configured with the Threat Prevention service (APT Blocker and Botnet Detection enabled), using the default action of "block and log." The logs show it catching things periodically—usually lookups to known malware domains or suspicious newly registered domains—but these always seem to be from a handful of the same internal hosts with recurring issues. It feels more like cleaning up after the fact rather than proactive prevention.
* I'm particularly interested in its efficacy against more sophisticated threats:
* **DNS Tunneling:** Does the heuristic analysis catch low-and-slow data exfiltration, or is it primarily looking for known malicious domain patterns? Have you seen it trigger on something you later confirmed was an actual exfiltration attempt?
* **Zero-Day/DGA Domains:** How quickly does the feed update? In a scenario with a new malware family using Algorithmically Generated Domains, is DNS Watch reactive until the signature is pushed, or is there any behavioral detection at play?
* **False Positives:** I've had to create a few allow-list entries for internal services and weird SaaS APIs that use unique subdomains per customer. Has this been a significant management overhead for others?
I'm trying to weigh the real security value against the (admittedly low) performance overhead and log noise. Is DNS Watch a true line of defense, or is it better thought of as a useful logging/alerting mechanism that requires a separate response workflow? I'd love to hear from anyone who has done deeper analysis, has integration with their SIEM for these alerts, or, crucially, has any forensic evidence of it actually stopping a breach.
~jason
~jason
It does block the low-hanging fruit. The logs you're seeing for the same internal hosts? That's it working.
On DNS tunneling: it's a basic volumetric detector. It looks for excessive query rates or unusual request sizes. A slow, patient tunnel using encoded data in subdomains will likely slip past it. You need dedicated DNS filtering or a proxy that does actual payload inspection for that.
It's supplemental. Treat it as a cheap alarm bell for infected hosts, not a primary defense layer. The real value is catching those callouts before something worse happens, even if it's "after the fact" for that host.
Numbers don't lie