從臺灣時間10月4日下午3點到7點之間,Cloudflare的網路關鍵系統DNS歷經長達4小時的DNS解析異常,使用1.1.1.1伺服器或使用1.1.1.1的WARP服務,還有零信任和第三方DNS解析器等產品的用戶,在進行有效查詢時,部分收到了DNS查詢失敗的回應。

這次的問題與DNS架構有關。在DNS中,每個網域名稱都位於某個DNS區域(Zone)內,而區域則是一個包含網域名稱和主機名稱的集合,區域中的網域名稱和主機名稱皆由同一個管理單位所控制。舉例來說,cloudflare.com這個網域名稱就由Cloudflare管理,而其中的.com屬於頂級域(Top-level Domain,TLD),位於DNS架構的最上層,也就是根域中最高級的域名,由ICANN監管並且交由各註冊機構負責。

根域會指引連接頂級域的方法,因此根域在解析所有網域名稱時,扮演非常重要的角色。雖然根域存放在根伺服器上,但是DNS營運商通常會檢索並且保存根域的副本,這樣就算暫時無法存取根域伺服器,還是可以利用根域副本繼續提供DNS服務。

Cloudflare的遞迴式DNS架構也採用這種方法,以加快DNS解析的速度。在Cloudflare上有一支叫做static_zone的WebAssembly應用程式,負責載入和解析根域資料。而Cloudflare發生在10月4日的DNS查詢異常,便是根域資料更新失敗所導致。

在9月21日的時候,DNS根域執行了一項計畫性更新,當中加入了名為ZONEMD的資料,用作根域內容的校驗和。Cloudflare核心系統會在擷取根域資料後,發送到全球Cloudflare資料中心,但是當1.1.1.1解析系統在解析ZONEMD資料時卻發生問題,Cloudflare提到,ZONEMD解析失敗就代表,Cloudflare的解析系統未採用新版本的根域資料版本。

同時,託管Cloudflare解析基礎設施的伺服器也沒有接收到新根域,這些伺服器便會針對每個請求查詢DNS根伺服器,但是其他伺服器仰賴記憶體中的舊根域資料運作,這些資料是在9月21日之前的版本。

一直到了10月4日,9月21日版本的根域DNSSEC簽章過期,且由於Cloudflare解析系統無法使用更新版本,所以部分解析系統停止驗證DNSSEC簽章,因此開始發送錯誤回應,這導致Cloudflare解析器產生錯誤回應的比例增加12%,為平常錯誤回應比例的5倍。DNSSEC用於保護DNS查詢與回應的安全擴充,可避免DNS快取污染等問題。

Cloudflare進一步解釋ZONEMD資料解析失敗的原因,在於static_zone這支程式不支援新的ZONEMD資料的二進位格式。過去Cloudflare一直是使用表示格式(Presentation Format)而非二進位格式,因此在邊緣解析根域的函式庫不認得二進位格式的資源紀錄時,便無法進行解析。

而之所以沒有造成全部DNS查詢失效的原因,在於當伺服器曾經重新啟動,且無法載入根域時,便會選擇直接向根伺服器發送DNS查詢,所以才沒有受到影響。此外,解析器使用一種稱為Serve Stale(RFC 8767)的技術,可從快取繼續提供過期的紀錄,也可以避免DNS服務完全中斷。

針對這個事件,Cloudflare進行檢討,透過強化監控來避免之後再發生類似的事件,會在static_zone提供過時根域資料時發出警示。同時也檢討內部根域擷取和發布的方法,確保新的資源紀錄類型能夠被處理,也擴大測試覆蓋範圍和流程,避免使用過時的根域資料,減少營運風險。

熱門新聞

Advertisement