因根域數(shù)據(jù)解析失敗，Cloudflare DNS查詢異常影響大量用戶

從10月4日下午3點到7點之間，Cloudflare的網(wǎng)絡(luò)關(guān)鍵系統(tǒng)DNS歷經(jīng)長達4小時的DNS解析異常，使用1.1.1.1服務(wù)器或使用1.1.1.1的WARP服務(wù)，還有零信任和第三方DNS解析器等產(chǎn)品的用戶，在進行有效查詢時，部分收到了DNS查詢失敗的回應(yīng)。

這次的問題與DNS架構(gòu)有關(guān)。在DNS中，每個域名名稱都位于某個DNS區(qū)域（Zone）內(nèi)，而區(qū)域則是一個包含域名名稱和主機名稱的集合，區(qū)域中的域名名稱和主機名稱皆由同一個管理單位所控制。舉例來說，cloudflare.com這個域名名稱就由Cloudflare管理，而其中的.com屬于頂級域（Top-level Domain，TLD），位于DNS架構(gòu)的最上層，也就是根域中最高級的域名，由ICANN監(jiān)管并且交由各注冊機構(gòu)負責。

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

Cloudflare的遞歸式DNS架構(gòu)也采用這種方法，以加快DNS解析的速度。在Cloudflare上有一支叫做static_zone的WebAssembly應(yīng)用程序，負責加載和解析根域數(shù)據(jù)。而Cloudflare發(fā)生在10月4日的DNS查詢異常，便是根域數(shù)據(jù)更新失敗所導(dǎo)致。

在9月21日的時候，DNS根域執(zhí)行了一項計劃性更新，其中加入了名為ZONEMD的數(shù)據(jù)，用作根域內(nèi)容的校驗和。Cloudflare核心系統(tǒng)會在截取根域數(shù)據(jù)后，發(fā)送到全球Cloudflare數(shù)據(jù)中心，但是當1.1.1.1解析系統(tǒng)在解析ZONEMD數(shù)據(jù)時卻發(fā)生問題，Cloudflare提到，ZONEMD解析失敗就代表，Cloudflare的解析系統(tǒng)未采用新版本的根域數(shù)據(jù)版本。

同時，托管Cloudflare解析基礎(chǔ)設(shè)施的服務(wù)器也沒有接收到新根域，這些服務(wù)器便會針對每個請求查詢DNS根服務(wù)器，但是其他服務(wù)器依賴內(nèi)存中的舊根域數(shù)據(jù)運行，這些數(shù)據(jù)是在9月21日之前的版本。

一直到了10月4日，9月21日版本的根域DNSSEC簽章過期，且由于Cloudflare解析系統(tǒng)無法使用更新版本，所以部分解析系統(tǒng)停止驗證DNSSEC簽章，因此開始發(fā)送錯誤回應(yīng)，這導(dǎo)致Cloudflare解析器產(chǎn)生錯誤回應(yīng)的比例增加12%，為平常錯誤回應(yīng)比例的5倍。DNSSEC用于保護DNS查詢與回應(yīng)的安全擴展，可避免DNS緩存污染等問題。

Cloudflare進一步解釋ZONEMD數(shù)據(jù)解析失敗的原因，在于static_zone該程序不支持新的ZONEMD數(shù)據(jù)的二進制格式。過去Cloudflare一直是使用表示格式（Presentation Format）而非二進制格式，因此在邊緣解析根域的函數(shù)庫不認得二進制格式的資源記錄時，便無法進行解析。

而之所以沒有造成全部DNS查詢失效的原因，在于當服務(wù)器曾經(jīng)重新啟動，且無法加載根域時，便會選擇直接向根服務(wù)器發(fā)送DNS查詢，所以才沒有受到影響。此外，解析器使用一種稱為Serve Stale（RFC 8767）的技術(shù)，可從緩存繼續(xù)提供過期的記錄，也可以避免DNS服務(wù)完全中斷。

針對這個事件，Cloudflare進行檢討，通過強化監(jiān)控來避免之后再發(fā)生類似的事件，會在static_zone提供過時根域數(shù)據(jù)時發(fā)出警示。同時也檢討內(nèi)部根域截取和發(fā)布的方法，確保新的資源記錄類型能夠被處理，也擴大測試覆蓋范圍和流程，避免使用過時的根域數(shù)據(jù)，減少運營風險。