10 Simple Ways to Mitigate DNS Based DDoS Attacks

UDP floods are used frequently for larger bandwidth DDoS attacks because they are connectionless and it is easy to generate UDP packets using scripts. 

DNS uses UDP primarily and under some circumstances uses TCP. Because of the usage of UDP protocol, which is connection-less and can be spoofed easily, DNS protocol is extremely popular as a DDoS tool. 

Since DNS is a critically important protocol upon which the Internet is based, its availability is of utmost importance. To deny the availability, a malicious attacker sends spoofed requests to open DNS resolvers that allow recursion. There are millions of open DNS resolvers on the Internet including many home gateways. The open DNS resolver processes these requests as valid and then returns the DNS replies to the spoofed recipient (i.e., the victim). When the number of requests is large, the resolvers could potentially generate a large flood of DNS replies. This is known as an amplification attack because this method takes advantage of misconfigured DNS resolvers to turn a small DNS query into a much larger payload directed at the target. In yet another type of attacks, unsolicited or anomalous queries may be sent to the DNS servers.

Here are 10 simple ways through which FortiDDoS mitigates DNS floods to protect your DNS Infrastructure:

Do not allow unsolicited DNS responses

• A typical DNS message exchange consists of a request message from a resolver to a server, followed by a response message from your server to the resolver.  A response message is never sent unsolicited.  A response message is never answered with a response message.
• FortiDDoS is deployed before a DNS resolver, which could be an open resolver or an authoritative server.
• It is an inline device that can process millions of queries per second and maintains a memory table of queries and corresponding responses.
• When a response comes inbound, if the corresponding query has not passed yet, the response can be simply dropped. This scheme is a great remedy for reflection attacks.

Drop quick retransmissions

• Any legitimate DNS client does not send the same queries too soon, even when there is packet loss. There is a discipline in query retransmission that has to be followed per RFCs.
• Thus if the same queries come too soon from the same IP to the same destination, they can be dropped.

Do not allow same queries too soon if you have already sent the response – Enforce TTL

• A legitimate client does not send the same query again if it has already received the response.
• Every response is supposed to be cached until the TTL expires
• Under a query flood, such a scheme can be enforced to block unnecessary floods

Drop DNS queries and responses that are anomalous

• DDoS attacks are mostly written using scripts. These scripts prone to bugs like any other software. They do not necessarily comply with the RFCs related to DNS headers. Thus a simple anomaly detection mechanism can limit the number of packets under floods to a respectable level sometimes.

Drop unexpected or unsolicited DNS queries that you have not seen earlier.

• These queries may be due to lame delegations, taking a server for resolver, for probing, due to wrong configurations, for debugging purpose, or simply attack traffic. In any case, it makes sense to drop them.         
• During non-flood times, you can build a table of legitimate queries that have been responded with a positive response.
• Such a table can be used to block queries under flood that have not been seen earlier.
• This can ensure that you don’t get flooded with drip, phantom-domain and phantom-subdomain DNS DDoS attacks.
• This can also ensure that authoritative name servers will see queries only for domain names within or below zones they are authoritative for – thus blocking the so-called unsolicited DNS queries.

Force the DNS client to prove that it is not spoofed

• Spoofing is a common technique in DNS attack.
• If the appliance can force the client to prove its non-spoofed credentials, it can be used to sift the non-flood packets from spoofed flood packets.
• FortiDDoS does this by anti-spoofing techniques such forcing TCP transmission or forcing a retransmission.

Cache responses and save the DNS server from getting overloaded

• FortiDDoS has a built-in high performance DNS cache implemented using hardware logic that can handle millions of DNS queries per second.
• Under flood, if a DNS query passes all the above tests, the cache can respond if the response is already in the cache, thus saving the server from getting overloaded.

Use the power of ACLs

• Many queries contain information that you may not have or may not want to support. They can be simply blocked. E.g. if you don’t want external IP addresses to query Zone Transfer or fragmented packets, you should be simply able to drop them.

Use the power of Geo-location ACLs, BCP38 and IP Reputation

• Every enterprise that hosts DNS servers has limited footprint of customers.
• When attack packets are spoofed, these come from all over the world in terms of their source addresses. A simple filter that blocks unwanted geo-locations or allows only traffic from desired geo-locations goes a long way.
• In a similar way, spoofing is random. Sometimes spoofed packets may come from your inside addresses. Enforcing BCP38 using a hardware filter can also clean the traffic from anomalous sources addresses.
• Implementing BCP38 for service providers who provide DNS resolution for their customers is extremely powerful as it avoids their customers sending outbound attacks as well as receiving inbound packets with inside addresses. Thus they can filter their customer and their transit.

Over-provision bandwidth

• If your normal DNS traffic is X Gbps, ensure that you don’t simply have a pipe that’s just about right. Have some overprovisioning so that you can handle large attacks.

With the above 10 simple techniques available to you via FortiDDoS you can mitigate a bulk of DNS related DDoS attacks and ensure that your services remain available to your customers.