☰

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，一切看起來都正確。感謝您提供許多資訊豐富的回复，我學到了很多東西，下次發生這種情況時會參考這個問題。

答案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 Below.net 而不是 Global Crossing 來到達 GoDaddy，並且沒有任何低於該/24級別的路由欺騙的跡象 - 兩個名稱伺服器都具有相同的追蹤路由。

我唯一一次見過這樣的東西，它壞了思科快速轉發（CEF）。這是用於加速資料包路由的硬體級快取。不幸的是，它偶爾會與真實的路由表不同步，並嘗試透過錯誤的介面轉送封包。/32即使基礎路由表條目是針對/24.發現這類問題很困難，但一旦發現，通常很容易解決。

我已經給 GC 發了電子郵件，也嘗試與他們交談，但他們不會為非客戶建立票證。如果你們中有人是GC 的客戶，請嘗試回報此...

世界標準時間 10:38 更新 正如傑夫指出的那樣，問題現在已經解決了。到上述兩台伺服器的追蹤路由現在都通過208.109.115.121下一躍點。

答案2

serverfault.com 的 DNS 伺服器 [ ns21.domaincontrol.com、ns22.domaincontrol.com。 ] 無法訪問。在過去約 20 小時內，至少來自瑞典的幾個主要網路服務供應商 [特利亞,電信2,繁殖帶2]。

同時 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 是否做出反應並更改了名稱伺服器 - 例如尋找 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 的故障會影響更多域（您希望如此）。為了提高彈性，您可以委託給第二個 DNS 服務，以確保在網域控制網路出現問題時提供更好的解析冗餘。

相關內容