他们可能做到了。

检查实际受影响的一个，我们看到 basecamp 有 4 个 DNS 服务器，但都托管在 dynect.net 上。因此，如果 dynect 的基础设施受到攻击，很可能它们都没有很好地响应。

挖 -t NS basecamp.com

; <<>> DiG 9.8.1-P1 <<>> -t NS basecamp.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39198
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;basecamp.com.          IN  NS

;; ANSWER SECTION:
basecamp.com.       28725   IN  NS  ns3.p25.dynect.net.
basecamp.com.       28725   IN  NS  ns4.p25.dynect.net.
basecamp.com.       28725   IN  NS  ns1.p25.dynect.net.
basecamp.com.       28725   IN  NS  ns2.p25.dynect.net.

GitHub 也是一样

挖 -t NS github.com

; <<>> DiG 9.8.1-P1 <<>> -t NS github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22950
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;github.com.            IN  NS

;; ANSWER SECTION:
github.com.     24417   IN  NS  ns1.p16.dynect.net.
github.com.     24417   IN  NS  ns2.p16.dynect.net.
github.com.     24417   IN  NS  ns3.p16.dynect.net.
github.com.     24417   IN  NS  ns4.p16.dynect.net.

;; Query time: 1 msec
;; SERVER: 173.203.4.8#53(173.203.4.8)
;; WHEN: Sat Oct 22 06:09:42 2016
;; MSG SIZE  rcvd: 114

应该注意的是，这是将所有鸡蛋放在一个篮子中的示例。大多数托管服务提供商、ISP，甚至许多云服务提供商都在谈论他们的多个数据中心之间的冗余，但它们通常都在某种类型的单一基础架构中，例如全部路由或黑洞，因为所有这些 IP 共享一个 BGP从 Internet 主干的角度来看，ASN 旨在防止发生错误时出现循环，但它可能会使这些托管服务提供商、ISP 或云提供商网络中的所有一个暂时退出。

这就提出了一个问题，那么为什么 DNS 服务器不在完全不同的 ISP 网络上来防止这样的单点故障。对此，我想说这更多的是选择数据中心/云提供商的人的疏忽。有时这是由于易于计费或由于供应商关系或系统部署方法的其他动态，但发生这种情况的更正式术语是简单的路径依赖 （即他们这样做是因为这是以前的方式公司，它在那里工作得很好......）

值得称赞的是，Dyn DNS 确实提供了一些企业解决方案，这些解决方案具有许多附加功能，这些附加功能可能只有在 Dyn DNS 管理所有 DNS 服务器时才可用。有趣的风险权衡。我很想知道他们的营销文献和合同 SLA 对他们基础设施的冗余和可用性的说法。

在任何情况下，由多个提供商托管 DNS 服务器是明智的。