Jef*_*ood 66 domain-name-system
我没有更改与 serverfault.com 的 DNS 条目相关的任何内容,但是今天一些用户报告说serverfault.com DNS 无法为他们解析。
我运行了一个简单的查询,我可以确认这一点 - serverfault.com dns 似乎无法在少数几个国家/地区解决,我没有任何特别的原因可以辨别。(也通过What's My DNS以类似的方式进行了一些全球 ping 的确认,因此它被两个不同的来源确认为一个问题。)
如果我没有接触 serverfault.com 的 DNS,为什么会发生这种情况?
我们的注册商是 (gag) GoDaddy,我在大多数情况下使用默认 DNS 设置,没有发生任何事故。难道我做错了什么?DNS的众神抛弃了我吗?
我能做些什么来解决这个问题吗?有什么方法可以提高 DNS 或强制 DNS 在全球范围内正确传播?
更新:截至周一太平洋标准时间凌晨 3:30,一切看起来都正确。 JustPing 报告站点可从所有位置访问。感谢您提供许多非常有用的回复,我学到了很多东西,下次发生这种情况时会参考这个 Q..
Aln*_*tak 91
这不是直接的 DNS 问题,而是 Internet 的某些部分与 serverfault.com 的 DNS 服务器之间的网络路由问题。由于无法访问域名服务器,域停止解析。
据我所知,路由问题出在具有 IP 地址的(Global Crossing?)路由器上204.245.39.50。
如@radius所示,发往 ns52(由stackoverflow.com 使用)的数据包从这里传递到那里208.109.115.121并从那里正常工作。但是,到 ns22 的数据包会转到208.109.115.201.
由于这两个地址都在同一个地址中,/24并且相应的 BGP 公告也是针对 a/24这不应该发生的。
我已经通过我的网络完成了跟踪路由,最终使用 MFN Above.net 而不是 Global Crossing 来到达 GoDaddy,并且在该/24级别以下没有任何路由欺骗的迹象- 两个名称服务器都有相同的跟踪路由。
我唯一见过这样的事情是思科快速转发(CEF)坏了。这是用于加速数据包路由的硬件级缓存。不幸的是,它偶尔会与真正的路由表不同步,并试图通过错误的接口转发数据包。CEF条目可以再往/32水平即使底层路由表条目是/24。找到这些类型的问题很棘手,但一旦发现它们通常很容易修复。
我给 GC 发了电子邮件,也尝试与他们交谈,但他们不会为非客户创建票证。如果你们中的任何一个是 GC 的客户,请尝试报告这个......
UTC 时间 10:38 更新 正如杰夫所指出的,问题现已解决。上面提到的两个服务器的跟踪路由现在通过208.109.115.121下一跳。
pQd*_*pQd 18
serverfault.com 的 dns 服务器 [ns21.domaincontrol.com, ns22.domaincontrol.com。] 无法访问。在过去的大约 20 小时内,至少来自瑞典的几家主要互联网服务提供商 [ 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
Run Code Online (Sandbox Code Playgroud)
和 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. ???
Run Code Online (Sandbox Code Playgroud)
可能会搞砸过滤/有人触发了一些不需要的 ddos 保护并将互联网的某些部分列入黑名单。也许你应该联系你的 dns 服务提供商 - 去爸爸。
您可以通过以下方式验证问题是否[部分]解决:
编辑:来自工作场所的跟踪路由
波兰
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
Run Code Online (Sandbox Code Playgroud)
德国
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
Run Code Online (Sandbox Code Playgroud)
编辑:现在确实一切正常。
bor*_*yer 16
我的建议:正如 Alnitak 所解释的,问题不是 DNS,而是路由(可能是 BGP)。DNS 设置中没有任何更改的事实是正常的,因为问题不在他的 DNS 中。
serverfault.com 今天的 DNS 设置非常糟糕,对于像这样的重要站点来说肯定不够:
我们刚刚看到了结果:路由故障(在 Internet 上很常见)足以使 serverfault.com 对某些用户(取决于他们的运营商,而不是他们的国家)消失。
我建议添加更多位于其他 AS 的名称服务器。这将允许故障恢复。您可以将它们租给私人公司或要求 serverfault 用户提供辅助 DNS 托管(可能仅当用户拥有 > 1000 代表 :-)