DNS Profile

DNS Profile

Use the DNS Profile to configure various DNS parameters and ACLs. Always assign an DNS profile to SPP.

All DNS Profile parameters can be used with symmetric or asymmetric traffic.

You can create a maximum of 64 DNS Profiles.

DNS mitigation is complex and varies depending on many factors such as what is being protected, including:

Authoritative DNS Servers
Recursive DNS Servers
Resolvers such as firewalls and outbound proxies that may use encrypted UDP DNS (like FortiGuard)
Non-DNS servers and infrastructure

Contact Fortinet for expert help on DNS.

DNS 0x20

DNS 0x20 is a method Recursive DNS servers use to improve resistance to DNS Cache Poisoning attacks among other things. While it has not been ratified by the IETF, it is in wide use. “0x20” creates randomized capitalization of the FQDN so that what would normally be sent (fortinet.com) is sent as ForTiNEt.cOM or fOrTinET.Com. The Query sender expects to see exactly the same capitalization in the Response or the Response is rejected. FortiDDoS uses several tables that need to react and match, drop and or pass 0x20 packets correctly.

From Release 6.3.0, the following is done:

Allowlist/Blocklist and manual FQDN ACL entries: All entries from file or manual are stored as lower-case only. When matching, Queries are converted to lower-case to check the match. Allows packets retain the original 0x20 format. Regex entries should allow upper and lower-case characters.
LQ/TTL table: All entries are stored as lower-case only. When matching, Queries are converted to lower-case to check the match. Allows packets retain the original 0x20 format.
Cache and DQRM tables: Entries are stored as 0x20 since the Response must exactly match the Query.

DNS 0x20 is automatic with no feature or anomaly setting.

DNS Anomalies Feature Control

Use the DNS Anomalies Feature Control section to configure DNS traffic anomaly detection. DNS Anomalies (and DNS Feature Controls) cannot be used in SPPs that contain devices such as Firewalls, Proxies, Gateways, mail servers that produce encrypted DNS packets destined for port 53 on their cloud services. For example, FortiGate firewalls by default send encrypted DNS packets to FortiGuard UDP Port 53. The FortiGuard DNS port can be modified to UDP port 8888 which is recommended but other products maynot be modifiable.

FortiDDoS interprets these encrypted DNS packets as anomalies and drops them. This can result in no Internet access for any LAN-based client.

Devices sending encrypted packets should be isolated in a separate SPP with DNS Anomaly and Feature Controls disabled.

In order to discover if these devices exist in the SPP and identify the IP addresses of the devices, in Detection Mode, enable all DNS anomalies. In Log & Report > Log Access > DDoS Attack Log: Top Attacks widget, with the direction set to Outbound, look for DNS Anomaly drops across a wide range of anomalies. If you are seeing Outbound DNS Anomaly drops, drill down (using page icon to the right of Attack description) to see the detailed attack logs. Drill down further to see the Protected IPs. These will be the devices sending encrypted DNS. Move these IP addresses to a separate SPP and disable all DNS Anomalies and Features for that SPP.

DNS Anomalies settings:

Setting	Description
Header Anomaly	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 Anomaly	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. RA Bit Set — DNS query with the recursion allowed (RA) bit set. The RA bit is set in responses, not queries.
Response Anomaly	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.
Bufferoverflow Anomaly	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.
Exploit Anomaly	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.
Info Anomaly	Type All/Any Used — Detects a DNS request with request type set to ALL (QTYPE/Resource Record = 255).
Data Anomaly	Extraneous Data — a query/response with excess data in the packet after valid DNS data. TTL too Long — a response where the TTL value is greater than 7 days (or 604800 seconds) is dropped. The current recommendation is to disable this since some popular websites may have longer TTLs. 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.

DNS Feature Controls

Use this section to configure DNS feature controls. For an overview of DNS features, see Understanding FortiDDoS DNS attack mitigation.

There are two network conditions where most DNS Feature controls must be disabled:

If the FortiDDoS appliance is operating in Asymmetric traffic mode and cannot see both directions of the DNS traffic. See Understanding FortiDDoS Asymmetric Mode for more information.
In SPPs that contain Firewalls, Proxies, Gateways, mail servers or other equipment that generates encrypted DNS packets.

DNS Feature Controls settings:

