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.

Types of DNS Attack

1. DNS Tunneling

DNS tunneling exploits the fact that firewall administrators must open port 53 in order for DNS authoritative name servers to respond to queries from the Internet. The attacker compromises a host in the internal network and runs a DNS tunnel server on it. A DNS tunnel client outside the internal network can then gain access to the internal network by sending a DNS query to the compromised host that sets up a DNS tunnel.

2. DNS query attack

A DNS flood is an attempt to create a network outage by flooding critical DNS servers with excessive queries. Some DNS floods target the authoritative name server for a domain. In these types of attacks, malware bots send a continuous flood of queries for random, nonexistent subdomains of a legitimate domain. All of the DNS servers in the recursive chain consume resources processing and responding to the bogus queries.

There are 2 types of DNS query Attack

2.1 DNS slow-drip, random, non-existent subdomain attack

If clients in your internal network have been compromised by malware, your internal DNS resolvers could also be targets of query flood attacks. In non-existent NX domain (NXDOMAIN) attacks, the clients that have been compromised send queries for domains that do not exist. This uses resources and can fill up the cache. In phantom domain attacks, the clients that have been compromised send DNS queries for a phantom domain name—a domain server that exists, but it is controlled by an attacker. The attacker might have configured it to send no responses or slow responses. These illegitimate transactions waste resources, and a flood of them can take down the DNS resolver.

2.2 DNS NX domain and phantom domain attack

3. DNS Response Attack

With DNS Response attack, Zombie generated DNS query packet with source Address is victim IP Address and request to Authorized DNS server. In a short time, Victim server received milion of DNS response packet routed to it and maked overload CPU for processing unwanted packets.

Protection DNS DDOS Attack with FortiDDOS

For protecting again DNS DDOS attacks, FortiDDOS support some protection module with DNS Transport TCP/UDP as below:

1. ACL rules You can use the Do Not Track and Global ACL Allow policy to whitelist trusted IP addresses. For example, to permit DNS query type ALL or Zone Transfer from specified hosts, you can whitelist them and then create rules that deny those types of queries from all other sources.
2. 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.
3. 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
4. DNS Query Response Matching (DQRM) Blocks unsolicited responses and throttles duplicate queries (regardless of flood state)

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. Under normal conditions (no floods), FortiDDoS builds a baseline of DNS traffic statistics and stores DNS query and response data in tables. At all times, the tables are used to validate response traffic. During UDP floods, the tables are used to test queries and responses. The following table describes the system tables used for DNS attack 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. It can store up to 1.9 million records. When it receives a response, it searches this table for a matching query. If the response has no matching query, FortiDDoS drops the unmatched response. Drops are reported on the Monitor > Layer 7 > DNS > Unsolicited Response graph. The table entry is cleared after the matching response is received. The DQRM table response validation prevents attacks that attempt to exploit DNS responses, such as DNS cache poisoning and DNS amplification attacks (also called Distributed Reflective Denial of Service 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.
Legitimate Query (LQ) table	Used to mitigate UDP floods. When a valid response is received, the query details are stored in the table. It can store 128,000 records. Entries are cleared when the TTL expires. During a flood, the system drops queries that do not have entries in the table.
TTL table	Used to mitigate UDP floods. When a valid response is received, the query details are correlated with the client IP address and stored in the table. It can store 1.5 million records. Entries are cleared when the TTL expires. Responses with TTL=0 are not added to the table. During a flood, the system drops queries that have an entry in the table. It is not expected that a client would send the same query before the TTL expires.
Legitimate IP table	Used to mitigate UDP floods. During DNS query floods, you can leverage the legitimate IP (LIP) table to test whether the source IP address is spoofed. If the source IP address is found in the LIP table, processing continues; if there is no entry, the system can test source IP legitimacy by performing a UDP retransmission test or by sending a response with the TC flag set. The TC flag indicates to the client to retry the request over TCP. When the query is retried over TCP, other flood mitigation mechanisms may be available, such as SYN flood antispoofing features.
DNS cache	Used to mitigate UDP floods. When a valid response is received, the system caches the response packets. It can store 64,000 records. Entries are cleared when the TTL expires. During a flood, if the query passes the LQ and TTL checks, the response is 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 not an 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.
Source tracking table	Used for source flood tracking—UDP or TCP. Tracks DNS queries per source and suspicious actions per source. It drops packets that exceed the maximum thresholds and applies the blocking period for identified sources.