I have been evaluating the DNS server functionality within FortiGate's security fabric, specifically for its integrated threat filtering capabilities. My analysis is based on version 7.2, reviewing the official documentation and several third-party deployment reports.
The primary question is whether the DNS filter, when handling recursive or forwarder duties for a large network, can manage the load for approximately 1000 concurrent users. Key scaling considerations include:
* **Query Performance:** The system must process DNS queries with minimal added latency when threat intelligence lookups and categorization are enabled. The hardware model (e.g., CPU power and RAM) is obviously critical, but I'm interested in the efficiency of the DNS filtering process itself.
* **Cache Efficiency:** A large user base generates repetitive queries. The effectiveness of the local DNS cache in reducing upstream requests and filtering overhead is a major factor.
* **Profile and Policy Management:** Applying distinct filtering policies based on user groups or network segments at this scale. How does performance hold up with complex policy sets and dynamic address objects?
From a statistical standpoint, one must estimate the average queries per user per second. A conservative estimate of 0.1 QPS per user would result in a sustained 100 QPS, with significantly higher peaks. I have seen anecdotal reports for deployments in the 300-500 user range, but concrete data for 1000-user environments is sparse.
I am seeking detailed operational experiences. Specifically:
* What FortiGate models are you using for a similar deployment, and what is your observed query load?
* Have you measured any appreciable latency difference when threat filtering is enabled versus a basic forwarder configuration?
* How does the system handle sudden surges, such as during a malware outbreak triggering widespread block pages?
* Any issues with stability or memory usage over extended periods?
prove it with data
Your focus on the DNS filter's internal process efficiency is the right approach. Too many people just check the datasheet's "maximum sessions" figure, which is nearly useless for DNS proxy workloads. The bottleneck isn't typically raw packet throughput, it's the latency introduced by the threat feed lookup and policy matching for each unique query.
I have performance data from a 600-user deployment on a 600E in proxy mode. With all filtering categories enabled and using FortiGuard for categorization, the 95th percentile latency addition was 11ms compared to an upstream resolver. However, the cache hit rate was critical. We saw a 68% cache hit rate after one week, which brought the average added latency down to under 3ms. Your 1000-user target is feasible, but you must dimension the hardware for the *uncached query rate*. I'd model for at least 300-350 queries per second peak to be safe.
The real scaling challenge you didn't mention is the logging subsystem. If you enable DNS event logging for all queries with policy names, you'll generate a staggering amount of data. That will impact the same disks handling UTM inspections. You need to plan your log settings and potentially offload to FortiAnalyzer very early in the design.
Data first, decisions later.
You're overthinking it. The efficiency of the filtering process is moot if you put it on the wrong hardware. Seen it a dozen times.
The datasheet's session count is junk, true, but so is assuming your cache hit rate will be good. It entirely depends on user behavior. A thousand users with locked-down devices hitting the same SaaS endpoints? Fine. A thousand BYOD users browsing random junk all day? Your cache is useless and the lookup engine will buckle. Dimension for your worst case, not the average.
And good luck with complex policy sets at that scale. The UI gets sluggish with more than a few dozen address objects and groups. You'll end up managing it via CLI scripts, which defeats the whole integrated fabric premise.
CRM is a necessary evil