Setting	Description
Authentication Direction	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.
Flood Mitigation Mode Inbound	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. Note: Both the TC Equal One and DNS Retransmission validations are very effective against direct spoofed source Query floods protecting Recursive and Authoritative DNS servers as well as other infrastructure from spoofed IP floods. In both 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.
Flood Mitigation Mode Outbound	The Flood Mitigation Mode Outbound options appear if 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. Note: Both the TC Equal One and DNS Retransmission validations are very effective against direct spoofed source Query floods protecting Recursive and Authoritative DNS servers as well as other infrastructure from spoofed IP floods. In both 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. DNS Retransmission
Match Response With Queries(DQRM)	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.
Validate TTL For Queries From The Same IP	During normal traffic, every Destination IP (client IP), FQDN and TTL from good Responses is extracted and stored in the TTL table. The TTL is decremented as normal. Under flood, if the Same IP Queries the same FQDN before the TTL has expired, the Query is dropped.
Generate Response From Cache Under Flood	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).
Allow Only Valid Queries Under Flood(LQ)	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.
Block Identified Sources	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.
Duplicate Query Check	If Enabled: FortiDDoS drops multiple identical Queries in rapid succession but below the Query thresholds. If Disabled: Only Query Thresholds are used for mitigation.
Options When No Cache Match	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.
DNS Fragment	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.
Domain Reputation	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.
Forbid DNSSEC	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 Message Type Match	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 Require Response After Query	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.
Force Qtype ANY Query Use TCP	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.
DNS Message IP Fragment Try Best	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.
FQDN Control List Type	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.
Drop 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.

FQDN Files

Each SPP Profile allows you to add large numbers of FQDNs (maximum 150k) as CSV files to the Blocklist or Allowlist enabled in the DNS Feature Controls.

The FQDN Control List (Blocklist or Allowlist) is processed before any other DNS feature, anomaly or validation. For example, a DNS Query that is allowed to pass by the DNS Control List and gets a good Response will populate the LQ and TTL tables with FQDN, Type, Class and TTL.

File format is CSV or TXT, with one FQDN per line.

Options	Description
Upload	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
Name/Check Domain	Enter a domain (full FQDN, no wildcards allowed) and the system will respond with present or absent message.

Options

Description

Upload

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

Name/Check Domain

Enter a domain (full FQDN, no wildcards allowed) and the system will respond with present or absent message.

FQDN List

Create individual FQDN (maximum 1024) or Regex (maximum 128) entries here. These entries follow the FQDN Control List Type settings selected for the DNS Feature Controls, Allowlist or Blocklist. Note, this means you cannot have a Blocklist with FQDN List exceptions, for example.

FQDN List entries are not searchable from the FQDN file search, instead you can filter for FQDN List entries using the Add Filter function.

Regular entries require a full FQDN as pictured above.

To create a regex entry, click Regular to select Regex entry type, then click Create New.

Regex entries follow regex syntax, with a maximum length of 255 characters. Longer strings will be truncated without any error message. FortiDDoS evaluates all regex expressions for matches simultaneously, so longer strings can be broken up and separate regex can be entered in any order.

If the FQDN Control List Type is set to Blocklist, for example, the Combined regex above would:

Block any right-most subdomain if it contains 4 or more digits 0-9 (with or without any other characters)
Block any right-most subdomain if it contains 8 or more characters a-Z, (with or without any other digits)
Block any right-most subdomain if it contains 9 or more characters or digits, and special characters “-“ or “_” (all legal domain characters). For example, Mirai-based subdomain floods include a 12 character (a-Z, 0-9 character set at least) subdomain.

Interaction between FQDN Control List Type and Drop Allowlist Unmatched Query Under Flood

The DNS Resource Record Type ACL

The DNS Resource Record Type ACL allows blocking of any number of DNS Resource Record Types by QTYPE number. The DNS QTYPE field allows 65,536 TYPES of which fewer than 100 are defined and less are in common use.

The following Qtypes can be blocked:

Known Qtypes which are not needed (for example: ALL/ANY=255)
Deprecated Qtypes (for example: NULL=10)
Undefined Qtypes (for example: 32770-65279)

DNS Resource Record Type ACLs are defined in numeric ranges. A single ACL entry has DNS Resource

Record Type Start = DNS Resource Record Type End.

Guidelines for use with SPPs that contain Firewalls, Proxies, Gateways, Email servers and other outbound generators of DNS Queries.

Many Firewalls, including FortiGates, send encrypted SSL-over-UDP DNS Queries to destination UDP port 53. FortiDDoS sees these as DNS anomalies and drops them, preventing Internet access for users behind the firewall or other proxy devices. SSL-over-UDP DNS Queries do not meet any RFC but our experience is that they are standard industry practice for many firewalls, proxies, gateways, mail servers and other equipment that uses cloud services to detect malicious domains. Some firewalls are adopting DNS-over-HTTPS or DNS-over-TLS, but, in many cases, the equipment is unknown or is not capable of changing the Queries from UDP port 53. In this case, the Firewall or other equipment sending these encrypted DNS Queries should be isolated in a separate SPP with all DNS anomalies and DNS Feature controls disabled.

