当企业安全团队在日志中发现终端通过 Cloudflare 的 1.1.1.2 DNS 解析 archive.today 时触发 C2 告警，第一反应往往是己方网络已被入侵。但实际情况往往更为复杂 —— 这是一起典型的 DNS 过滤误判问题，涉及递归解析器行为、目标站点的 EDNS 处理策略以及下游安全产品的检测逻辑三者交互。本文将从技术根因出发，推演误判链路并给出可落地的缓解参数与监控阈值。
Cloudflare DNS 产品线的过滤逻辑
Cloudflare 提供了三条公开的递归 DNS 服务：1.1.1.1 为标准解析器，不做内容过滤；1.1.1.2 在递归层面拦截已知恶意软件域名；1.1.1.3 则在此基础上增加成人内容过滤。这三条服务均使用相同的 Anycast 网络基础设施，区别仅在于返回结果前的域名分类检查环节。关键在于，1.1.1.2 的恶意软件拦截列表来自多个第三方威胁情报源，包括 Bambenek、MalwareDomains、URLhaus 等公开 Feed，这些列表在合并过程中可能混入误标条目。
从架构角度看，1.1.1.2 本身并不存储或中转任何 C2 流量，它仅在 DNS 查询阶段比对域名是否命中恶意软件黑名单。如果某个域名被错误地加入这些 Feed，使用 1.1.1.2 的终端将无法解析该域名，表现为 DNS 查询返回 NXDOMAIN 或 SERVFAIL。这种阻断机制与真正的 C2 通信在网络层上截然不同 —— 前者是 DNS 层面的查询失败，后者是实际的数据通道。
archive.today 被误标的触发机制
archive.today（曾用名 archive.is）是一个合法的网页归档服务，允许用户保存任意网页的快照。然而，由于其技术实现方式，它在多个环节容易触发安全检测。首先，该服务使用动态 IP 池和频繁的域名重定向来对抗爬虫和审查，这种行为模式与某些僵尸网络的 Fast-flux 通信高度相似。其次，archive.today 在处理 EDNS Client Subnet（ECS）时与 Cloudflare DNS 存在兼容性问题 —— 当递归解析器不传递 ECS 信息时，归档站点可能返回意外的响应或触发其反滥用检查，导致解析结果不稳定。
从社区历史案例来看，使用 1.1.1.1 或 1.1.1.2 访问 archive.today 时，用户报告过 CAPTCHA 无限循环、页面加载失败、解析出的 IP 在不同请求间剧烈变化等现象。这些现象本身不会直接导致 C2 告警，但当安全产品将「DNS 解析结果频繁变化」与「目标域名属于可疑类别」两条指标叠加时，就可能产生误判。在 2022 年的 Sophos ATP 案例中，安全设备将 Cloudflare 某段 IP 标记为 C2/Generic-A，实际上是该设备的检测规则对 Anycast IP 的行为产生了误读。
安全产品的级联误判链
完整的误判链路通常包含以下环节：威胁情报 Feed 将 archive.today 错误归类为恶意域名 → 使用 1.1.1.2 的终端无法解析该域名 → 安全团队的 DNS 日志捕获大量对 archive.today 的失败查询 → EDR 或网络检测系统将这些失败查询关联到 C2 信标特征（请求频繁、域名非标准、返回 NXDOMAIN） → 最终在告警平台生成「疑似 C2 通信」事件。这一链路中每个环节单独看都是合理的安全检测逻辑，但组合在一起却产生了显著的假阳性。
值得注意的是，部分安全厂商的检测规则对 Cloudflare 的 IP 段存在固有偏见。由于 Cloudflare 承载了互联网上大量合法与非法流量，其 IP 段在某些基于「IP 信誉」的古老检测模型中会被标记为高风险。当终端与这些 IP 发生任何通信 —— 包括上述的 DNS 解析失败 —— 系统可能自动升级威胁等级。
工程化缓解策略与关键参数
针对上述误判链路，企业可从四个层面实施缓解。第一，在 DNS 转发层面配置条件转发规则。使用 dnsmasq 或 AdGuard Home 时，可为 archive.today 及其关联域名（archive.is、archive.ph 等）设置专用上游 —— 当查询这些域名时切换到 8.8.8.8（Google DNS）或 9.9.9.9（Quad9），而非继续使用 1.1.1.2。dnsmasq 配置文件示例如下：
server=/archive.today/8.8.8.8
server=/archive.is/8.8.8.8
server=/archive.ph/9.9.9.9
第二，在安全告警平台配置域名白名单。如果 SIEM 或威胁检测平台已接入 DNS 查询日志，建议将 archive.today 家族加入「已知误报域名列表」，在关联分析时降低其威胁评分。具体参数可设为：将包含 archive.today 的告警置信度阈值从默认的 70% 下调至 30%，并强制要求至少关联一个额外的高危指标（如异常流量规模、非标准端口通信）才触发工单。
第三，在终端检测层面添加诊断日志。当终端通过 1.1.1.2 解析任意域名失败时，记录完整的 DNS 响应码（RCODE）、返回的 IP 列表及查询延迟。建议设置告警阈值为：连续 5 次对同一域名解析失败且响应码为 NXDOMAIN 时，输出诊断级别告警而非安全级别告警，避免安全运营中心收到大量误报。
第四，在威胁情报管理流程中加入人工复核节点。对于来自第三方的恶意软件域名 Feed，建议安全团队每月抽样审计前 100 条新增条目，识别可能的误标。对于 archive.today 这类已知可能误标的域名，可建立静态白名单并与 Feed 供应商保持沟通，推动从源头修正分类。
监控指标与回滚建议
部署上述缓解措施后，建议监控以下指标以验证效果：DNS 解析成功率（针对 archive.today 域名应回升至 99% 以上）、安全平台的 C2 误报工单数量（预期在首周内下降 60% 以上）、条件转发规则的查询命中次数（可反映实际流量走向）。回滚策略应保持简洁 —— 若出现与预期相反的趋势（例如 archive.today 解析成功率下降），立即检查条件转发规则是否被安全策略覆盖，并确保主 DNS 通道仍可用。
整体而言，Cloudflare DNS 对 archive.today 的误判并非单一产品的缺陷，而是 DNS 递归解析、目标站点技术特性、威胁情报质量、安全检测规则四者交互的结果。通过在网络层实施细粒度的 DNS 条件转发，并在安全分析层引入领域知识驱动的白名单机制，可在保持整体安全态势感知能力的前提下，有效消除这一高频误报。
资料来源：Sophos ATP 误报案例（https://www.sophos.com/en-us/blogs/2022/12/atp-reports-cloudflare-188-114-97-3-as-c2-generic-a）