Use multiple DNS providers to mitigate DDoS attacks

With the proliferation of insecure Internet of Things (IoT) devices, distributed denial of service (DDoS) attacks against domain name system (DNS) providers are increasing in number and scale. These attacks then affect websites that rely on these vendors for domain name resolution. Although DNS providers have taken various measures to protect themselves from such attacks, one way for websites to protect themselves is to use multiple DNS providers.

In 2016, one of the largest DDoS attacks in history occurred. This attack was targeted at the DNS provider Dyn. There are three waves before and after this attack. It attacks through a botnet composed of Internet of Things devices infected with Mirai malware. Many companies have been affected by this attack, such as Amazon, Paypal, Reddit and Github. This attack caused Dyn to be unable to respond to the valid DNS query of the domain name resolved by its domain name server, so that the end user could not access the relevant domain name.

According to Phil Stanhope, Vice President of Dyn Technology, this Dyn attack also includes an attack based on TCP SYN cookies, which exploits an error in the Linux kernel. SYN cookie is a method to mitigate SYN flood attacks. SYN flood attacks use up the resources of the target system by continuously sending TCP SYN requests. However, SYN cookies have their own problems. In Linux 3. x, a system level lock is used to generate SYN cookies. Because of this level of locking, the system runs like a single core system regardless of the actual number of cores, reducing its actual processing capacity. Linux version 4. x solves this problem by using local locks for each CPU kernel.

DNS providers use various methods to prevent attacks, such as scrubbing. Cleaning is to filter all traffic through a third party. The third party provides protection as a service to remove malicious traffic and enable legal traffic to pass through and reach the final destination. Many vendors provide such services, such as Akamai, AT&T, Verizon, and Arbor Networks.

Any HTTP (or other protocol) request for a website or domain name requires DNS queries to resolve the domain name to one or more IP addresses. The request traverses multiple parsers of authorization servers at all levels in the domain name. For example, for a request for www.infoq.com, first the root server, then the top-level domain name (TLD) server of. com, and finally the authorization server of infoq.com. The parser in the whole process may cache the results for faster follow-up response. The cache can be controlled by the Time To Live (TTL) value in the DNS response. The DDoS attack against the infoq.com authorization server may make these authorization servers unable to respond to valid queries, and ultimately make the entire website inaccessible.

In general, DNS server redundancy can prevent such interruption. In other words, any commercial DNS provider will provide multiple DNS servers for a given domain name. The dig or drill command can be used to view the DNS records (take infoq.com as an example below).

However, if a vendor is attacked by DDoS, all its DNS servers may be affected. Therefore, using multiple DNS providers can help solve this problem.

To use multiple DNS providers, you must allow editing the DNS server records of each DNS provider so that all records can be sent as part of the response. In addition, each supplier will have multiple domain name servers, and the order of all domain name servers of each supplier is disordered. In this way, a failed request to one vendor will result in a request to another vendor, rather than trying all the other DNS servers of the first vendor all the time, because these servers may also fail.

Another way to ensure DNS reliability is Anycast. In this method, multiple DNS servers have the same IP address. During DNS query, the data packet is sent to the nearest DNS server. In case of failure, the data packet is automatically transmitted to the nearest valid DNS server by the underlying routing protocol.

It is very important to set the correct TTL, so that even if the records are cached by the intermediate server serving the response, you can also switch to the secondary server in case of failure. As Stanhope said in his speech on Velocity, more collaboration is needed between NetOps, DevOps, SecOps and SRE teams to mitigate this attack in the future.