我运行了一个查询查询，可以对此进行确认。 -serverfault.com dns在少数国家/地区似乎无法解决，没有我可以识别的特殊原因。 （也通过What's My DNS进行了确认，该DNS以类似的方式在全球范围内执行了ping操作，因此被两个不同的来源确认为问题。）
如果我没有触摸serverfault.com的DNS，为什么会发生这种情况？
我们的注册商是（gag）GoDaddy，而我在大多数情况下都使用默认DNS设置事件。难道我做错了什么？ DNS的众神已经抛弃了我吗？
我可以做些什么来解决此问题？有什么方法可以使DNS正常运行，或强制DNS在世界范围内正确传播？
更新：截至太平洋标准时间星期一凌晨3:30，一切看起来都是正确的。JustPing报告站点是从所有位置均可到达。谢谢您提供了许多非常有帮助的答复，我学到了很多东西，下次发生这种情况时将参考此问题。.
#1 楼
这不是直接的DNS问题，而是Internet的某些部分与serverfault.com的DNS服务器之间的网络路由问题。由于无法访问名称服务器，因此域将停止解析。据我所知，路由问题是在IP地址为
204.245.39.50的（Global Crossing？）路由器上。如@radius所示，发送到ns52的数据包（由stackoverflow.com使用）从此处传递到
208.109.115.121，并从那里正常工作。但是发送到ns22的数据包将发送到208.109.115.201。由于这两个地址都在同一个/24中，并且对应的BGP公告也针对/24，所以这不应该发生。我已经通过我的网络完成了路由跟踪，该网络最终使用MFN Above.net而不是Global Crossing到达GoDaddy，并且没有迹象表明
/24级别以下的路由有任何欺骗性-这两个名称服务器都具有从此处相同的路由跟踪。我唯一一次见过这样的东西的时候，它就是Cisco Express Forwarding（CEF）。这是用于加速数据包路由的硬件级缓存。不幸的是，偶尔它与实际的路由表不同步，并试图通过错误的接口转发数据包。即使基础路由表条目用于
/32，CEF条目也可以降至/24级别。找到这类问题很棘手，但是一旦发现它们通常就很容易解决。我已经通过电子邮件发送了GC并尝试与他们交谈，但是它们不会创建一个非客户票。如果您是GC的客户，请尝试报告此问题。
在世界标准时间10:38更新。正如Jeff所指出的那样，问题现已解决。现在，到上述两台服务器的路由都通过下一跳
208.109.115.121。评论
我希望我能更多地支持你。我在外包世界中很着迷，可以联系Godaddy的1级地狱办公室，因为他们对问题描述的了解甚少，甚至对问题的解释也更少。
– pQd
09年7月20日在6:55
#2 楼
您的用于serverfault.com的dns服务器[ns21.domaincontrol.com，ns22.domaincontrol.com。 ]不可访问。持续约20小时，至少来自瑞典的几个主要isps [telia，tele2，bredband2]。同时可以访问stackoverflow.com和superuser.com [ns51.domaincontrol.com，ns52.domaincontrol.com]的“邻居” dns服务器。
示例跟踪到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服务提供商-爸爸。
您可以验证问题是否通过以下方式[部分地]得以解决：
检查Godaddy是否已做出反应并更改名称服务器-例如，使用recort类型在http://www.squish.net/dnscheck/上查找lookup serverfault.com：ANY
检查提供的名称服务器是否响应ping [不是很科学，因为名称服务器可以正常工作，并且仍然会阻止icmp，但是在这种情况下，似乎可以通过窥镜从telia允许icmp到其他服务器。
编辑：来自工作场所的跟踪路由
波兰
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
编辑：现在一切正常。
评论
是的，这绝对是一个外部问题，显然只限于欧洲。
– Alnitak
09年7月19日在11:39
似乎不是整个欧洲。 Eircom宽带线路（例如）可以很好地解决serverfault.com。
–钱
09年7月19日在11:42
@Alnitak：这不会影响整个欧洲-可以肯定。我可以从瑞典的bredbandsbolaget，波兰和德国的多个isps到达那些naem服务器。
– pQd
09年7月19日在11:55
尽管Eircom在过去的两周里给客户带来了一些严重的麻烦，但DNS中毒了：siliconrepublic.com/news/article/13448/cio/…
– Arjan
09年7月19日在11:59
上次我看到这样的问题是Cisco路由器上的CEF表损坏。即使某些主机位于同一/ 24子网中，也可以访问某些主机，而其他主机则无法访问。仅某些ISP受影响表明这些ISP有一些共同的供应商。从有效的连接中很难找出原因。
– Alnitak
09年7月19日在19:01
#3 楼
我的建议：正如Alnitak解释的那样，问题不在于DNS，而在于路由（可能是BGP）。 DNS问题没有发生，DNS设置没有任何变化是正常的事实。serverfault.com今天的DNS设置非常差，对于这样的重要站点肯定是不够的：
只有两个名称服务器
所有鸡蛋都在同一个篮子中（都在同一个AS中）
我们刚刚看到了结果：路由故障（在Internet上很常见）足以使serverfault.com对于某些用户消失（取决于他们的运营商，而不是他们所在的国家/地区）。
我建议添加更多内容名称服务器，位于其他AS中。这将允许故障恢复。您可以将它们租给私人公司，也可以要求serverfault用户提供辅助DNS托管（可能仅在用户具有> 1000 rep的情况下：-）
评论
zoneedit.com提供免费的DNS托管，我使用了多年，从未遇到任何问题。
–半径
09年7月24日在5:13
#4 楼
我确实确认从法国ISP Free.fr也无法到达NS21.DOMAINCONTROL.COM和NS22.DOMAINCONTROL.COM。与pQd traceroute一样，对于ns21和ns22，我的操作也将在208.109.115.201之后结束。 >
traceroute to NS22.DOMAINCONTROL.COM (208.109.255.11), 64 hops max, 40 byte packets
1 x.x.x.x (x.x.x.x) 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 x.x.x.x (x.x.x.x) 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具有相同的跟踪路由。从工作地点来看，我没有越过此204.245.39.50路由器（全局交叉）。
从工作地点和非工作地点获得更多的traceroute都会有所帮助，但是Global Crossing很有可能会为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到连接到Global Crossing路由服务器，并从Global Crossing网络内进行traceroute。
编辑：几天前，其他NS似乎已经出现了相同的问题，请参见：http：//www.newtondynamics。 com / forum / viewtopic.php？f = 9＆t = 5277＆start = 0
评论
我怀疑您可以通过[bgp]投放小于/ 24甚至/ 23的广告。我宁愿押注过滤然后路由故障。
– pQd
09年7月19日在12:08
是的，但是204.245.39.50可能是Go Daddy和Global Crossing之间的专用路由器。它可以接受来自父亲的任何路由，但是Global Crossing内部的上游路由器将仅路由/ 24（在BGP表208.109.255.0上被广告为/ 24）。 Go Daddy还可以将所有主机广告为/ 32，并且Global Crossing路由器将其聚合为/ 24，以进行BGP重新分发
–半径
09年7月19日在12:10
（但我同意那会有点丑）
–半径
09年7月19日在12:19
我敢打赌CEF表损坏...
– Alnitak
09年7月19日在19:22
#5 楼
方便的是从发生故障的位置查看详细的分辨率跟踪...查看发生故障的分辨率路径的哪一层。我不熟悉您所使用的服务，但是也许可以在某个地方选择它。如果失败，很可能问题在树中“降低”了，因为根或TLD将影响更多域（您希望如此）。为了提高弹性，如果domaincontrol的网络存在问题，可以委托第二个DNS服务以确保更好的解析冗余。
#6 楼
我很惊讶您没有托管自己的DNS。这样做的好处是如果DNS可以访问，那么（希望）您的站点也可以访问。评论
好吧..最好不要把所有的鸡蛋都放在一个篮子里。可能还有更多功能，而不仅仅是虚拟主机-也许是邮件服务？从弹性角度来看，dns非常不错。最好的做法是将主要dns放在提供程序＃1上，将第二个dns服务器放在其他提供程序上。只要其中任何一个都可以访问-最终用户就可以解决。
– pQd
09年7月19日在14:22
我自托管，但将ISP的DNS服务器列为主要服务器，即使它们确实是次要服务器也是如此。是的，这很顽皮，我完全希望听到抱怨的声音……但结果是，我们可以通过Qwest DNS服务器的冗余来完全控制自托管DNS。记录的TTL足够高，如果我们无法在3天之内解决问题，那么问题就不仅仅是DNS设置中断了。哦，@ Paul，+ 1表示在“将所有事情都外包出去，因为我们可以的时候”将自我托管作为原始选项。
–艾琳·佩恩（Avery Payne）
09年7月20日在3:03
#7 楼
至少从UPC，当尝试从您的权威服务器（ns21.domaincontrol.com）获取您的A记录时，我会收到此响应。; <<>> 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
当我尝试相同的从不同网络（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（至少）正在将DNS查询静默重定向到其自己的缓存名称服务器，并欺骗答复。如果您的DNS行为异常，这可以解释为UPC的名称服务器可能正在缓存NXDOMAIN响应。
评论
杰夫，请放心-绝对不是您。它可能是GoDaddy，但更可能是Global Crossing，特别是204.245.39.50上的路由器