从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提供过时根域数据时发出警示。同时也检讨内部根域截取和发布的方法，确保新的资源记录类型能够被处理，也扩大测试覆盖范围和流程，避免使用过时的根域数据，减少运营风险。