Fix Fortinet DNS parser default event type filtering

[michaelatmsft]

Summary

Fix the Fortinet FortiGate DNS filtering parser so the parameterless DNS unifying parser returns Fortinet DNS events.

_Im_Dns() uses the legacy default eventtype='lookup' and passes it to each source-specific filtering parser. Fortinet DNS events are normalized with EventType='Query', but vimDnsFortinetFortiGate only accepted Query or *. As a result:

_Im_Dns(starttime=ago(1d), endtime=now())

excluded Fortinet DNS records, while either of these returned them:

_Im_Dns(starttime=ago(1d), endtime=now(), eventtype='Query')
_Im_Dns(starttime=ago(1d), endtime=now(), eventtype='*')

This causes incomplete results for investigations, hunting queries, workbooks, analytics, and detections that use the ASIM DNS abstraction without overriding eventtype.

Root cause and regression history

• PR #10150 originally fixed this compatibility issue by accepting both the schema-standard Query value and legacy lookup value.
• PR #12927, specifically commit 7a88704015f888f441b3ccf9628f2da0a3c45c2a, replaced that check with a direct comparison between EventTypeTmp='Query' and the incoming parameter. This unintentionally removed lookup compatibility and reintroduced the issue.

Changing the unifying parser default from lookup to Query is not safe because other DNS source parsers still rely on the legacy value. Compatibility therefore belongs in the source-specific filtering parser.

Changes

• Accept Query, legacy lookup, and * in vimDnsFortinetFortiGate.
• Set the source parser default to lookup, matching the value supplied by imDns and _Im_Dns.
• Add a KQL comment explaining why lookup support must not be removed.
• Update the parser from version 0.1.2 to 0.1.3 and add a changelog entry.
• Regenerate the corresponding ARM template.

Regression coverage

The repository already runs an ASIM filtering workflow against Fortinet sample data. Using lookup as this parser's default makes that workflow exercise the same path used by a parameterless _Im_Dns() call, providing regression coverage without adding new test infrastructure or a parser-specific test framework.

Validation

• ASIM parser template validation passed for both Fortinet DNS parsers.
• Focused assertions verified that the YAML default and compatibility filter are present and that the generated ARM query and function parameters match the YAML source.
• ARM JSON parsing and diff checks passed.
• CI KQL validation passed on rerun.
• CI ASIM template validation, sample-data ingestion, and schema/data tests passed.
• The CI filtering job returned 21 Fortinet rows through the lookup default, demonstrating that this regression is fixed. On both attempts, the job then failed its generic time-window assertions because all newly ingested sample rows had effectively the same timestamp (starttime returned 21 of 21 rows and endtime returned 0). It also reported the expected single DNS EventType as the workflow's documented partial-validation case. These failures are in the generic data-dependent test assumptions rather than the Fortinet event-type compatibility behavior changed by this PR.

[michaelatmsft]

CI status after rerun

All current checks pass except Run ASim Parser Filtering tests.

The rerun confirms the behavior fixed here: invoking the modified parser with its lookup default returns all 21 Fortinet DNS sample rows. The job subsequently fails only because its generic datetime test assumes the newly ingested rows span more than one timestamp:

• starttime: 21 rows returned out of 21, so the count was not reduced.
• endtime: 0 rows returned at the computed midpoint.
• eventtype: one normalized value (Query), which the workflow itself identifies as the expected partial-validation case for DNS.

KQL validation passed on rerun, as did ASIM template validation, sample-data ingestion, and schema/data validation. No failure identifies the changed Fortinet filter or generated ARM template as invalid.