DNS无法在全球传播

这不是直接的DNS问题，而是因特网的某些部分和serverfault.com的DNS服务器之间的networking路由问题。 由于无法到达域名服务器，因此域名停止parsing。

据我可以告诉路由问题是在IP地址为204.245.39.50的（Global Crossing？）路由器上。

如@radius 所示 ，到ns52的数据包（由stackoverflow.com使用 ）从这里传递到208.109.115.121并从那里正常工作。 然而，到ns22的数据包转到208.109.115.201 。

由于这两个地址都在相同的/24和相应的BGP公告也是一个/24这不应该发生 。

我已经通过我的networking完成了跟踪路由，最终使用MFN Above.net而不是Global Crossing来到GoDaddy，并且在/24级别之下没有任何路由欺骗的迹象 – 两个名称服务器都具有相同的跟踪路由。

我唯一见过这样的东西就是思科快速转发 （CEF）。 这是用于加速数据包路由的硬件级高速caching。 不幸的是，偶尔它会与真正的路由表不同步，并尝试通过错误的接口转发数据包。 即使底层路由表条目为/24 CEF条目也可以降低到/32级别。 find这些问题很棘手，但是一旦发现这些问题通常很容易解决。

我已经通过电子邮件发送了GC，并试图与他们交谈，但是他们不会为非客户创build票据。 如果你们中的任何人是 GC的客户，请尝试报告这个…

更新在10:38 UTC正如杰夫已经注意到，问题已经清除。 上述两台服务器的路由跟踪现在都通过208.109.115.121下一跳进行。

您的DNS服务器为serverfault.com [ns21.domaincontrol.com，ns22.domaincontrol.com。 ]是无法访问的。 最后〜20小时，至less来自瑞典的几个主要的isps（ telia ， tele2 ， bredband2 ）。

同时“邻居”dns服务器为stackoverflow.com＆superuser.com [ns51.domaincontrol.com，ns52.domaincontrol.com]是可及的。

示例traceroute到ns52.domaincontrol.com：

  1. xxxxxxxxxxx 2. 83.233.28.193 3. 83.233.79.81 4. 213.200.72.5 5. 64.208.110.129 6. 204.245.39.50 7. 208.109.115.121 8. 208.109.115.162 9. 208.109.113.62 10. 208.109.255.26 

和ns21.domaincontrol.com

  1. xxxxxxxxxxxx 2. 83.233.28.193 3. 83.233.79.81 4. 213.200.72.5 5. 64.208.110.129 6. 204.245.39.50 7. 208.109.115.201 8. ??? 

也许搞砸了过滤/某人触发了一些不必要的ddos保护和黑名单的互联网的一些部分。 可能你应该联系你的DNS服务提供商 – 去爸爸。

您可以通过以下方式validation问题是否得到解决：

1. 检查godaddy是否已经反应并更改了名称服务器 – 例如，使用recorttypes查找http://www.squish.net/dnscheck/上的 serverfault.com：ANY
2. 检查提供的名称服务器是否响应ping [由于名称服务器可以正常工作，并仍然阻止icmp，但在这种情况下似乎icmp被允许到其他服务器]从telia通过镜子反应非常科学。

编辑 ：从工作地点traceroutes

波兰

  1. xxxxxxxxxxxxxxx 2. 153.19.40.254 3. ??? 4. 153.19.254.236 5. 212.191.224.205 6. 213.248.83.129 7. 80.91.254.171 8. 80.91.249.105 80.91.251.230 80.91.254.93 80.91.251.52 9. 213.248.89.182 10. 204.245.39.50 11. 208.109.115.121 12. 208.109.115.162 13. 208.109.113.62 14. 208.109.255.26 

德国

  1. xxxxxxxxxxxx 2. 89.149.218.181 3. 89.149.218.2 4. 134.222.105.249 5. 134.222.231.205 6. 134.222.227.146 7. 80.81.194.26 8. 64.125.24.6 9. 64.125.31.249 10. 64.125.27.165 11. 64.125.26.178 12. 64.125.26.242 13. 209.249.175.170 14. 208.109.113.58 15. 208.109.255.26 

编辑 ：现在确实工作正常。

我的build议：正如Alnitak解释，问题不是DNS，而是路由（可能是BGP）。 在DNS设置中没有任何变化的事实是正常的，因为问题不在于DNS。

serverfault.com今天有一个非常糟糕的DNS设置，对于像这样一个重要的网站当然不够：

• 只有两个名字服务器
• 同一篮子里的所有鸡蛋（都在同一个AS中）

我们刚刚看到了这样的结果：路由故障（在Internet上相当普遍）足以使serverfault.com消失（取决于他们的运营商，而不是他们的国家）。

我build议添加更多的名称服务器，位于其他AS。 这将允许失败弹性。 你可以把它们租给私人公司，或者要求serverfault用户提供二级DNS托pipe（只有当用户拥有> 1000的代表:-)

