Understanding FortiDDoS DNS attack mitigation

This section includes the following information:

• DNS attack vulnerability overview
• FortiDDoS DNS amplified response mitigation overview
• FortiDDoS DNS protection module summary
• FortiDDoS DNS flood mitigation overview
• FortiDDoS DNS flood types
• FortiDDoS DNS deployment topologies
• Getting started with DNS mitigation

DNS attack vulnerability overview

DNS was designed for robustness and reliability, not security. It is vulnerable to multiple types of attacks that can compromise or take down a network. DNS Query Floods typically target DNS servers while DNS Reflected, Amplified Response Floods are used across all infrastructure. DNS Reflected Response Floods are in the top three by number of attacks and size of attacks every quarter. It is important all Service Protection Policies are protected from DNS floods. Some of these attacks are described below.

DNS query floods

DNS Query Floods can attack DNS servers using the two methods described below:

• Taking the server down or preventing others from getting responses from the server.

• Reflecting Responses from the server to flood specific targets. In many cases these “floods” are lower rate to avoid detection from administrators or DDoS services. The attacker uses thousands of DNS servers at the same time to generate large Response floods to the target.

The Authoritative DNS servers can be attacked directly or indirectly as described below:

• Directly by botted devices that spoof random Source IPs so they cannot be traced. These types of attacks normally attempt to take the DNS server offline but can also be used to reflect Responses to targets. In that case all devices use the same spoofed IP address (that of the target). Attack on Authoritative servers take advantage of DNSSEC options to create Responses as large as 4096 Bytes. Even an NxDomain (no answer) Response can be over 1500 Bytes.

• Indirectly via many Recursive servers. Attackers will allow the botted devices to use their default DNS server (usually the local ISP’s Recursive DNS server). The ISP Recursive DNS server forwards the Query to the target’s Authoritative DNS server. This adds complexity to the attack mitigation.

Recursive DNS servers can also be used to reflect attacks to targets from cached records or after resolving the FQDN via an Authoritative server.

Attackers use many manipulations to prevent various mitigations, such as the following examples:

• The Mirai botnet uses a 12 character random subdomain (xxxxxxxxxxxx.example.com, where x = 0-9 or a-z) to evade Response Rate Limiting in Recursive servers.

• Attackers may randomize Resource Records with good domain names to evade NxDomain rate limiting at the server or the target.

DNS servers are also susceptible to all other DDoS floods which may be trying to saturate connected links to block all traffic or to drive CPU exhaustion with various TCP and UDP floods.

You can use FortiDDoS DNS flood mitigation features to prevent query floods.

DNS response floods

DNS Response floods are reflected from Recursive or Authoritative DNS servers. They are always in the top three or quarterly attack statistics by both number of attacks and size of attacks. As of April 2020, there are over 1.7 million “open” recursive servers and countless millions of Authoritative servers that can be exploited to create Response floods.

FortiDDoS DNS amplified response mitigation overview

FortiDDoS offers the following mitigations for the target of DNS Response Floods:

• DNS Query Response Matching
  If FortiDDoS is seeing symmetric network traffic, it records all outbound Queries in the DQRM table. When the system sees a matching DNS Response, the table is cleared. If any Response arrives that has no matching Query in the table, it is immediately dropped. Unsolicited DNS Response floods are dropped from the first packet.
  Many DNS Responses will be fragmented. FortiDDoS inspects the first fragment to extract XID and 5-tuple information to match.
  

  Model	VM04	VM08	VM16	200F	1500F	2000F	1500E	2000E
  DQRM Size	2M	2M	4M	2M	8M	16M	4.5M	9M

  See Match Response with Queries (DQRM) and DNSSEC Message Type Match in the FortiDDoS DNS protection module summary.

• DNS Fragments
  FortiDDoS automatically learns the normal data rate of DNS first fragments and creates a System Recommended threshold. Responses will be rate-limited to the Threshold.
  See Scalar Thresholds: DNS Fragment UDP and TCP in Thresholds View.
  
