• Illegal Flag Combination — invalid combination in the flags field.

• Invalid Op Code — invalid value in the OpCode field.

• SP, DP Both 53 — Typically, all DNS queries are sent from a high-numbered source port (49152 or above) to destination port 53, and responses are sent from source port 53 to a high-numbered destination port. If the header has port 53 for both, it is likely a crafted packet. DNS Zone Transfers can use Port 53-Port 53 traffic as well as several other “anomalies”. These are accounted-for by the DNS anomalies and feature controls.

• Incomplete DNS — DNS packet format not detected.

• Query Bit Set — DNS query with the query reply (QR) bit set to 1. In a legitimate query, QR=0.

• Null Query — DNS query in which the question, answer, additional, and name server counts are 0.

• QDCount not One in Query — Number of entries in the question section of the DNS packet is normally 1. Otherwise, it might be an exploit attempt. If this anomaly is not enabled, the system will allow TCP queries with multiple questions to exceed the TCP query thresholds. Enable this anomaly unless there is encrypted UDP DNS traffic present.

• RA Bit Set — DNS query with the recursion allowed (RA) bit set. The RA bit is set in responses, not queries.

• QCLASS in Reply — DNS response with a resource specifying a CLASS ID reserved for queries only (QCLASS).

• QType in Reply — DNS response with a resource specifying a TYPE ID reserved for queries only (QTYPE).

• Query Bit not Set — DNS response with the query reply (QR) bit set to 0. In a legitimate response, QR=1.

• QDCOUNT not One in Response — Number of entries in the question section of the DNS packet is normally 1. Otherwise, it might be an exploit attempt.

• Name too Long — DNS name that exceeds 255 characters. This can cause problems for some DNS servers.

• Label Length too Large — Query or response with a label that exceeds the maximum length (63) specified in the RFC.

• TCP Message too Long — TCP query or response message that exceeds the maximum length specified in the message header.

• UDP Message too Long — UDP query or response message that exceeds the maximum length specified in the message header.

• Message Ends Prematurely — a message that ends prematurely might indicate an exploit attempt.

• Class not IN — a query/response in which the question/resource address class is not IN (Internet Address). Although allowed by the RFC, this is rare and might indicate an exploit attempt.

• Zone transfer — an asynchronous Transfer Full Range (AXFR) request (QTYPE=252) from untrusted networks is likely an exploit attempt.

• Pointer Loop — DNS message with a pointer that points beyond the end of data (RFC sec4.1.4). This is an exploit attempt.

• Empty UDP — An empty message might indicate an exploit attempt.

• TCP Buffer Underflow — A query/response with less than two bytes of data specified in the two-byte prefix field.

• Type All/Any Used — Detects a DNS request with request type set to ALL (QTYPE/Resource Record = 255).

• Extraneous Data — a query/response with excess data in the packet after valid DNS data.

• TTL too Long — TTL value is greater than 7 days (or 604800 seconds). As some web sites have TTLs longer than 7 days, it is highly recommended that this anomaly be always disabled except under expert advice.

• Invalid Class Type — a query/response with TYPE or CLASS reserved values.

• Name Length too Short — a query/response with a null DNS name. This anomaly includes a check that any FQDN is structured properly with at least one “.” to separate the domain and the TLD, like “Fortinet.com”. If the “.” is missing the FQDN is invalid.

• Multiple OPT RR — multiple OPTION (Qtype/Resource Record 65) are not allowed in the RFC.

The Authentication Direction determines if the Source Address validation is attempted from the Flood Mitigation Mode Inbound/Outbound as listed below:

• Inbound — default and normally used.

• Outbound — not recommended.

• Inbound Outbound — not recommended.

• None — this disables DNS Source IP validation. It is not recommended.

The Flood Mitigation Mode Inbound options appear if Inbound or Inbound Outbound is selected for Authentication Direction.

• TC Equal One — When DNS UDP Query floods are detected, the Queries are dropped and a TC=1 DNS Response is sent to Sources which is a request for the Source to retransmit the Query in TCP. Spoofed Sources cannot do that and the original packet has already been dropped. Good Sources (like DNS Recursive Servers) will change to TCP and that Query will be processed again using the TCP mitigation and TCP Query thresholds. Note: Some DNS servers are set up to refuse TCP Queries. Understand your DNS server settings.