To determine if the firewall is sending encrypted DNS to UDP Port 53, in Detection Mode, enable all DNS Anomalies. Leave the system for at least a day. Then go to Dashboard Top Attacks. Select the SPP you are concerned with and set the direction to Outbound. Look for several different types of DNS Anomaly drops. The number of drops is not a concern, it is the number of types of drops. If you see Invalid Opcode, QDCount not One in Query, Class No IN or other Anomalies, it is likely the firewall (email server, WiFi gateway, etc.) is using encrypted DNS packets.

Settings	Guidelines for Symmetric traffic (or Asymmetric where FortiDDoS sees all traffic)	Guidelines for Asymmetric Mode, where FortiDDoS does not see all traffic.
Match responses with queries (DQRM)	Enable/disable the DNS query response match (DQRM) table. Enable on all SPPs that do not carry encrypted DNS Queries.	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.
Allow only valid queries under flood (LQ)	Enable/disable the legitimate query (LQ) table. LQ should normally be enabled ONLY on SPPs containing public Recursive or Authoritative DNS servers. It has little value for SPPs sending outbound Queries like firewalls and proxies.	Disable. The LQ table is populated based on seeing an r-code=0, 'good' DNS Response. This may not be available with asymmetric traffic.
Validate TTL for queries from the same IP under flood	Enable/disable the time-to-live (TTL) table. TTL validation should normally be enabled ONLY on SPPs containing public Recursive or Authoritative DNS servers. It has little value for SPPs sending outbound Queries like firewalls and proxies.	Disable. The TTL table is populated based on seeing an r-code=0, "good" DNS Response. This may not be available with asymmetric traffic.
DNS UDP Anti-spoofing Method inbound/outbound	Enable/disable anti-spoofing checks for inbound and outbound UDP DNS traffic. This can be used for all types of services. See firewall notes in second column.	Enable inbound if this leg of the traffic might see inbound DNS Queries
DNS flood mitigation mode inbound/outbound	Specify the antispoofing method if the source IP address is not already in the legitimate IP table (LIP): Force TCP (TC=1)—Return a DNS response to the client that has the DNS Truncate bit set and no response record data. A properly implemented DNS client will respond to the spoofed response by retrying the original DNS query using TCP port 53. TC=1 reduces the amount of inbound traffic, particularly for Authoritative DNS servers. If you are protecting authoritative servers, use this. This is recommended for protecting Recursive servers. DNS Query Retransmission—Drop packets and test for valid retransmission. A valid client is expected to retransmit the Queries within preset time windows. DNS Query Retransmission reduces the amount of outbound traffic generated by FortiDDoS. If your outbound traffic is limited, use this.	Enable as for normal traffic suggestions.
Generate response from cache under flood	Enable/disable DNS caching. Generally, more valuable for DNS Authoritative servers and may assist Recursive servers under attack. No valid for outbound gateways, firewalls, etc.	Disable. Cache is created from outbound Responses which may not be seen.
Force TCP or forward to server when no cache response available	If DNS caching is enabled ('Generate Response From Cache Under Flood' setting above), one of the following behaviors must be configured: Force TCP (TC=1)—Return a DNS response to the client that has the DNS Truncate bit set and no response record data. A properly implemented DNS client will respond to the spoofed response by retrying the original DNS query using TCP port 53. Use with Authoritative DNS Servers. Forward to Server—Forward the DNS query to the DNS server. Use with Recursive Servers If DNS caching is disabled, this setting is hidden and by default it will forward the DNS query to the DNS server.	Enable TC=1 if seeing inbound traffic.
Duplicate query check before response	Enable/disable checks for repeated queries from the same source. If enabled, under non-flood conditions, the system checks and drops repeated UDP/TCP queries from the same source if it sends them at a rate greater than 3 per second. Under flood conditions, the duplicate query check is done for TCP and not for UDP.	Enable if seeing inbound traffic.
Block identified sources	Enable/disable source IP address blocking periods for violators of any DNS-protection feature (ACL, anomalies, or flood meters). Disabled by default. DNS floods are often spoofed, so we do not recommend blocking an identified source to avoid punishing legitimate clients. Instead, we recommend you rely on the other DNS protection methods. They make packet-by-packet determinations and are not prone to false positives The configuration is open, allowing you to enable source blocking if you want to experiment with it in your network. If enabled, when a threshold is reached, packets are dropped and the identified sources are subject to the Blocking Period for Identified Sources configured on the Global Settings > Settings page. Layer 7 > DNS > Query Per Source > DNS Query Per Source Egress Max Packet Rate/Sec Layer 7 > DNS > Suspicious Sources > Packet Track Per Source Egress Max Packet Rate/Sec	Disable
Restrict DNS Queries to Specific Subnets	Enable/disable restriction to DNS queries from unwanted sources from the Internet. This feature allows service providers to protect their recursive or open DNS resolvers. In a typical deployment, the service provider will keep their open resolvers on the 'LAN' or the protected side of FortiDDoS and their own customers will be on the Internet side. On the Internet side, there will also be rogue DNS clients who send unwanted DNS query floods. To ensure that the DNS queries are only allowed from the service provider’s customers, the service provider must add those subnets into the Restricted Subnets list. By restricting the DNS queries to specific subnets, the service provider can avoid responding to unwanted queries and thus protecting DNS infrastructure from getting overloaded.	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
DNS Fragment	Enable/disable checks for DNS packets.	Enable if seeing inbound traffic.
Domain Reputation	Enable/disable domain reputation. If enabled, domain names in DNS query and response will used to match items in the Domain reputation database file. Domain Reputation updated through FortiGuard.	Enable if seeing inbound traffic.
DNS Resource Record Type ACL	Config range number of Resource Record Type.	Enable if seeing inbound traffic.