• UDP Fragments
  Subsequent DNS fragments have no layer 4 information and will show as UDP Fragments. FortiDDoS learns, sets a threshold for and monitors UDP Fragments. Over threshold UDP Fragments are rate-limited.
  See Scalar Thresholds: UDP Fragments in Thresholds View.
  
• DNS Response Codes
  FortiDDoS automatically learns, sets thresholds for and monitors all 16 DNS Response codes (for example, 0 = good, 3 = NxDomain). Over-threshold Responses with specific Response Codes are rate-limited.
• Domain Reputation (optional subscription)
  Domain Reputation inspects Response FQDNs as well as Query FQDNs. Responses that match the Domain Reputation database are dropped. Domain Reputation is normally not required for enterprise environments.

FortiDDoS DNS protection module summary

FortiDDoS has the following protection modules for DNS (transport over TCP or UDP):

• Protocol anomaly rules
  Built-in and user-enabled rules filter malformed traffic and known protocol exploits. There is a special set of anomalies that can be detected in DNS traffic. For an overview of protocol anomalies, see Understanding FortiDDoS protocol anomaly protection.
• Rate meters and flood mitigation mechanisms
  For TCP, the DNS rate meters enforce rate limits (drops). For UDP, the DNS rate meters trigger flood mitigation responses that drop illegitimate queries but continue DNS services for legitimate user queries. For details, see FortiDDoS DNS flood mitigation overview.
• DNS Query Response Matching (DQRM)
  Blocks unsolicited responses and throttles duplicate queries (regardless of flood state). See FortiDDoS DNS flood mitigation overview.
• DNS FQDN Allowlist/Blocklist
  File/FQDN/Regex and DNS Resource Record ACL blocks or allows FQDNs and/or FQDN formats and DNS Resource Records. See DNS Profile.

The following two figures illustrate the order in which FortiDDoS applies its rules and actions for UDP and TCP DNS traffic, respectively.

FortiDDoS DNS flood mitigation overview

FortiDDoS mitigates DNS threats by applying tests to determine whether Queries and Responses are legitimate. These methods minimize illegitimate traffic from reaching protected DNS servers and maximize the availability of DNS services for legitimate queries during a flood. They also prevent DNS Response floods from disrupting the network.

To protect from DNS Query floods, FortiDDoS builds a baseline of DNS Query traffic statistics during normal traffic. During UDP Query floods, Validations of the Source IPs, FQDNs used, and TTL expiration are used to drop attack traffic. During TCP Floods Source IP Validation and various DNS Query Threshold rate-limiting is used.

To protect from DNS Response floods, FortiDDoS builds a baseline of DNS Response traffic statistics during normal traffic and stores DNS query and response data in tables. At all times (during non-flood and flood), the tables are used to validate Response traffic. The table below describes the system tables used for DNS attack mitigation.

DNS-related system tables

