研究互联网域名系统内部运作的专家们说，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的战略关系和技术标准主管Jim Galvin说：“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月,德国停电它的.de顶级域区域服务器由于区域文件被截断而使数百万网站（如www.ford.de）离线数小时。
一年前，所有带有瑞典.se扩展名的网站是不可用的由于用于更新.se域的不正确脚本丢失了一个点，已持续一小时或更长时间。
凯悦说：“这些类型的停机经常发生。”。“它们发生在管理不善的系统中。发生在德国和瑞典的一次——这些都是自动化脚本中永远不会发生的错误或错误……它们本可以避免。”
凯悦表示，包括BlueCat功能配置检查软件在内的DNS设备可以提醒管理员他们正在进行的DNS数据更改无效。
Hyatt表示:“如果系统不存在或配置不正确，我们有数据检查规则，检查你试图部署的配置，不会将其推出。”“我们的系统有很多智能。它会给你一个警报，告诉你哪里出了问题。”
BlueCat的设备自2001年引入以来就以DNS配置检查为特色。
凯悦说：“我们正在寻找不合情理的异常现象和逻辑错误。”。“我们肯定会抓住德国和瑞典的错误，因为这些都是逻辑错误。”
类似地，Afilias会在发布更改之前检查其操作的顶级域的区域文件更改，以防止出现类似.de和.se运算符所遇到的错误。
加尔文说：“我们注意到区域文件发生更改时，会弹出警报，以便进行调查。”。“我们检查了更改的百分比……这将有助于防止德国和瑞典的问题，那里的分区文件更改非常剧烈。”
但Galvin补充说，如果客户的DNS数据库中存在不良数据，像Afilias这样的服务提供商就无能为力了，就像Facebook经历的情况一样。
“你对自己的数据完全负责；我们保证你的数据是可用的，”加尔文说。“您的恢复速度无法超过TTL允许的恢复速度。”
凯悦补充说，最好的错误检查系统无法防止系统管理员避免犯各种可能导致停机的错误。凯悦补充说:“如果他们在做一些有风险的事情，无视最佳做法，我们无法阻止他们。”