To configure with CLI:

config ddos spp dns profile

edit <dns profile name>

set dns-headeranomaly-feature-control {illegal-flag-combination invalid-op-code sp-equals-dp incomplete-dns}

set dns-queryanomaly-feature-control {qr-bit-set null-query qdcount-not-one-in-query ra-bit-set}

set dns-responseanomaly-feature-control {qclass-in-reply qtype-in-reply qr-bit-not-set qd-count-not-one-in-response}

set dns-bufferoverflow-anomaly-feature-control {long-name-length long-label-length tcp-message-long udp-message-long}

set dns-exploitanomaly-feature-control {premature-end-of-packet class-not-in zone-transfer pointer-loop empty-udp tcp-buffer-underflow}

set dns-infoanomaly-feature-control {enable/disable}

set dns-dataanomaly-feature-control {extraneous-data long-ttl invalid-class-type short-name-length multiple-opt-rr}

set dns-authentication-direction {none inbound outbound inbound-outbound}

set dns-flood-mitigation-mode-inbound {TC-equal-one dns-retransmission}

set dns-flood-mitigation-mode-outbound {TC-equal-one dns-retransmission}

set match-response-with-queries {enable/disable}

set validate-ttl-for-queries-from-the-same-ip {enable/disable}

set generate-response-from-cache-under-flood {enable/disable}

set allow-only-valid-queries-under-flood {enable/disable}

set source-blocking-in-dns {enable/disable}

set duplicate-query-check {enable/disable}

set force-tcp-or-forward-to-server {forcetcp/forward-to-server}

set aggressive-aging-incomplete-request {enable/disable}

set dns-fragment {enable/disable}

set domain-reputation {enable/disable}

set forbid-dnssec {enable/disable}

set dnssec-message-type-match {enable/disable}

set dnssec-require-response-after-query {enable/disable}

set force-any-query-use-tcp {enable/disable}

set dns-msg-ipfrag-parse-try-best {enable/disable}

set fqdn-control-list-type {allowlist/blocklist}

set block-allowlist-unmatched-query-under-flood

config fqdn-regex-list

edit <rule name>

set value <regex expression>

end

config fqdn-regular-list

edit <rule name>

set value <FQDN (lower-case characters, numbers, - _ only)

end

config dns-resource-record-type-acl

edit <rule name>

set dns-resource-record-type-start <1-65535>

set dns-resource-record-type-end <1-65535>

end

DNS Profile

Use the DNS Profile to configure various DNS parameters and ACLs. Always assign an DNS profile to SPP.

All DNS Profile parameters can be used with symmetric or asymmetric traffic.

You can create a maximum of 64 DNS Profiles.

DNS mitigation is complex and varies depending on many factors such as what is being protected, including:

Authoritative DNS Servers
Recursive DNS Servers
Resolvers such as firewalls and outbound proxies that may use encrypted UDP DNS (like FortiGuard)
Non-DNS servers and infrastructure

Contact Fortinet for expert help on DNS.