DNS无法在全球传播

66

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

我运行了一个查询查询，我可以对此进行某种程度的确认-serverfault.com dns在少数国家/地区似乎无法解决，因为我没有发现任何特殊原因。（也已通过What's My DNS进行了确认，该DNS以类似的方式在全球范围内执行了ping操作，因此有两个不同的来源将其确认为问题。）

如果我还没有接触serverfault.com的DNS，为什么会发生这种情况？
我们的注册商是（gag）GoDaddy，我大部分时候都使用默认的DNS设置，而不会发生任何事件。难道我做错了什么？DNS的众神离弃了我吗？
有什么我可以解决的吗？有什么方法可以使DNS正常运行，或强制DNS在世界范围内正确传播？

更新：截至太平洋标准时间星期一凌晨3:30，一切看起来都正确。.JustPing报告站点可从所有位置访问。感谢您提供了许多非常有帮助的答复，我学到了很多东西，下次再发生时将参考此问题。

domain-name-system

— 杰夫·阿特伍德
source

杰夫，请放心-绝对不是您。它可能是GoDaddy，但更可能是Global Crossing，特别是204.245.39.50上的路由器

— Alnitak

90

这不是直接的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即使基础路由表条目用于，CEF条目也可以下降到该级别/24。找到这类问题很棘手，但是一旦发现问题，通常就很容易解决。

我已经通过电子邮件发送了GC并尝试与他们交谈，但是他们不会为非客户创建票证。如果您是 GC的客户，请尝试报告此问题...

UTC于10:38 UTC更新 正如Jeff所指出的那样，问题现在已经清除。现在，到上述两个服务器的Traceroute经过208.109.115.121下一跳。

— 阿尼塔克
source

9

我希望我能更多地支持你。我在外包世界中很着迷，可以联系Godaddy的1级helldesk，这将不了解很多问题描述，甚至还不了解可能的问题解释……

— pQd

18

您的用于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的示例traceroute：

 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是否已响应并更改了名称服务器-例如在http://www.squish.net/dnscheck/上查找serverfault.com
检查提供的名称服务器是否响应ping [这不是很科学，因为名称服务器可以正常工作并且仍然阻止icmp，但是在这种情况下，似乎允许icmp用于其他服务器]是通过telia通过窥镜从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

编辑：现在一切正常。

— pQd
source

是的，这绝对是一个外部问题，显然只限于欧洲。

— Alnitak

似乎不是整个欧洲。Eircom宽带线路（例如）可以很好地解决serverfault.com。

— Cian

@Alnitak：这不会影响整个欧洲-可以肯定。我可以从瑞典的bredbandsbolaget，波兰和德国的多个isps到达那些naem服务器。

— pQd

尽管Eircom在过去的两周里给客户带来了一些严重麻烦，但DNS 遭到

— Arjan

2

上次我看到这样的问题是Cisco路由器上的CEF表损坏。即使某些主机位于同一/ 24子网中，也可以访问某些主机，而其他主机则无法访问。仅某些ISP受影响仅表明这些ISP有一些共同的供应商。从有效的连接中很难找出原因。

— Alnitak

16

我的建议：正如Alnitak解释的那样，问题不在于DNS，而在于路由（可能是BGP）。DNS问题未更改的事实是正常的，因为问题不在DNS中。

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

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

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

我建议添加更多位于其他AS中的名称服务器。这将允许故障恢复。您可以将它们租给私人公司，也可以要求serverfault用户提供辅助DNS托管（可能仅在用户拥有> 1000 rep的情况下：-）

— Bortzmeyer
source

1

zoneedit.com提供免费的DNS托管，我使用了多年，从来没有遇到任何问题。

— 半径

3

我确实确认，法国的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具有相同的traceroute。在工作地点，我没有越过这个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

— 半径
source

我怀疑您可以通过[bgp]投放比/ 24甚至/ 23小的广告。我宁愿押注过滤然后路由故障。

— pQd

是的，但是204.245.39.50可能是Go Daddy和Global Crossing之间的专用路由器。它可以接受来自父亲的任何路由，但是Global Crossing内部的上游路由器将仅路由/ 24（在BGP表208.109.255.0上被广告为/ 24）。Go Daddy也可以将所有主机广告为/ 32，并且Global Crossing路由器将其聚合为/ 24以进行BGP重新分发

— 半径为

（但我同意那会有些丑陋）

— 半径

1

我敢打赌CEF表损坏……

— Alnitak

2

方便的是从发生故障的位置查看详细的分辨率跟踪...查看发生故障的分辨率路径的哪一层。我对您使用的服务不熟悉，但是也许可以选择在某个地方。

如果失败，则问题很可能在树中“降低”，因为根或TLD的故障将影响更多域（您希望）。为了提高弹性，如果domaincontrol的网络有问题，您可以委派第二个DNS服务以确保更好的解析冗余。

— 子宫
source

2

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

— 保罗·汤姆林
source

1

好吧..最好不要把所有的鸡蛋都放在一个篮子里。可能还有更多功能，而不仅仅是虚拟主机-也许是邮件服务？从弹性角度来看，dns非常不错。最好的做法是将主要dns放在提供程序＃1上，将第二个dns服务器放在其他提供程序上。只要其中任何一个都可以访问-最终用户就可以解决。

— pQd

1

我自托管，但是将ISP的DNS服务器列出为主要服务器，即使它们确实是次要服务器也是如此。是的，这很顽皮，我完全希望听到抱怨的声音……但结果是，我们可以通过Qwest DNS服务器的冗余完全控制自托管DNS。记录的TTL足够高，如果我们无法在3天之内解决问题，那么问题就不仅仅是DNS设置中断了。哦，@ Paul，+ 1表示在“将所有内容都外包出去，因为我们可以的时候”将自我托管作为原始选项。

— 艾利·佩恩

1

至少从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响应。

— ian
source