主页 / server / 问题 / 42678
Accepted
Jeff Atwood
Asked: 2009-07-20 02:30:32 +0800 CST

DNS 无法在全球传播

  • 772

我没有更改与 serverfault.com 的 DNS 条目相关的任何内容，但今天有些用户报告说serverfault.com DNS 无法为他们解析。

我运行了一个justping 查询，我可以确认这一点——serverfault.com dns 似乎无法在少数几个国家/地区解析，我无法辨别出任何特殊原因。（也通过What's My DNS确认，它以类似的方式在全球范围内执行一些 ping，所以它被两个不同的来源确认为一个问题。）

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

  • 我们的注册商是 (gag) GoDaddy，我在大多数情况下都使用默认 DNS 设置，没有发生任何意外。难道我做错了什么？DNS之神抛弃我了吗？

  • 我能做些什么来解决这个问题吗？有什么方法可以让 DNS 继续前进，或强制 DNS 在全球范围内正确传播？

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

domain-name-system

7 个回答

  1. Best Answer

    这不是直接的 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 公告也是针对/24这不应该发生的。

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

    我见过的唯一一次是这样的，它被破坏了Cisco Express Forwarding (CEF)。这是用于加速数据包路由的硬件级缓存。不幸的是，它偶尔会与真正的路由表不同步，并尝试通过错误的接口转发数据包。/32即使底层路由表条目是针对/24. 发现这类问题很棘手，但一旦发现它们通常很容易解决。

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

    UTC 时间 10:38 更新 正如 Jeff 所指出的，问题现已解决。到上面提到的两台服务器的跟踪路由现在通过208.109.115.121下一个跃点进行。

    • 91

  2. 用于 serverfault.com [ ns21.domaincontrol.com, ns22.domaincontrol.com 的 dns 服务器。] 无法访问。在过去的 ~20 小时里，至少来自瑞典的几个主要 isp [ 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 服务提供商 - 去爸爸。

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

    1. 检查 godaddy 是否已做出反应并更改名称服务器 - 例如使用记录类型在http://www.squish.net/dnscheck/查找 serverfault.com：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

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

    • 18

  3. 我的建议：正如 Alnitak 所解释的，问题不是 DNS，而是路由（可能是 BGP）。DNS 设置中没有任何更改的事实是正常的，因为问题不在他的 DNS 中。

    serverfault.com 今天的 DNS 设置很差，对于像这样的重要站点来说肯定是不够的：

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

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

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

    • 16

  4. 我确实确认 NS21.DOMAINCONTROL.COM 和 NS22.DOMAINCONTROL.COM 也无法从法国的 ISP Free.fr 访问。
    与 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 路由器（Global Crossing）。

    来自工作地点和非工作地点的更多跟踪路由会有所帮助，但 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

    • 3

  5. 方便的是从失败的位置查看详细的分辨率跟踪...查看失败的分辨率路径的哪一层。我不熟悉您正在使用的服务，但也许它是某个地方的一个选项。

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

    • 2

  6. 我很惊讶您没有托管自己的 DNS。这样做的好处是如果 DNS 是可访问的，那么（希望）您的站点也是如此。

    • 2

  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 响应。

    • 1

相关问题