Distributed Denial of Service (DDoS) attacks against Domain Name System (DNS) providers are increasing in number and scale with the proliferation of insecure IoT devices. These attacks in turn affect websites dependent on such providers for name resolution. While DNS providers have various methods of protecting themselves against such attacks, one of the ways for a website to protect itself is to use multiple DNS providers.
2016 saw one of the largest DDoS attacks in history carried out against DNS provider Dyn. Spread out across three waves, it was orchestrated using a botnet of IoT devices that had been infected with the Mirai malware. Many services like Amazon, Paypal, Reddit and Github were affected. The attack led to Dyn not being able to respond to valid DNS queries for domains resolved by its nameservers, which led to the end users of such domains not being able to reach them.
The Dyn incident included a TCP SYN cookie based attack, according to Phil Stanhope, VP of Technology at Dyn, which exploits a fault in the Linux kernel. SYN cookies are a way to mitigate SYN flood attacks, which attempts to exhaust the target system’s resources by sending successive TCP SYN requests. However, SYN cookies have their own problems, since in Linux 3.x, a machine-wide lock is used to generate the SYN cookies. Because of the lock, the system behaves as a single-core system irrespective of the number of cores, thus reducing its actual processing power. Linux 4.x fixes this by introducing a lock that is local to each CPU core.
DNS providers utilize various methods against attacks like scrubbing. Scrubbing involves filtering all traffic through a third party, which provides protection as a service, removing malicious traffic and letting the legitimate traffic through to the final destination. Various vendors like Akamai, AT&T, Verizon and Arbor Networks provide such services.
Any HTTP (or other protocol) request for a website or domain results in a DNS query to resolve the name to an IP address (or addresses). The request goes through multiple resolvers to the authoritative servers for each level in the name. E.g. a request for www.infoq.com first hits the root servers, then the top-level domain (TLD) servers for .com, and then the authoritative servers for infoq.com. Resolvers along the way might cache the results for faster subsequent responses. The caching can be controlled by a time-to-live (TTL) value in the DNS response. A DDoS attack against the authoritative servers for infoq.com can result in them being unable to respond to valid queries, and the entire website being unavailable as a result.
In general, redundancy for DNS servers can prevent such outages. Any commercial DNS provider will have multiple DNS servers for a given domain. The dig or the drill command can be used to see the nameserver records (infoq.com in the example below)
# dig infoq.com ns
; <<>> DiG 9.10.3-P4-Ubuntu <<>> infoq.com ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47143
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;infoq.com. IN NS;; ANSWER SECTION:
infoq.com. 259200 IN NS ns1.contegix.com.
infoq.com. 259200 IN NS ns2.contegix.com.;; Query time: 367 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 03 23:47:46 IST 2017
;; MSG SIZE rcvd: 83
However, if the provider is hit by a DDoS attack, there is a possibility that all its nameservers might be affected. Having multiple DNS providers can help get around such cases.
To use multiple DNS providers, it has to be possible to edit the nameserver records in each DNS provider so that all records can be sent as part of a response. Also, each provider will have multiple nameservers, and they should be in mixed order so that a failed request made to one provider leads to the request being made to the other provider instead of first trying out all the other nameservers of the first one, which might have failed as well.
Other methods for DNS robustness include Anycast, which involves multiple nameservers having the same IP address. When a DNS query is made, the packet is routed to the closest nameserver. In case of failure, the packets are automatically routed to the nearest alive nameserver by the underlying routing protocol.
Setting the correct TTL is important so that failover to secondary servers can happen even if the records are cached by intermediate servers serving the response. As Stanhope says in his Velocity talk, more collaboration between NetOps, DevOps, SecOps and SRE teams is required to meet and mitigate such attacks in the future.