System Table	DNS Flood Mitigation
DNS Query Response Match (DQRM) table	Used for all DNS traffic—UDP or TCP. When it receives a DNS query, the system stores the DNS transaction details in the DQRM table. Table sizes vary by model. When it receives a response, it searches this table for a matching query. The table entry is cleared if there is a Query matching the Response. If the Response has no matching Query, FortiDDoS drops the unmatched Response. Drops are reported on the Monitor > DROPS MONITOR: SPP > Layer 7 > Flood Drops > DNS graph. The DQRM table response validation prevents DNS reflected amplification attacks. The DQRM can also be used to throttle repeated queries that would otherwise result in unnecessary server activity. The "Duplicate query check before response" option drops identical queries (same transaction details) that are repeated at a rate of >3/second. Drops are reported on the Monitor > DROPS MONITOR: SPP > Layer 7 > Flood Drops > DNS graph.
Legitimate Query (LQ) table	Used to mitigate UDP floods. When FortiDDoS sees a valid Response to a Query, the Query details are stored in the LQ table. THe LQ table stores from 128,000 to 2 million records depending on the model. Entries are cleared when the TTL expires unless refreshed by a new valid Query/Response. During a flood, the system drops queries that do not have entries in the table. Drops are reported on the Monitor > DROPS MONITOR: SPP > Layer 7 > Flood Drops > DNS graph.
TTL table	Used to mitigate UDP Query floods. When FortiDDoS sees a valid Response to a Query the query FQDN and Source IP; and TTL of the Response are stored in the TTL table. The table stores 2-35 million records, depending on the model. Entries are cleared when the TTL expires. Responses with TTL=0 are not added to the table. During a UDP Query flood, the system drops queries from the same Source IP for the same FQDN that have an entry in the table. It is not expected that a client would send the same Query again before the TTL expires. Drops are reported on the Monitor > DROPS MONITOR: SPP > Layer 7 > Flood Drops > DNS graph.
DNS cache	Used to mitigate UDP Query floods. When a valid Response to a Query is received, the system caches the response packets. It can store 64,000 to 1 million records, depending on the model. Entries are cleared when the TTL expires. During a flood, if the query passes the LQ and TTL checks, the response is optionally served from the cache and the query is not forwarded to the DNS server. This enables legitimate clients to get DNS results without adding load to the server that is being attacked. If there is no entry in the cache, you can configure whether you want the query to be forwarded to the DNS server or have FortiDDoS send a response with the TC flag set. The TC flag indicates to the client to retry the request over TCP. Drops are reported on the Monitor > DROPS MONITOR: SPP > Layer 7 > Flood Drops > DNS graph. Note: Cache Query drops may be the result of a Response from the Cache or because the Cache has sent a TC=1 request – they are not differentiated.
Source tracking table	Used for source flood tracking — UDP or TCP. Tracks DNS Queries per Source and Suspicious Sources. It drops packets that exceed the maximum thresholds and applies the blocking period for identified sources. Drops are reported on the Monitor > DROPS MONITOR: SPP > Layer 7 > Flood Drops > DNS graph.

Source tracking thresholds and TCP thresholds are rate limits, resulting in drops when the flood rate thresholds are crossed. For UDP, rate thresholds trigger mitigation mechanisms. Drops are based on results of the mitigation checks. The figure below illustrates the packet flow through mitigation mechanisms during a UDP flood.

FortiDDoS DNS flood types

The following table summarizes the types of DNS floods mitigated by FortiDDoS.

DNS Flood types

DNS flood types

DNS Flood Type	Thresholds
Query Flood	Abnormal rate of DNS UDP Queries. FortiDDoS automatically learns PPS rates for the following parameters which the use converts Thresholds by using Traffic Statistics and System Recommendations. In all cases, when thresholds are crossed the Query follows the UDP Query mitigation process above. UDP Query Thresholds include: DNS UDP Query DNS UDP Question Count DNS UDP MX Query DNS UDP ALL Query Abnormal rates of DNS TCP Queries are rate-limited by the TCP Query Thresholds for: DNS TCP Query DNS TCP Question Count DNS TCP MX Query DNS TCP ALL Query DNS TCP Zone Transfer Abnormal rates for DNS UDP and TCP Queries per Source and Suspicious Sources, are identified based on Query Thresholds for: Query per Source Suspicious Sources (Packet Track per Source) and identified Sources are blocked for a user-specified blocking period: Service Protection Policy > SPP > Blocking Period For Identified Sources (in seconds). Monitor > TRAFFIC MONITOR: Layer 3/4/7 > SPP > Layer 7 > DNS graphs show data rates for all of the above parameters. Monitor > TRAFFIC MONITOR: Layer 3/4/7 > SPP > Layer 7 > DNS graphs shows the drop information for: All TCP parameters Query per Source Suspicious Sources Monitor > DROPS MONITOR: SPP > Layer 7 > Flood Drops > DNS graph shows drop associated with all UDP parameters.
Suspicious Sources	The Suspicious Sources (Packet Track per Source) counter is incremented when a query is not found in the DQRM, when there are fragmented packets in the query or response, and when the response has an RCODE other than 0.

FortiDDoS DNS deployment topologies

FortiDDoS can be deployed to protect:

• Authoritative DNS servers that receive queries from the Internet.
• DNS recursive resolvers that send queries to and receive responses from Internet DNS authorities.

• All other network infrastructure. DNS Response floods are common, attempting to saturate they Internet link(s). DNS Query floods are less common but are also seen across all network infrastructure. A DNS Profile and DNS Thresholds (automatically set with all other Thresholds) should be created for all Service Protection Profiles.

The following figure shows a topology where FortiDDoS is deployed primarily to protect the authoritative DNS server for a domain. Under normal traffic rates, FortiDDoS builds a baseline of DNS traffic statistics and stores DNS Query and Response data in tables. The tables are used to validate response traffic.

DNS no flood: inbound queries

	Query	Response
UDP	Adds an entry to the DQRM table. Performs a duplicate query check to prevent unnecessary queries to the server.	Validates the response against the DQRM table. If there is an entry, the traffic is forwarded; otherwise, it is dropped. Updates the LQ table, the TTL table, and the DNS cache.
TCP	Adds an entry to the DQRM table. Performs a duplicate query check to prevent unnecessary queries to the server.	Validates the response against the DQRM table. If there is an entry, the traffic is forwarded; otherwise, it is dropped.

The following figure shows a topology where FortiDDoS is deployed in front of an internal DNS resolver that sends queries to and receives responses from the Internet. This type of deployment is useful for open resolvers where the DNS resolver is protected primarily from Internet-originating inbound reflection attacks.

FortiDDoS records Outbound Queries and validates inbound Responses. This deployment protects your network against DNS amplification attacks that result in unsolicited DNS response floods to targeted victims In a deployment like this, the unsolicited responses would fail the DQRM check and be dropped.

Note:

• DQRM checks will only work if FortiDDoS is deployed on networks with symmetric traffic or asymmetric network where both Internet links are passing through the same FortiDDoS.

• Most firewalls, outbound proxies, and WiFi gateways that use web filtering features for the LAN-side clients encrypt DNS Queries towards their cloud resolvers but use UDP Port 53. DQRM will not work correctly with encrypted DNS.
  Note this does not include DoT or DoH which is encrypted over other port that FortiDDoS does not monitor.

• Other mitigations such as DNS R-code Thresholds are available in these scenarios.

Contact Fortinet for additional assistance. DNS and DNS mitigation can be complex.

DNS query flood mitigation

The following shows how FortiDDoS mitigates a DNS query flood. It uses the DNS tables and LIP table to validate queries and responses.

	Query	Response
UDP	Validates against the LQ table. Under flood conditions, a query must have an entry in the LQ table or it is dropped. Validates against the TTL table. If a match is found, the TTL check fails and the packets are dropped. It is not expected that a client would send the same query before the TTL expires. Perform a lookup in the LIP table. If an entry exists, processing continues; otherwise, FortiDDoS drops the packets and tests the legitimacy of the source IP address. You can configure FortiDDoS to do so by performing a UDP retransmission challenge or by sending the requestor a response with the TC flag set. The TC flag indicates to the client to retry the request over TCP. Performs a lookup in the DNS cache. If found, the response to the query is sent from the cache and the query is not forwarded to the protected server. If not found, you can configure whether to forward the query to the server or to send a TC=1 response to force the client to retry using TCP. Adds an entry to the DQRM table.	Validates the response against the DQRM table. If there is an entry, the traffic is forwarded; otherwise, it is dropped. Updates the LQ table, the TTL table, and the DNS cache.
TCP	Drops packets according to thresholds. Adds an entry to the DQRM table. Performs a duplicate query check to avoid unnecessary queries to the server.	Validates the response against the DQRM table. If there is an entry, the traffic is forwarded; otherwise, it is dropped.

Getting started with DNS mitigation

DNS and DNS mitigation is complex with different requirements for the following: Small and large enterprise, hosters, MSSPs, ISPs Symmetric and Asymmetric traffic networks Presence of encrypted DNS over UDP 53 from firewalls and other outbound-origination products like proxies, WiFi gateways and email servers Whether the Service Protection Profile is in Detection or Prevention Mode Ask for assistance if you are not an expert on DNS and FortiDDoS DNS mitigations.

