從臺灣時間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提供過時根域資料時發出警示。同時也檢討內部根域擷取和發布的方法，確保新的資源紀錄類型能夠被處理，也擴大測試覆蓋範圍和流程，避免使用過時的根域資料，減少營運風險。