互联网域名系统的内部工作专家说，使用了27年的通讯协议似乎并不是Facebook上周高调宕机的原因。该系统将IP地址与相应的域名进行匹配。
互联网内部工作的专家域名系统该公司表示，使用了27年的通讯协议似乎并不是Facebook上周高调宕机的原因。
Facebook的服务无法使用这是该公司四年多来最严重的失败。最初的新闻报道将宕机归咎于DNS因为终端用户在无法到达网站时收到了一个“DNS错误”消息。
“这可能是一个教训，问题在不同时期看起来像DNS，但最终证明不是，”蟋蟀刘，架构副总裁Infoblox这家公司销售DNS设备。“根据我的经验，用户很快就会指责DNS(可能是因为浏览器在无法到达某个地方时喜欢暗示DNS)，但DNS通常并没有错。”
Facebook没有提供关于宕机原因的细节，只是说宕机是由于其一个数据库的错误配置造成的，这导致一个试图修复错误的自动化系统产生了大量流量。
“我们对一个被解释为无效的配置值的持久副本进行了更改，”Robert Johnson在Facebook的博客对这一事件做出回应。这意味着每个客户端都看到了无效值并试图修复它。因为修复方案涉及到对数据库集群进行查询，该集群很快就会被每秒数十万次查询淹没。”
这个反馈循环产生了如此多的流量，以至于Facebook被迫关闭了数据库集群，这意味着关闭了网站。
约翰逊说:“一旦数据库恢复并修复了根本原因，我们就会慢慢地让更多的人回到这个网站。”他补充说:“目前，我们已经关闭了试图纠正配置值的系统。”
专家表示，Facebook的宕机并不是DNS造成的，因为在事故发生期间，他们能够部分登录到网站，如果是DNS造成的，这是不可能的。
“这似乎是他们那端国家信息的配置问题——什么是缓存，什么是权威，”Richard Hyatt说，他是长鳍叉尾网络该公司销售DNS设备和基于云计算的托管DNS服务。“我认为，他们那边的配置可能与DNS有关……但他们对此非常含糊。”
Infoblox将Facebook的宕机归因于一个问题与变更管理在周五的一篇博文中。
“在处理网络变更和配置时，组织必须更加主动地测试、验证和监控关键网络基础设施(路由器、交换机、防火墙等)以及Web服务(应用程序、数据库和服务器)的持续状态。”Infoblox称，变更管理是“全球IT团队面临的最大问题”。
“目前还不清楚Facebook是否存在DNS问题。从他们发布的官方信息来看，没有任何迹象表明这一点。Afilias该公司经营着包括。info和。org在内的十多个顶级域名。“很明显，他们存在分布式数据库问题……从我们的角度来看，问题在于如何确保数据库中有良好的数据。”
加尔文说，Facebook经历的问题类似于分布式拒绝服务攻击在这种情况下，网站会被黑客的流量淹没。在Facebook的例子中，多余的流量是由它自己的自动验证配置值的系统产生的。
Galvin说:“对于Facebook，临时系统知道它有坏数据，想要得到正确的数据……所以它会一直询问，直到得到正确的答案。”这就好比是DDOS攻击。有越来越多的解析器突然发现缓存中有坏数据，他们不断地请求正确的数据。有坏数据的服务器会收到更多请求，一切都会变慢。”
Galvin说，围绕Facebook宕机的困惑源于DNS也有类似的属性。如果权威DNS数据库中有坏数据，DNS解析器将继续请求正确的数据，并使系统流量泛滥。此外，由于DNS的生存时间(TTL)特性，DNS数据库中的坏数据将在错误修复后继续驻留在缓存数据库中若干小时。许多网站的生存时间为一天，这意味着坏数据将在DNS缓存中保存24小时。
“这是DNS默认的做法，”Galvin说。“如果缓存中有坏数据，TTL就会开始发挥作用。你也许能做些什么，也许不能，这取决于你的TTL有多长。”
虽然Facebook的宕机似乎与DNS无关，但类似的DNS数据错误配置已经导致了大规模的宕机，最近发生在德国和瑞典。
今年5月,德国遭遇停机由于一个区域文件被截断，导致诸如www.ford.de这样的数百万网站脱机数小时。
一年前，所有瑞典的。se扩展名的网站是不可用的因为一个用于更新.se域的错误脚本缺少了一个点，导致一个小时或更长时间。
Hyatt说:“这种类型的中断经常发生。“它们是通过管理不善的系统发生的。在德国发生的和在瑞典发生的，这些都是自动化脚本中的错误或错误，本不应该发生的……它们本可以避免。”
凯悦表示，包括BlueCat功能配置检查软件在内的DNS设备可以提醒管理员他们正在进行的DNS数据更改是无效的。
Hyatt表示:“如果系统不存在或配置不正确，我们有数据检查规则，检查你试图部署的配置，不会将其推出。”“我们的系统有很多智能。它会给你一个警报，告诉你哪里出了问题。”
BlueCat的设备自2001年引入以来就以DNS配置检查为特色。
“我们正在寻找不合理的异常情况和逻辑错误，”Hyatt说。“我们肯定会发现德国和瑞典的错误，因为那是逻辑错误。”
类似地，Afilias在更改发布之前检查其操作的顶级域的区域文件更改，以防止类似.de和.se操作符所经历的错误。
我们会注意到区域文件的变化。它会弹出一个警报，以便进行调查。”“我们检查更改的百分比……这将有助于防止德国和瑞典的问题，那里的文件更改非常剧烈。”
但Galvin补充说，如果客户的DNS数据库中存在不良数据，像Afilias这样的服务提供商就无能为力了，就像Facebook经历的情况一样。
“你要对自己的数据完全负责;我们所能保证的就是你的数据是可用的。”“您不能比TTL允许的恢复速度更快(从坏数据中)恢复。”
凯悦补充说，最好的错误检查系统也无法预防系统管理员避免犯各种可能导致停机的错误。凯悦补充说:“如果他们在做一些有风险的事情，无视最佳做法，我们无法阻止他们。”