The following instructions describe DNS configuration for an enterprise DNS Authoritative Server in a symmetric traffic environment. This configuration may not be valid for other types of servers and networks. Please contact Fortinet for assistance.

If you host your own Authoritative DNS server(s), you must allocate a Service Protection Policy exclusively for that DNS traffic.

Overview

DNS protection follows the same procedures as other service protection, the following lists the basic steps:

1. Define and Service Protection Policy (SPP) for the DNS server(s). Ensure the SPP is in Detection (monitor) Mode (default).
2. Add the Protected Subnets (IP addresses) to the SPP.
3. Create SPP Profiles for IP, ICMP, TCP, HTTP, SSL/TLS, NTP, DNS and DTLS for the DNS SPP.
   Note: DNS servers can be attacked by all DDoS attacks so these are mandatory.
4. Assign the Profiles from step 3 to the DNS SPP.
5. Add DNS Allowlist/Blocklist/Regex and Resource Record ACLs. (Expert use only and entirely optional).
6. Leave the DNS SPP in Detection Mode for one-week of traffic learning. Shorter periods will result in more manual tuning. Contact Fortinet if one week is not feasible.
7. Generate Traffic Statistics for one week for the DNS SPP.
8. Create System Recommended Thresholds for the DNS SPP.
9. Leave the SPP in Detection Mode for 1-2 days. “Drops” caused by Anomalies and Thresholds will be shown but not dropped. Some parameters may require tuning.
10. Observer the Top Attacks GUI page for the DNS SPP for false-positive events. Tune as required.
11. Change SPP Profiles for IP and DNS to prepare for Prevention Mode.
    Note: You can clone the existing Profiles and rename them DNS-Prevention for example to remind yourself that the Profiles are different in Detection and Prevention.
12. Monitor the DNS SPP attack logs or Top Attacks to ensure there are no further false positives.
13. Allow the system to protect the servers autonomously with regular reporting.

Detailed steps

1. Go to Service Protection > CONFIGURATION: Service Protection Policy and create an SPP rule exclusively for DNS traffic.
   Ensure the SPP is in Detection Mode in both directions as shown below.
   
2. Save and reopen the SPP and add Protection subnets. Save the configuration.
3. Go to Service Protection > CONFIGURATION: DNS Profile and create a DNS Profile specifically for the DNS SPP.
   1. Set DNS Anomaly Feature controls as shown below. Note the disabled anomalies.
      
   2. Set DNS Feature Controls as shown below. Note these will change for Prevention Mode.
      
   3. While DNS servers are more likely to be attacked with Query floods, they can be attacked by any DDoS attack. Please follow the SPP Profiles Overview to create IP, ICMP, TCP, HTTP, SSL/TLS, NTP and DTLS Profiles before proceeding. Due to the complexity of DNS mitigation, it is best to create specific Profiles for the DNS SPP.
4. Go to Service Protection > CONFIGURATION: Service Protection Policy, select the SPP Rule, and click the Service Protection Policy tab.
5. Assign the various IP through DTLS Profiles to the SPP as shown below.
   
   Remaining options in the SPP must remain default.