• DNS Retransmission — When DNS UDP Query floods are detected, the Queries are dropped but recorded in a special section of the DQRM table. When the Source IP (client or recursive server) re-Queries at an appropriate time interval, the 2nd Query is again dropped with the Source IP of the Query added to the Legitimate IP Table for DNS. The 3rd and subsequent DNS Queries are allowed to pass for a short time before re-validation is required. This method uses less outbound bandwidth (no outbound TC=1 Response) but is slightly easier for attackers to spoof. Fortinet is unaware of any attacks that send identical Queries with the correct cadence and quantity. If unsure, use TC=1.

• Transparent Proxy — Expert use only — Transparent Proxy is intended to improve Source validation over DNS Retransmission when DNS servers do not accept TCP Queries (rare). FortiDDoS validates the Source using CNAME redirects with source cookies to track the Source statelessly. Legitimate Sources will successfully redirect twice and will be allowed to proceed to other DNS mitigations. Spoofed Sources will fail to redirect.

Note 1: If Transparent Proxy is used:

• Do not use Options when No Cache Match = ForceTCP. Other options are acceptable.

• Disable Force QType ANY Query Use TCP.

Note 2:

TC Equal One,DNS Retransmission, and Transparent Proxy validations are effective against direct spoofed source Query floods protecting Recursive and Authoritative DNS servers as well as other infrastructure from spoofed IP floods. In all cases, TC=1 is strongly recommended as a more decisive “stateless” method to validate Query Sources. However, in many cases, attacks on Authoritative DNS servers are relayed through ISP or Global DNS Recursive Servers. These servers are “valid” by definition and will always respond correctly. While TC=1 is still recommended with Authoritative servers, other mitigations below will add protection.

Note: Expert use only. There is almost no situation where Outbound or Inbound/Outbound DNS Flood Mitigation is required. Use Inbound only.

The Flood Mitigation Mode Outbound options appear if Outbound is selected for Authentication Direction.

• See options for Flood Mitigation Mode Inbound above.

DQRM is a protection from DNS Reflected (Amplified) Response floods. Attackers Query Recursive or Authoritative DNS servers using UDP and using the Target IP address (yours) as the Source IP of the packet. Since the server cannot verify the Source IP it sends a Response to the Target which never sent a Query. DNS Response Floods are the #1 or #2 attack by numbers of attacks and size of attacks every quarter.

For Symmetric Traffic: Enable this always for all SPPs. FortiDDoS will record every outbound Query. When the Inbound Response is seen, it is matched to the Query, allowed to proceed and the table is cleared. If an inbound Response is seen that does not have a matching Query, it is immediately dropped with no Threshold.

For Asymmetric Traffic: Disable this option. If FortiDDoS cannot see all outbound traffic and DNS Queries, there is a high risk of false-positive drops from DQRM. Use DNS Rcode Thresholds in SPP > Thresholds.

For Encrypted DNS: Many firewalls encrypt DNS traffic over UDP 53, particularly for vendor web filter services. If encrypted DNS to UDP 53 is present, disable DQRM since it cannot decrypt vendor encryption. Use DNS Rcode Thresholds in SPP > Thresholds.

Note:

Some firewalls can change the web filter DNS Query port to HTTPS over TCP 442 (DoH).

If you are unsure if you have encrypted traffic to UDP port 53, enable all DNS anomalies above and leave SPP in Detection mode for one hour. Examine the outbound drop information for that SPP from Dashboard > TOP ATTACKS > SPP. If there are a number of different DNS anomalies, particularly Invalid Opcodes and 5-10 others, then the system is seeing encrypted DNS. If in doubt, contact Fortinet for assistance.

The cache stores FQDNs and RR Types (A, AAAA, MX, etc. records) with decrementing TTLs from good Responses. Under Flood the cache can respond to Queries to offload the DNS server. Options for cache misses are described below. Cache should only be used with Authoritative DNS Servers with limited numbers of domains.

Note: The Cache will not store any FQDN with TTL longer than 30 days (2,592,000 seconds).

During normal traffic, the FQDN, RR Type (A, AAAA, MX, etc) and TTL of good Responses is stored in the Legitimate Query (LQ) table. Under Flood a Query with matching FQDN and RR Type is allowed to pass for further processing while non-matching Queries are dropped. This stops random subdomain or dictionary FQDN Queries very quickly.

Note: Good (Rcode = 0) DNS Responses that are NODATA (no answer section/IP address) are treated as negative responses and will not populate the LQ table.

If Enabled: Under flood, FortiDDoS will block all traffic from the identified Source IPs.

If Disabled: This is the default status. Under flood, FortiDDoS drops packets based on validations, TTL, LQ, etc. but does not block the Source IP.