我确认NS21.DOMAINCONTROL.COM和NS22.DOMAINCONTROL.COM也从法国的ISP Free.fr不可用。
像pQd traceroute一样，我的也在208.109.115.201之后结束了ns21和ns22。

 traceroute to NS22.DOMAINCONTROL.COM (208.109.255.11), 64 hops max, 40 byte packets 1 xxxx (xxxx) 2.526 ms 0.799 ms 0.798 ms 2 78.224.126.254 (78.224.126.254) 6.313 ms 6.063 ms 6.589 ms 3 213.228.5.254 (213.228.5.254) 6.099 ms 6.776 ms * 4 212.27.50.170 (212.27.50.170) 6.943 ms 6.866 ms 6.842 ms 5 212.27.50.190 (212.27.50.190) 8.308 ms 6.641 ms 6.866 ms 6 212.27.38.226 (212.27.38.226) 68.660 ms 185.527 ms 14.123 ms 7 204.245.39.50 (204.245.39.50) 48.544 ms 19.391 ms 19.753 ms 8 208.109.115.201 (208.109.115.201) 19.315 ms 19.668 ms 34.110 ms 9 * * * 10 * * * 11 * * * 12 * * * 

但ns52.domaincontrol.com（208.109.255.26）可以正常工作，与ns22.domaincontrol.com（208.109.255.11）位于同一个子网中，

 traceroute to ns52.domaincontrol.com (208.109.255.26), 64 hops max, 40 byte packets 1 xxxx (xxxx) 1.229 ms 0.816 ms 0.808 ms 2 78.224.126.254 (78.224.126.254) 12.127 ms 5.623 ms 6.068 ms 3 * * * 4 212.27.50.170 (212.27.50.170) 13.824 ms 6.683 ms 6.828 ms 5 212.27.50.190 (212.27.50.190) 6.962 ms * 7.085 ms 6 212.27.38.226 (212.27.38.226) 35.379 ms 7.105 ms 7.830 ms 7 204.245.39.50 (204.245.39.50) 19.896 ms 19.426 ms 19.355 ms 8 208.109.115.121 (208.109.115.121) 37.931 ms 19.665 ms 19.814 ms 9 208.109.115.162 (208.109.115.162) 19.663 ms 19.395 ms 29.670 ms 10 208.109.113.62 (208.109.113.62) 19.398 ms 19.220 ms 19.158 ms 11 * * * 12 * * * 13 * * * 

正如你所看到的，这一次在204.245.39.50之后，我们会去208.109.115.121而不是208.109.115.201。 而pQd具有相同的traceroute。 从工作地点我没有通过这个204.245.39.50路由器（环球电讯）。

环球电讯很有可能会在208.109.255.11/32和216.69.185.11/32中为208.109.255.10,208.109.255.12,216.69.185.10,216.69虚假路由条目。 185.12运作良好。

为什么它有一个路由条目是很难知道的。 可能208.109.115.201（Go Daddy）正在为208.109.255.11/32和216.69.185.11/32广告非工作路线。

编辑：您可以telnet route-server.eu.gblx.net连接到全球通道路由服务器，并从全球通道networking

编辑：看来，同样的问题已经发生与他人NS几天前，请参阅： http : //www.newtondynamics.com/forum/viewtopic.php? f=9&t=5277&start =0

我很惊讶，你不主机自己的DNS。 这样做的好处是，如果DNS是可及的，（希望）您的网站也是如此。

如果从失败的位置看到详细的解决scheme追踪，看看哪个层面的解决schemepath失败，那将是非常方便的。 我不熟悉你使用的服务，但也许这是一个选项。

否则，树中的问题很可能会“降低”，因为根或TLD的失败会影响更多的域（您希望）。 为了提高弹性，您可以委托第二个DNS服务，以确保在域控制networking出现问题时能够更好地解决冗余问题。

至less从UPC，我得到这个反应时，试图从您的授权服务器（ns21.domaincontrol.com）获得您的Alogging。

 ; <<>> DiG 9.5.1-P2 <<>> @ns21.domaincontrol.com serverfault.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38663 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;serverfault.com. IN A ;; Query time: 23 msec ;; SERVER: 216.69.185.11#53(216.69.185.11) ;; WHEN: Sun Jul 19 12:09:40 2009 ;; MSG SIZE rcvd: 33 

当我从另一个networking（OVH）上的机器尝试同样的事情时，我得到一个答案

 ; <<>> DiG 9.4.2-P2 <<>> @216.69.185.11 serverfault.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33998 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;serverfault.com. IN A ;; ANSWER SECTION: serverfault.com. 3600 IN A 69.59.196.212 ;; AUTHORITY SECTION: serverfault.com. 3600 IN NS ns21.domaincontrol.com. serverfault.com. 3600 IN NS ns22.domaincontrol.com. ;; Query time: 83 msec ;; SERVER: 216.69.185.11#53(216.69.185.11) ;; WHEN: Sun Jul 19 12:11:05 2009 ;; MSG SIZE rcvd: 101 

我得到了一些其他域的类似行为，所以我认为UPC（至less）是静静地将DNS查询redirect到他们自己的caching域名服务器，并欺骗回复。 如果您的DNS短暂地被误解了，这可以解释它，因为UPC的名称服务器可能cachingNXDOMAIN响应。