DNSPod - 首席架構師深度解讀：從 Facebook 故障看 DNS 控制面異常處理－鑽石舞台

導語

這個國慶假期互聯網最大的新聞就是某不存在的公司 Facebook 全線業務宕機了 7 個小時，這其中有一個不起眼但是很關鍵的原因是其權威 DNS 節點在檢測到部分網絡異常（可以理解為控制面異常）後進行自我剔除操作，所有 DNS 節點「集體自殺」，從而導致 Facebook 自身及其他使用其權威 DNS 服務的業務全線異常。這裡會簡單聊聊騰訊雲 DNSPod權威 DNS 的控制面異常時是如何處理的，包括曾經的思考與當前的實踐經驗，如何保障在出現類似問題的情況下儘量保障 DNS 服務的連續性，最終方案其實很簡單，一點都不高大上，但好在簡單實用。

權威 DNS 的控制面最主要的工作是同步用戶記錄的修改，不管是通過私有協議還是域傳送，一旦控制面異常，邊緣的 DNS 節點在故障期間無法同步用戶最新的記錄修改數據，終端用戶就可能解析到舊的 IP 上，對業務造成一定影響，所以控制面故障時主要要解決的問題就是如何防止故障節點繼續響應過期記錄。

當前權威 DNS 大多使用多個 IP 同時提供服務，可能是 Anycast 集群，或者單地域集群，或者混合部署，都可以提供一定的容災和負載均衡能力。而遞歸 DNS 對多個不同的權威 DNS 服務 IP 一般是通過 SRTT 方式來選擇使用哪一個 IP 進行請求，可以自動剔除（減少請求）故障的權威 IP，一般只要權威的 IP 列表中有可用的 IP 且容量足夠就可以正常進行遞歸解析。

所以最簡單的處理方式就是直接踢掉控制面異常的權威 DNS 節點，即可保證遞歸不會解析到過期的數據，但是就是這最簡單的踢掉故障節點的操作，其實也會涉及到很多的思考和實踐經驗，下面從頭開始介紹。

控制面故障影響範圍分類

按照影響 DNS 節點範圍和處理方式來區分控制面故障的類型，主要就是兩種類型，部分節點受影響和全部節點受影響。

01.部分節點受影響

這裡可能有多種原因，最常見的如 DNS 節點與控制中心之間的網絡異常，或者部分控制中心從節點故障，只影響少部分邊緣的 DNS 節點的控制面數據同步，那麼這時候故障 DNS 節點自救做自我剔除，將自己從服務集群中摘除貌似完全沒有影響，然後自動/手動切換到其他正常的控制節點或者等待故障的控制節點恢復，再恢復 DNS 節點的對外服務即可。

當然這裡沒有影響是有一個前提的，那就是剩餘節點必須有足夠的服務能力，而故障節點本身因為控制面故障形成了一個孤島節點，是沒有足夠的信息進行相關判斷的，可見即使只有部分節點受影響，故障節點也是不能輕易進行自我剔除操作的。

延伸閱讀：

2009 的「5.19」南方斷網故障，DNSPod 只有免費服務，且多台服務器位於同一機房，因受攻擊被機房拔線導致所有服務器下線，所有使用 DNSPod 進行解析的域名無法解析，暴風影音客戶端解析失敗重試量太大導致運營商 LocalDNS 服務器受衝擊雪崩，進而影響所有用戶的 DNS 解析。

如何解決

從上面的分析可以得出一個結論：權威 DNS 節點在控制面故障時一定不能做自我剔除的操作，因為孤島節點是沒有足夠的信息，無法得出正確的結論，是否應該進行自我剔除，下面是前兩年時討論這個問題的一個截圖，當然這個結論在很多年前其實就已經分析得出了。

故障 DNS 節點能做的是告警、嘗試切換尋找正常的控制節點等操作，很多時候故障節點已經可以自動恢復，比如單獨某個控制從節點故障自動切換即可恢復。但是也有時候無法自動恢復，如 DNS 節點本身內網故障的時候，而且這時候節點本身的告警也是無法正常發出來的^_^。

那就只能通過權威 DNS 節點及控制面之外的外圍監控來進行處理，目前 DNSPod 的實踐經驗是這樣的：

控制面故障監控：

在多個地區多個運營商部署了監控節點，對所有的權威 DNS 的 LB VIP 以及 RS 的物理 IP 持續進行撥測；

每一輪撥測前通過 API 對撥測域名添加一條 TXT 記錄，記錄值為當前撥測點當前時間戳；