If Enabled: FortiDDoS drops multiple identical Queries in rapid succession but below the Query thresholds.

If Disabled: Only Query Thresholds are used for mitigation.

• ForceTCP — Default. Under flood, if no Cache Response is available for an otherwise legitimate Query (has passed validation, TTL and LQ for example), to confirm the Source, request a re-Query over TCP.

• Forward To Server — Recommended, particularly if using TC=1 validation. Under flood, if no Cache Response is available for an otherwise legitimate Query (has passed validation, TTL and LQ for example), forward to the DNS server. Under flood, Cache entries may age-out and not be replaced, leading to false-positive drops.

• Drop — Under flood, if no cache entry exists, drop the Query.

If Enabled: Drop all DNS Fragments. Use with care. DNS Response fragments are common when communicating with upstream servers using DNSSEC and EDNS0. If you know this SPP never uses DNSSEC, then enabled is recommended.

If Disabled: DNS Fragments are allowed and DNS Fragment Thresholds will be used to detect/mitigate DNS Fragments.

Enable if you have purchased FortiGuard Domain Reputation Service. When enabled, choose any or all of the following:

• Malicious Urls
• Botnet Domains
• Bitcoin Mining Domains

See System > FortiGuard for license information and additional settings.

Drop any Query or Response that indicates DNSSEC D0 bit=1 or RR 41. Use with care. It is difficult to know who is using DNSSEC.

DNSSEC Queries and Responses will be matched by DQRM using XID and QType (RR) only.

Do not use Asymmetric Mode since Queries may not be seen.

DNSSEC Queries and Responses will be matched by DQRM using XID, QType (RR) and D0 bit =1. Use this option with care. DNSSEC requests to servers that don’t support it may result in a DO bit mismatch but an otherwise valid Response. If unsure, enable this during Detection Mode and look for inbound drops. If excessive disable. DNSSEC Message Type Match will protect from DNSSEC Response Floods. For additional support, contact Fortinet.

Do not use Asymmetric Mode since Queries may not be seen.

Query with Resource Record Type All/ANY (255) results in dropped Query with TC=1 Response to force TCP. Use with care. Most servers that support ANY Queries will do this automatically or respond to an ANY Query with a single A-Record. Use the DNS QType All Threshold.

Both standard and DNSSEC Responses from DNS servers can be fragmented into 3 packets. The first fragment normally contains the needed FQDN, Type an TTL information used to populate the LQ and TTL tables. FortiDDoS will attempt to parse the first fragment so that:

• LQ and TTL are populated

• DQRM can determine match/mismatch to the Query

• DNSSEC info is seen

Use this in Symmetric or Asymmetric Modes.

• Blocklist — Blocklist blocks the FQDN file list/Manual entries /Regex expressions at all times. Blocklist is the default option.

• Allowlist — Allowlist FQDN file list/Manual entries /Regex expressions allows only those Queries to pass at any time unless modified by Drop Blocklist/Allowlist Unmatched Query Under Flood.

The Drop Allowlist Unmatched Query Under Flood options appear if Allowlist is selected for FQDN Control List Type.

Enabling this feature allows all Queries during normal traffic but will allow only the specified FQDN file list/Manual entries /Regex expressions to pass when the system is under DNS flood.

Opens a file selection dialog to upload files. Files must be CSV or TXT format with one FQDN per line. Maximum 150,000 entries.

When the file is successfully uploaded the File name and FQDN count is displayed.

Duplicate FQDNs will automatically be removed.

Note:

Upload checks for string errors:

• TLD must be at least 2 characters (.cn is valid, .n is not)
• Currently “_” (underscore) is not supported
• Currently Unicode characters are not supported

Disable.
DQRM depends on seeing both Queries and Responses. If these are not seen, DQRM will have unexpected results and may block users from the Internet.

Disable.
The LQ table is populated based on seeing an r-code=0, 'good' DNS Response. This may not be available with asymmetric traffic.

Disable.
The TTL table is populated based on seeing an r-code=0, "good" DNS Response. This may not be available with asymmetric traffic.

Enable inbound if this leg of the traffic might see inbound DNS Queries

Enable as for normal traffic suggestions.

Disable. Cache is created from outbound Responses which may not be seen.

Enable TC=1 if seeing inbound traffic.

Enable if seeing inbound traffic.

Disable

Optional.
But disable on outbound leg if installed there. For this reason, this feature is not recommended for HA pairs where one system is on primary inbound and one is on primary outbound. See Fortinet support for more details

Enable if seeing inbound traffic.

Enable if seeing inbound traffic.