随着不安全物联网（IoT）设备的激增，针对域名系统（DNS）供应商的分布式拒绝服务（DDoS）攻击在数量和规模上正在不断增加。这些攻击随之影响依赖于这些供应商进行域名解析的网站。虽然DNS供应商采取了各种方法来保护自己免受此类攻击，但网站保护自身的方法之一是使用多个DNS供应商。
2016年发生了史上最大规模之一的DDoS攻击，这一攻击是针对DNS供应商Dyn的。此次攻击前后，它通过已感染Mirai恶意软件的物联网设备组成的僵尸网络进行攻击。许多公司都受到此次攻击的影响，比如Amazon、Paypal、Reddit和Github。该攻击导致Dyn无法响应由其域名服务器解析的域名的有效DNS查询，以至于终端用户无法访问相关域名。
据Dyn技术副总裁Phil Stanhope所说，此次Dyn攻击事件还包括一个基于TCP SYN cookie的攻击，该攻击利用了Linux内核的一个错误。SYN cookie是一种用于缓解SYN flood攻击的方法，SYN flood攻击通过连续发送TCP SYN请求来耗尽目标系统的资源。然而，SYN cookie也有自己的问题，在Linux 3.x版本中，一个系统级别的锁用于生成SYN cookie。由于这个级别的锁定，无论内核实际数量多少，系统均如单核系统一样运行，从而降低了其实际处理能力。Linux 4.x版本通过使用针对各个CPU内核的局部锁来解决这个问题。
DNS供应商采用了各种方法来防止攻击，比如清理（scrubbing）。清理是通过第三方来过滤所有流量。第三方以提供保护为服务，清除恶意流量，使合法流量通过并到达最终目的地。许多厂商，比如Akamai、AT＆T、Verizon和Arbor Networks。
对某个网站或域名的任何HTTP（或其他协议）请求，都需进行DNS查询，以将域名解析为一个或多个IP地址。该请求穿行于域名中各个级别的授权服务器的多个解析器。例如，对的请求，首先是根服务器，然后再查询.com的顶级域名（TLD）服务器，最后查询infoq.com的授权服务器。整个过程中的解析器可能会缓存结果，以便更快地进行后续响应。缓存可以由DNS响应中的生存时间（TTL）值控制。针对infoq.com授权服务器的DDoS攻击可能使得这些授权服务器无法响应有效查询，并且最终导致整个网站无法访问。
一般来说，DNS服务器冗余可以防止此类中断。也就是说任何商业DNS供应商都将为一个既定域名提供多个DNS服务器。dig或drill命令可用于查看域名服务器记录（下面以infoq.com为例）。
# 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但是，如果某个供应商遭到DDoS攻击，那么可能其所有的域名服务器都会受到影响。因此使用多个DNS供应商有助于解决这一问题。
要使用多个DNS供应商，必须允许编辑各个DNS供应商的域名服务器记录，以便所有记录都可以作为响应的一部分进行发送。另外，每个供应商都将拥有多个域名服务器，并且各供应商的所有域名服务器的顺序是打乱的。这样对一个供应商的失败请求会引起对另一个供应商的请求，而不是一直在尝试第一个供应商的所有其他域名服务器，因为这些服务器可能也是失效的。
确保DNS可靠性的其他方法还有Anycast，在这个方法中，多个域名服务器具有相同IP地址。进行DNS查询时，数据包被传送到最近的域名服务器。在失效的情况下，数据包由底层路由协议自动传送到最近的有效域名服务器。
设置正确的TTL非常重要，这样即使记录由服务于响应的中间服务器进行缓存，也可以实现发生故障时切换到辅助服务器。正如Stanhope在Velocity的演讲中所说，未来NetOps、DevOps、SecOps和SRE团队之间需要更多的协作来缓解这种攻击。