正常情況下 DNSPod 所有的權威 DNS 節點的數據同步都是秒級的，所以一旦撥測結果與最新設置的記錄值不一致，則可以判斷該節點數據同步落後，並可以計算出落後的時長，匯總統計所有數據同步落後節點後發出告警，實現對 DNS 節點控制面是否正常的監控；

該監控可以同時對 DNS 節點的數據面是否能夠正常解析進行監控告警。

控制面故障處理：

接下來就需要對控制面故障的 DNS 節點進行處理，此處可以有多種處理方式，自動或手動，DNSPod 目前主要還是手動處理，主要由以下幾個原因：

目前外部的監控節點對 DNS 服務器做的是完全黑盒撥測，很難自動判斷 DNS 節點控制面故障的真實原因，從而無法確定處理方式；

監控節點無法直接控制 DNS 服務器的行為，而通過控制中心處理的話，但是此時控制面已經異常了，可能會陷入死鎖無法處理，還是比如故障節點內網中斷的這個場景；

大部分異常節點已經可以自動恢復，無法自動恢復的告警發生頻率很低。

不同場景處理方式：

本節列出幾個常見的控制面故障場景，以及對應的處理方式

節點本身內網故障：

此時故障節點處於一個網絡孤島，內網中斷，外網因為安全原因禁止登陸，根據不同情況可以由以下幾種處理方式：

如果只是 LB + RS 集群中單獨某台 RS 故障，優先通過 LB 剔除；

如果LB異常或沒有LB（如直接的 OSPF 集群），有帶外，可以通過帶外方式登陸服務器，將該服務器剔除，剔除方式優先選擇停止 OSPF，如果沒有 OSPF，則可以考慮封禁數據面 53 端口的請求以及停止服務程序等方式；

沒有帶外或者帶外故障，如果該故障節點是 Anycast 節點，可以選擇在交換機等處取消 BGP 廣播下掉整個節點，需要能夠快速聯繫到網絡交換機相關負責人，且不會影響其他業務；

直接通過防護系統（宙斯盾）或運營商防護接口在某地域或全地域封禁該IP，此時雖然對應節點的 IP 不可用，但是 LocalDNS 可以通過文章開頭提到的 SRTT 機制去其他正常節點請求，不影響總體解析；

前面的處理方式都有一個前提，就是其他節點容量足夠，但是如果剩餘節點容量不足怎麼辦，此時處理方案是不對 DNS 節點進行下線處理，雖然可能導致部分 DNS 請求會解析到過時的記錄，但是有變化的記錄畢竟是少數，需要優先保證整個大盤的解析正常。此場景在某些極端情況下有一定的出現的可能，比如整個平台遭受持續超大量的 DDoS 攻擊時，同時這台服務器出現了控制面故障，根據具體情況評估影響後可能採取此不處理下線的方式；

在權威解析控制台及註冊局（商）出刪除該 IP，因為 TTL 很長，一般不考慮。

控制中心完全故障導致所有節點控制面故障：

類似此次的 Facebook 的最初始故障，如判斷確實是控制中心就是無法連接，無法同步數據，那麼也只能降級服務，不對 DNS 節點進行下線處理，等待控制中心恢復。

（本文作者：姜鳳波，F-Stack發起人、DNSPod首席架構師，人稱鳳梨叔）

SMB

騰訊雲中小企業產品中心

騰訊雲中小企業產品中心（簡稱SMB），作為騰訊雲體系中唯一專業服務於8000萬中小企業的業務線，致力於為中小微企業提供全面完善貼心的數字化解決方案。產品線覆蓋了企業客戶從創業起步期、規範治理期、規模化增長期、戰略升級期等全生命周期，針對性的解決企業的信息化、數字化、智能化的生產力升級需求。本中心還擁有兩大獨立騰訊子品牌：DNSPod與Discuz!，在過去15年間，為超過500萬企業級客戶提供了強大、優質、穩定的IT服務。

SMB團隊成員大多都有過創業經歷，有獲得過知名VC數千萬投資的，有被一線互聯網巨頭以數千萬全資收購的，也有開設數十家分公司後技術轉型而失敗倒閉的，我們成功過，也失敗過，我們深知創辦企業的難處與痛點，深刻的理解中小企業該如何敏捷起步、規範治理、規模化增長與數字化升級發展，我們會用自己踩坑的經驗給出最適合你的答案。

騰訊雲中小企業產品中心，助力中小企業數字化升級的好夥伴。