☰

DNS 无法在全球范围内传播

tag-icon • tag-icon domain-name-system
DNS 无法在全球范围内传播

我没有改变任何事物与 serverfault.com 的 DNS 条目相关但今天有些用户报告说serverfault.com DNS 无法解析。

我跑了一个查询我可以大致确认这一点——serverfault.com dns 似乎在少数几个国家无法解析，我不知道具体原因。（也通过我的 DNS 是什么它以类似的方式进行一些全球范围的 ping，因此它被两个不同的来源确认为是一个问题。）

  • 如果我没有触碰 serverfault.com 的 DNS，为什么会发生这种情况？

  • 我们的注册商是 GoDaddy（真恶心），我大部分时间都使用默认 DNS 设置，没有发生任何意外。我做错了吗？DNS 之神抛弃我了吗？

  • 我能做些什么来解决这个问题？有什么方法可以加快 DNS 速度，或者强制 DNS 在全球范围内正确传播吗？

更新：截至周一太平洋标准时间凌晨 3:30，一切看起来都正确。JustPing 报告称，网站可从所有位置访问。感谢您提供许多非常有帮助的回复，我学到了很多东西，下次遇到这种情况时会参考这个问题。

答案1

这不是直接的 DNS 问题，而是互联网某些部分与 serverfault.com 的 DNS 服务器之间的网络路由问题。由于无法访问名称服务器，域名停止解析。

据我所知，路由问题出在 IP 地址为 的路由器（Global Crossing？）上204.245.39.50。

作为显示经过@半径，数据包到 ns52（由stackoverflow.com) 从这里传递到208.109.115.121那里并正常工作。但是，发往 ns22 的数据包却发往208.109.115.201。

由于这两个地址都在同一个网段/24，并且相应的 BGP 公告也是针对/24这个不应该发生。

我已经通过我的网络完成了跟踪路由，最终使用 MFN Above.net 而不是 Global Crossing 到达 GoDaddy，并且没有任何迹象表明该/24级别以下存在任何路由欺骗 - 两个名称服务器从这里都有相同的跟踪路由。

我唯一见过的像这样的东西是坏了思科快速转发（CEF）。这是用于加速数据包路由的硬件级缓存。不幸的是，它偶尔会与实际路由表不同步，并尝试通过错误的接口转发数据包。/32即使底层路由表条目是针对的，CEF 条目也可能下降到级别/24。找到这类问题很棘手，但一旦发现，通常很容易修复。

我已经给 GC 发了电子邮件，也尝试与他们交谈，但他们不会为非客户创建票据。如果你们中的任何人是作为 GC 的客户，请尝试报告此问题...

更新于 UTC 时间 10:38 正如 Jeff 所说，问题现在已经解决。到上述两个服务器的跟踪路由现在都通过208.109.115.121下一跳进行。

答案2

您的 serverfault.com [ns21.domaincontrol.com,ns22.domaincontrol.com] 的 DNS 服务器无法访问。在过去约 20 小时内，至少来自瑞典的几家主要 ISP [特利亚，电话2，bredband2]。

同时，stackoverflow.com 和 superuser.com 的‘邻居’dns 服务器 [ns51.domaincontrol.com、ns52.domaincontrol.com] 可以访问。

到 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 服务提供商 - go daddy。

您可以通过以下方式验证问题是否已[部分]解决：

  1. 检查 godaddy 是否已做出反应并更改了名称服务器 - 例如查找 serverfault.comhttp://www.squish.net/dnscheck/使用记录类型：ANY
  2. 检查所提供的名称服务器是否响应 ping [不太科学，因为名称服务器可以正常工作并且仍然阻止 icmp，但在这种情况下，似乎 icmp 被允许发送到其他服务器] 来自 telia 通过镜子。

编辑：来自工作地点的跟踪路由

波兰

 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

编辑：现在确实一切正常。

答案3

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

serverfault.com 目前的 DNS 设置非常差，对于像这样的重要网站来说，这显然不够：

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

我们刚刚看到了结果：路由故障（在互联网上很常见）足以让 serverfault.com 对于某些用户消失（取决于他们的运营商，而不是他们的国家）。

我建议添加更多位于其他 AS 的名称服务器。这将允许故障恢复。您可以将它们出租给私人公司，也可以要求 serverfault 用户提供辅助 DNS 托管（可能仅当用户拥有 > 1000 个代表时才提供 :-)

答案4

最方便的做法是查看失败位置的详细解析跟踪...查看失败的解析路径层。我不熟悉您使用的服务，但也许这是某个地方的一个选项。

否则，问题很可能出现在树的“较低层”，因为根或 TLD 的故障会影响更多域（您希望如此）。为了提高弹性，如果 domaincontrol 的网络出现问题，您可以委托第二个 DNS 服务以确保更好的冗余解析。

相关内容