Four modes, and they are not variations of one thing

A FortiGate can serve DNS on an interface, and the mode decides what it does with a query it receives:

  • Forward to System DNS (forward-only in the ) makes it a relay. Queries go to the DNS servers configured under the system settings. It answers nothing itself.
  • Recursive checks the FortiGate's own DNS database first, and forwards anything it does not hold to the system DNS servers.
  • Non-recursive answers only from the local database. A name not in it is not resolved at all.
  • Resolver, added in FortiOS 7.6.0, performs full resolution itself - talking to root, and authoritative servers directly rather than handing the query to an external resolver.

The names invite the assumption that these differ by degree. They differ by who ultimately answers, which is a different question and the one that matters when something breaks.

*** THE FILTER DOES NOT APPLY TO EVERY MODE ***

Fortinet's documentation states it plainly: a DNS filter profile can be applied to Recursive and Forward to System DNS modes.

Non-recursive is not in that list.

So a FortiGate configured in non-recursive mode with dnsfilter-profile set is a device carrying a filtering policy that is not filtering. The configuration is present, the profile exists, the shows it attached — and no category rating is consulted, because the query never leaves the local database path.

Nothing reports this. There is no error, no log line saying the profile was skipped, and the dashboard has nothing to show because nothing was evaluated. It is the exact shape of failure the rest of this site keeps finding: a control that is configured, visible in the running config, and inert.

Check the mode before trusting the profile. It is one line: config system dns-server, and the mode is the field above the filter.

Why the Resolver mode exists

The stated reason in Fortinet's own release material is worth knowing because it is an operational constraint rather than a feature preference: resolving directly avoids limits imposed by external resolvers, which may cap queries per second.

A firewall doing DNS for a large network is a single client making an enormous number of queries to whatever public or resolver it forwards to. From that resolver's side it looks like one very busy host, and rate limits are applied to hosts. Resolver mode removes the intermediary that was rate-limiting you.

The cost is that the FortiGate now carries the full recursion job: root hints, the latency of walking the hierarchy on a cache miss, and the cache itself becoming a thing whose size and behaviour matter.

The database, and the two kinds of local zone

The DNS database holds local zones, and it can be primary — every record maintained by hand — or secondary, taking its content from an outside source.

The primary case is the one that quietly accumulates debt. Records added for a migration or a lab stay after the reason has gone, and a FortiGate answering authoritatively for a name that has moved is a resolution problem visible only from behind that firewall. The name works everywhere except inside your own network, which reverses the usual direction of a DNS complaint and sends the investigation outward.

Encrypted DNS on the device itself

Recent FortiOS versions expose , DoH3 and DoQ settings on the DNS server, with a certificate taken from the DNS server configuration and falling back to the web proxy's.

That closes a loop worth naming. Encrypted DNS is usually discussed as the thing that defeats a network's policy - a client choosing its own resolver over HTTPS. A firewall that offers encrypted DNS itself is offering the privacy without the loss of control: the transport is protected and the policy still applies, because the resolver is the one the network operates.