6. Add FQDN Allowlist, Blocklist, Regex (optional and expert use only).
7. Add DNS Resource Record Type ACL to same DNS Profile (optional and expert use only).
8. Allow the system to learn traffic for this SPP for one week. Then perform the following steps after this one-week period:
   1. Go to Service Protection > CONFIGURATION: Service Protection Policy, select the DNS SPP, and click the Threshold Settings tab. Click Generate Statistics.
      
   2. On the Generate Statistics page, from the drop-down menu, select 1 Week.
      
   3. Once the report is generated, the Last Updated field will be updated with the time and date, and the Return button will change color to become selectable. Click Return to display the Service Protection Policy page.
   4. On the Service Protection Policy page, from the drop-down menu, select 1 Week. Note the Last Updated date and time stamp should match the one from the previous page. De-select the Do not show values below the low threshold to see more values displayed if available.
      
   5. View the right side of the same page and ensure that “Outbound Thresholds to MAX” is enabled as below (default). Leave all other settings at default.
      
   6. Click Create Thresholds. Wait for the “Your changes have been saved” message (a few seconds at most).
   7. Go to the Thresholds tab. You will see a large number of Threshold parameters similar to below.
      
      Cycle through all categories of Thresholds as shown below. Each category will have at least a one line entry. Many will have multiple lines and “ranges” of Ports, for example. If any category has no entries, contact Fortinet. The system creates more then 200,000 thresholds for each SPP and they are critical for protection.
      
      The system is now monitoring all thresholds but since it is in Detection Mode, it will report any “drops” but it will allow all traffic to pass. This allows you to tune Thresholds as required. Tuning takes experience and is not needed often, so contact Fortinet if you don’t understand what you are seeing in the next instructions.
9. Allow the system to monitor traffic for two to three days.
10. Go to Dashboard > TOP ATTACKS: SPP. Set the variables as shown below.
    
11. You may see entries in the Top Attacks and Top ACL Attacks tables.
    
    FortiDDoS recognizes more than 140 different attack events for more than 200,000 parameters. If you need help with Attack information, open a FortiCare ticket and go to System > Debug. Save a Debug File. Download it from the system and attach it to the ticket. The Debug file provides the last 20,000 attacks logs, which are summarized in the Top Attacks tables above. Fortinet will analyze the logs to assist you.
    Please be reminded that in Detection mode nothing is dropped, only reported.
    In general:
    
    • Layer 3 or Layer 4 anomalies are scans. These are unlikely to be false-positives.
    • TCP drops such as SYN Floods are scans or attacks on DNS servers. These are unlikely to be false-positives.
    • Small numbers of DNS anomalies (less than 100,000 per week) are scan traffic.
    • If you see DNS anomalies inbound, change the direction of the Top Attacks reporting to Outbound. If you see more than five or six different TYPES of DNS Anomalies, you may have encrypted DNS over UDP 53 in the same SPP. Contact Fortinet.
12. If you are seeing only small numbers of "drops" in the Top Attacks tables, go to Service Protection > CONFIGURATION: DNS Profile and change the settings as shown below and Save.
    
13. Go to Service Protection > CONFIGURATION: Service Protection Profiles > DNS SPP. Change the Inbound Operation Mode to Prevention as shown below. No other changes are needed.
    
    The SPP is now dropping any anomalies and floods in real time.
    Note: Fortinet recommends that this be done during a low traffic period but while traffic is rising, early in the business day, for example. If settings are incorrect, attack logs will alert you and you can return the SPP to Detection Mode to prevent further disruptions. If this happens, contact Fortinet for further support.
14. Go to Log & Report > LOG ACCESS: Logs. Set the Filter to the DNS SPP as shown below.
    
    Monitor the logs for 30 minutes to one hour. If you see large floods or your users or other monitoring equipment suggest there is a problem, return the DNS SPP to Detection Mode and contact Fortinet. All logs and graphs are preserved which will help to troubleshoot the problem.
    Attack Logs are generated every 5 minutes for anomalies and small floods but may report every minute for large floods. Normally drops are polled from the DDoS processors at the 5-minute interval but the system takes 2 minutes to aggregate the information and prepare the log; for example, logs for 1:05 appear on the GUI at 1:07. Logs are not automatically refreshed.
15. If Attack Logs are nominal and there are no other issues, leave the DNS SPP in Prevention Mode for several days, especially through heavier use times.
    Then, Check Dashboard > Top Attacks > SPP. Select Inbound, 1 Day or 1 Week and DNS SPP and observe the Top Attacks table.
    Review the Attacks. The Online Help or Handbook Appendix > Appendix A: DDoS Attack Log Reference contains information on every Attack Log event type including where the feature of threshold is set for that log and where the information is graphed. If in doubt, open a FortiCare Ticket and attach a Debug file for Fortinet’s review of the Attack Logs.