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:
Contact Fortinet for expert help on DNS. |
Understanding DNS Mitigation
DNS DDoS mitigation complexity arises from the variety of attack types encountered and the diverse services needing protection. It is crucial to configure DNS Profiles for each Service Protection Profile (SPP).
|
Before proceeding with DNS configuration, Thoroughly review this section or seek assistance from Fortinet support. |
DNS Profiles and automatically-learned Thresholds aim to safeguard:
-
DNS Authoritative Servers hosted in your network accept inbound DNS Queries and send Responses outbound. They are susceptible to DNS Query floods which have been growing rapidly since early 2023.
Authoritative DNS Servers are primarily subject to DNS Query Floods
-
DNS Resolvers in firewalls and other outbound proxies, send outbound Queries and receive inbound responses. Many firewalls, outbound proxies, WiFi gateways and email servers encrypt these queries and Responses using proprietary encryption. See below for more information.
DNS Resolvers are primarily subject to DNS Response floods.
-
Combination DNS Servers (often called “Split-brain” or “Split-Horizon” servers) act as Authoritative DNS servers to inbound Queries and as Resolvers for inside clients and may also encrypt the Resolver Query/Responses.
-
DNS Recursive Servers are seldom seen in non-ISP networks. Recursive DNS servers will not be covered in this document. If you need DDoS protection for a Recursive server, please contact Fortinet.
-
All other infrastructure, even unused IPs are subject to DNS Response Floods because these floods are large enough to disrupt the network, even if not aimed at specific services.
DNS Mitigation is also affected by network design, encryption settings and user DNS Server settings:
-
If FortiDDoS is on one leg of an asymmetric traffic network:
-
Some DNS Response Flood mitigations must be disabled but Thresholds continue protection.
-
Some DNS Query Floods are more difficult to mitigate but Release 7.0.1 DNS LQ Populate will guard from these floods.
-
-
As above, many devices that originate DNS Queries outbound will encrypt the Queries over UDP 53. FortiDDoS cannot decrypt the proprietary encryption used and falls back to thresholds for protections. If possible, moving these services to DoH or DoT moves the encryption to other UDP or TCP ports, allowing FortiDDoS to use its full DNS mitigation capabilities.
-
DNS Servers that allow wildcard domains seriously compromise DDoS Query Flood mitigation. Most DDoS Query Floods use random subdomains, like “this-is_junk.example.com”. If a wildcard is “*.example.com”, the DNS server will respond to this Query with a good Rcode=0 Response or a CNAME Response. FortiDDoS is then unable to distinguish between legitimate and NxDomain Queries and falls back to Thresholds and Source validations which are not as accurate as FQDN matching (see DNS LQ Populate).
For all Settings below, recommendations for use with various services and symmetric or asymmetric traffic will be included.
The DNS Features below will be grouped into four sections for clarity.
-
DNS Anomalies
-
DNS Response Flood Mitigation
-
DNS Query Flood Mitigation
-
DNS ACLs
DNS ACLs are the first checks in DNS packet flow, followed by the other above in descending order. However, DNS ACLs are not used very often, so are described last, below.
The features shown in each section may not be grouped together in the GUI for the DNS Profile. Be sure you are using the matching GUI feature described in each section.
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 packet anomaly detection. DNS Anomalies may not be usable in SPPs that contain devices such as Firewalls, Outbound Proxies, WiFi gateways, mail servers, or commercial DNS resolvers like InfoBox, that use web or domain filtering.
These products usually encrypt DNS Queries to their vendor DNS services (like FortiGuard) but continue to use UDP 53. FortiDDoS cannot inspect this proprietary encryption and enabling DNS Anomalies can block all DNS Responses, blocking internet access for local users.
Encrypted DNS also prevents the use of some DNS mitigations which will be described below.
Devices sending encrypted packets should be isolated in a separate SPP with DNS Anomaly and Feature Controls disabled.
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 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.
Alternatively, most devices and their proprietary DNS services now support DoH or DoT (or even DoQUIC). Moving the DNS traffic to one of these newer and more secure standards will greatly enhance FortiDDoS’ ability to mitigate both DNS Query and Response Floods.
DNS Anomalies settings:
|
Setting |
Description |
|---|---|
| Header Anomaly |
|
|
DNS Known Opcode Anomaly |
Expert use only. Do not enable. Contact Fortinet with questions. Status — Intended to get DNS server messages, this opcode has never been implemented. Notify — A NOTIFY message is sent from a Primary DNS server to notify secondary servers to initiate Zone Transfer updates for a specific domain. It looks very similar to a Query, with the exception that the Opcode and the secondary servers are expected to Respond before the initiate the Zone Transfer. Update — This Opcode was intended to allow a Primary Authoritative DNS server to update specific domain resource records in secondary servers without Zone Transfers. The message format, CLASS, Opcode, and Rcodes are completely different from “normal” DNS messages and to the best of our knowledge, this has not been implemented. DSO — DNS Stateful Operations – This Opcode is intended for use with session-based DNS like DNS-over-TLS (DoT). If this Opcode is in use, the DNS messages are already encrypted and cannot be decodes by FortiDDoS and all DNS anomalies must be disabled. Note: DNS Known Opcode Anomaly drops will be shown as DNS Header Anomaly drops in graphs and logs. |
| Query Anomaly |
|
| Response Anomaly |
|
| Bufferoverflow Anomaly |
|
| Exploit Anomaly |
|
| Info Anomaly |
|
|
Data Anomaly |
|
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 coxntain Firewalls, Proxies, Gateways, mail servers or other equipment that generates encrypted DNS packets.
These conditions will be highlighted for each feature below.
The features below will be grouped into the following areas which do not necessarily match the order of the features shown on the GUI.
-
DNS Response Flood Mitigation. This is the most common type of attack on all infrastructure. The features in this group are affected by both asymmetric traffic and non-RFC encrypted DNS from firewalls and other outbound Proxy and commercial DNS Resolvers.
Please see DNS Anomalies Feature Control above to discover if your devices are using non-RFC encrypted DNS.
Moving Firewall / resolver DNS ports from UDP 53 to the following greatly improves FortiDDoS’ ability to mitigate DNS Response Floods rapidly and accurately:
-
UDP 853 or 8000 (FortiGate proprietary encryption) or
-
DoT (UDP or TCP 853 RFC-standard encryption) or
-
DoH (TCP 443 RFC-standard encryption)
-
-
DNS Query Flood Mitigation. These floods are usually seen only on Authoritative DNS Servers but is also generally harmless to include in any SPP. This flood mitigation is not affected by asymmetric traffic nor encrypted DNS.
-
DNS ACLs. DNS ACLs should be used by DNS experts only, and used to enhance DNS Server protection.
DNS Response Flood Feature Controls
|
Setting |
Description |
|---|---|
|
Match Response With Queries (DQRM) |
Always disable in Asymmetric traffic. For Symmetric traffic: Enable this always for all SPPs where there is no encrypted DNS over UDP 53. 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.
DQRM protects 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 Note: Many firewalls encrypt DNS traffic over UDP 53, particularly for vendor web and domain filter services. Please see DNS Anomalies Feature Control above to discover if devices in an SPP are using encrypted DNS. If encrypted DNS to UDP 53 is present in the SPP, disable DQRM since it cannot decrypt vendor encryption. DNS Rcode Thresholds in SPP > Thresholds will protect from DNS Response Floods. If DQRM is disabled because of encrypted DNS, Symmetric or Asymmetric Traffic considerations below are irrelevant. For Asymmetric Traffic: Disable this option. If FortiDDoS cannot see all inbound and outbound DNS Queries and Responses, users will be blocked from the internet. |
|
DNSSEC Message Type Match |
As above, do not use in SPPs with encrypted DNS. Do not use if system is in Asymmetric Mode. DNS Rcode Thresholds in SPP > Thresholds will protect from DNS Response Floods. Enable in Symmetric Mode. DNSSEC Queries and Responses will be matched by DQRM using XID and QType (RR) only. |
|
DNSSEC Require Response After Query |
Expert Use Only – disable in normal use. As above, do not use in SPPs with encrypted DNS. Do not use if system is in Asymmetric Mode. DNS Rcode Thresholds in SPP > Thresholds will protect from DNS Response Floods. DNSSEC Queries and Responses will be matched by DQRM using XID, QType (RR) and D0 bit =1. |
|
DNS Message IP Fragment Try Best |
Do not use in SPPs with encrypted DNS over UDP 53. Can be used in Symmetric or Asymmetric Mode. Responses from Authoritative DNS servers supporting EDNS0 can be fragmented into as many as 3 packets. The first fragment normally contains the needed FQDN and XID information that can be matched to DQRM. |
DNS Query Flood Feature Controls
The following features can be used in Symmetric or Asymmetric Mode and in SPPs that see encrypted DNS, unless otherwise indicated.
| Setting | Description |
|---|---|
| Force Qtype ANY Query Use TCP |
Expert Use Only. Leave disabled unless you know your DNS Server does not support this feature already. Query with Resource Record Type All/ANY (255) results in dropped Query with TC=1 Response to force TCP. Most servers that support ANY Queries will do this automatically or respond to an ANY Query with a single A-Record. DNS UDP and TCP QType All Thresholds protect from any flood. |
| Duplicate Query Check |
Expert Use Only. Leave disabled. If Enabled: FortiDDoS drops multiple identical Queries in rapid succession but below the Query thresholds. If Disabled: Only Query Thresholds are used for mitigation. DNS Query retransmission timers are very vague in the RFCs, stating a “reasonable” time. A busy DNS server may see several rapid retransmissions without Responding. These will be blocked by FortiDDoS unnecessarily. DNS Threshold will see real attacks. |
| Block Identified Sources |
Enable this setting. When enabled, the Thresholds for DNS Query per Source and DNS Suspicious Sources are enforced, and Sources are displayed in logs. Query per Source Floods are usually intended to use your DNS Server(s) to create a DNS Amplified Reflection Flood back to that Source IP, which is the real target of the attack. If Disabled, the Thresholds for Queries per Source and DNS Suspicious Sources are not enforced and this type of flood may be missed. |
| Allow Only Valid Queries Under Flood(LQ) |
This feature has dependencies. Use this table to decide the appropriate settings. Using Global LQ Populate is highly recommended.
Using with Service Protection Policies:
LQ without DNS LQ Populate (symmetric traffic only) This option is no longer recommended since:
The (smaller) LQ table is populated with:
LQ with DNS LQ Populate (symmetric or asymmetric traffic) The (very large) LQ table is populated with FQDNs (example.com) from Queries and validated by:
Note: If DNS LQ Populate is in use, the DNS Profile FQDN Files, FQDN Regular and FQDN Regex described below are no longer required as Allowlist, except in very rare situations. They can be used as Blocklists if desired. Contact Fortinet if unsure. LQ only collects data in normal traffic but under flood, the first check done is a match of the FQDN in LQ with the FQDN in the Query. If these do not match, the Query is dropped. Queries with matching LQ are allowed to pass through further checks. The feature stops very common random subdomain floods from the 1st packet while allowing legitimate Queries to proceed. There are additional LQ options in Global Protection > DNS LQ Populate. |
|
LQ Populate Domain |
Expert use. Disable UNLESS you are using DNS LQ Populate AND this SPP hosts an Authoritative DNS Server. If those conditions are true, you can enter the top-level domains from this server (example.com, example.gov, example.org) to reduce FortiDDoS validation traffic. Please see Global Protection > DNS LQ Populate. |
|
FQDN Validation Resolver |
Expert use. Disable UNLESS you are using DNS LQ Populate AND this SPP hosts an Authoritative DNS Server. If those conditions are true, you can enter the IP addresses of the protected Authoritative DNS Servers in this SPP so they are used for FQDN validation. Please see Global Protection > DNS LQ Populate. |
|
Validate TTL for Queries From the Same IP |
Obsolete. Disable (default). 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 |
Expert use with limited application – Disable. Under flood FortiDDoS can respond to legitimate Queries from its own cache. If FortiDDoS is mitigating Query floods correctly, the DNS server will not be overloaded and will not need this feature. 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). |
|
Options when No Cache Match |
Related to above and can be ignored if Generate Response from Cache under Flood is disabled. 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, requests 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. |
|
Authentication Direction |
The Authentication Direction determines if Source Address validation is attempted. These options only apply after DNS Query packets have passed the other checks above.
Other options should not be used.
|
|
Flood Mitigation Mode |
Depending on the settings above, this option may or may not show and have directionality. If Authentication Direction above is: None – This option does not show Inbound (recommended) - Flood Mitigation Mode Inbound. Outbound (never recommended) - Flood Mitigation Mode Outbound. Inbound Outbound (never recommended) – both options will show. Flood Mitigation Mode Options: TC Equal One (use this in all cases) - When DNS UDP Query floods are detected, the Queries are dropped and a TC=1 DNS Response is sent to each Source. A TC=1 Response is a request for the Source to retransmit the Query in TCP. Spoofed Sources cannot retransmit in TCP 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: A few DNS servers are set up to refuse TCP Queries which violates DNS RFCs. Understand your DNS server settings. Contact Fortinet if you server does not support TCP. DNS Retransmission (do not use) — 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 frequently produces false-positives and false-negatives since DNS RFCs are very vague on appropriate retransmission intervals. Transparent Proxy — Do not use - 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 without using state tables. 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, DNS LQ Populate will offer the best protection. other mitigations below will add protection.
|
DNS ACLs
| Setting | Description |
|---|---|
| Domain Reputation |
Enable if you have purchased FortiGuard Domain Reputation Service. When enabled, choose any or all of the following:
Note: If for any reason FortiDDoS cannot access FortiGuard (network issues or end-of-subscription, for example) the Domain Reputation database is not removed but becomes “static” with no updates. Since the database content is dynamic, the lack of updates can cause false-positive drops, the longer the database ages. Fortinet strongly recommends disabling the Domain Reputation options in all IP Profiles should this scenario occur. See System > FortiGuard for license information and additional settings. A FortiGuard Domain Reputation subscription is not a “signature’ subscription like other vendors need and is not required for DDoS mitigation. It is intended for users who do not have any other web or domain filtering devices behind FortiDDoS – usually MSSPs or ISPs. The FortiDDoS Domain Reputation database is a subset of FortiGate/FortiGuard web and domain filtering. |
| FQDN Control List Type |
Allowlist should not be used if for some reason DNS LQ Populate cannot be used. Blocklist can be used with LQ Populate to block a list of suspect domains/FQDNs. This is generally not required. |
| Drop Allowlist Unmatched Query under Flood |
Always enable if Allowlist is used, due to the above caveats. Disable this if Blocklist is used, as it would have no function. 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. |
| Forbid DNSSEC | Expert use only. A high percentage of DNSSEC traffic is common. Use only for SPPs where you expect no DNS Traffic. Drop any Query or Response that indicates the DNSSEC D0 bit=1 |
| Apply RR Type ACL Under Flood Only |
Use this option with DNS Resource Record Type ACLs. If RR ACLs are not configured, it has no effect. See the DNS Resource Record Type ACL first. If you create RR ACLs, you can elect to only enforce the ACLs under DNS flood. This lowers the risk of false-positive drops during normal traffic. |
|
DNS Fragment (Deny) |
If Enabled: Drop all DNS Fragments. Expert use only. DNS Response fragments are possible when local resolvers are communicating directly with Authoritative DNS Servers. Normally, local resolvers will communicate with local or vendor (like FortiGuard) Recursive DNS servers and fragments should not be seen. If you know this SPP never communicates with any Authoritative DNS server, this can be enabled. If Disabled: DNS Fragments are allowed, and DNS Fragment Thresholds will be used to detect/mitigate DNS Fragments. |
FQDN Files
|
From Release 7.0.1, FQDN Allowlist has effectively been replaced with Global Protection > DNS LQ Populate, providing much more automated population of legitimate FQDNs. Using Allowlist and DNS LQ Populate simultaneously is counterproductive. Only use Allowlist if your network or DNS Server design cannot use DNS LQ Populate. Allowlist/Blocklist setting determines the actions of FDQN Files, FQDN Regular entries and FQDN Regex entries simultaneously. If DNS LQ Populate is in use, you can use FQDN Files, FQDN Regular and FQDN Regex as Blocklists. Most users will not require these. |
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:
|
| 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) and/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 1: These entries follow the FQDN Control List Type settings selected for the DNS Feature Controls, Allowlist or Blocklist. This means you cannot have a Blocklist with FQDN List exceptions, for example.
Note 2: FQDN List and Regex entries are not searchable from the FQDN file search. Instead, you can filter for FQDN List entries using the Add Filter function.
FQDN Regular List
Enter domain names here if you need a small number of domains. Otherwise use FQDN files as above.
Create New for each FQDN entry. No wildcard entries are allowed.
Regular entries require a full FQDN as pictured above.
FQDN Regex List
Enter Regex strings here. Create New for each Regex entry.
|
|
International domain names (IDN) must be converted to punycode to be used in regex strings. For example, 中国.china-fortiddos.com must be converted to xn--fiqs8s.china-fortiddos.com. |
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. |
| 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.
|
| 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.
|
| 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):
|
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:
|
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 |
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.
|
Disable |
|
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>
next
end
config fqdn-regular-list
edit <rule name>
set value <FQDN (lower-case characters, numbers, - _ only)
next
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>
next
end
next
end