1. 链下入口：web3 运营安全从这里开始
web3 项目的安全边界早已延伸到智能合约之外。服务器密钥泄露、前端被篡改、DNS 解析被劫持——这些事情发生在合约之外，却直接改变了用户加载的页面和签署的交易。从用户的角度来看，攻击是发生在链上还是链下几乎没有区别。真正重要的是，他们是否被引导到了错误的入口点。
合约审计相对成熟。链下运营安全则不然：长期以来一直缺乏一个项目团队可以持续应用、第三方也可以验证的通用框架。Security Alliance 发布的开放式运营安全认证框架 SEAL Certifications [1]，正是针对这一空白而构建的。它将运营安全划分为六个模块：多签操作、资金库操作、事件响应、DevOps 与基础设施、DNS 与注册商、身份与账户管理。
本文沿着这条线索，深入研究六个模块中的一个——DNS 与注册商。它位于用户到达项目的路径最前端，这使其成为攻击者绕过合约层防御最直接的方式。我们并未尝试进行详尽的运营安全评估，而是采取了外部视角，提出了一个更聚焦的问题：领先项目摆在用户面前的公共入口点，配置得究竟如何？
为了回答这个问题，我们基于 SEAL DNS 与注册商模块 [2] 开发了 BlockSec DNS Security Scanner（BDSS），并将其应用于属于 DefiLlama TVL Top 100 的 100 个唯一域名——每个域名进行八项标准化检测，共计 800 项检测。经人工确认后，基线差距既普遍又集中于少数几项控制措施：样本中仅有 1% 通过了全部检测，超过九成的域名触发了至少一个入口点信号。72% 没有 CAA 记录，47% 出现了 DNSSEC 验证缺陷，电子邮件认证和域名锁定也暴露出各自明显的短板。
2. DNS 与注册商：用户面前的安全边界
DNS 将人类可读的域名转换为可访问的服务地址。它是用户到达项目网站、交易前端、文档以及业务 API 和官方邮箱的链下入口点。一旦解析路径或域名控制权被攻破，用户就可能在毫无察觉的情况下被带到一个伪造页面——随之而来的每一次钱包连接、签名和交易都将失去根基。因此，DNS 与注册商不应被视为普通的基础设施配置，它们属于项目运营安全边界的一部分。
公开事件已经将这种风险具体化。Curve Finance 在 2022 年和 2025 年两次遭受 DNS 劫持 [3][4]。2023 年 10 月，一名社会工程学攻击者接管了 Galxe 的注册商账户，并将访问者引导至恶意前端；该项目披露约有 1,120 名用户受到影响 [5]。2025 年，Aerodrome Finance 的主域名遭受了前端攻击 [6]。2026 年 4 月，攻击者获取了 CoW Swap 的域名控制权，并将用户引导至钓鱼页面，损失估计约为 120 万美元 [7]。此前的 cBridge BGP 路由劫持事件进一步说明了一点：用户并不总能依靠浏览器警告来判断入口点是否出错 [8]。在这些案例中，链上合约本身未必存在问题，但用户资金依然面临风险，因为访问路径已经失控。
原因各不相同，但归结起来是四种直接影响用户入口点的攻击路径。第一，攻击者篡改 DNS 记录或解析路径，将访问者引导至恶意前端。第二，证书发行控制被绕过或配置错误，使伪造网站能够获取浏览器信任的 TLS 证书。第三，注册商账户或域名控制权被接管，从而可以转移域名或更改 NS 等关键记录。第四，攻击者冒充项目品牌或邮箱，诱导用户进入钓鱼页面。这四者都可能导致相同的结局：用户到达了错误的界面，并被诱导完成错误的签名、授权或交易。
其根本要点在于：用户入口点不是一个孤立的网页，而是由域名控制权、DNS 解析、TLS 证书和官方通信共同构成的一条信任链。 即使链上合约完美无缺，只要其中一环失守，攻击者就能利用项目自己的域名或品牌，将用户引向错误的页面和错误的交易流程。对项目团队而言，目标不是孤立地修补某一项设置，而是要确保域名不能被未经授权地转移，解析不能被悄然更改，证书发行受到适当约束，官方邮箱难以被冒充。接下来的外部扫描覆盖的正是这条信任链中可从公共互联网观察到的部分。
3. BDSS：设计与范围
为了将这些入口点风险转化为团队可以切实采取行动的工作，我们围绕 SEAL DNS 与注册商模块 [2] 中可外部观察的控制项构建了 BDSS。它并非要取代项目内部的审查，而是建立一个基线，用于在不触及任何敏感运营资料的前提下，揭示公开的配置差距。
SEAL DNS 与注册商模块 [2] 提出了一套完整的评估框架，既涵盖技术控制——解析、证书、邮件、域名控制——也涵盖域名资产管理、账户访问控制、变更管理、监控告警和事件响应等运营要求。
BDSS 将范围收窄至可从外部观察和验证的控制项，从而能够大规模识别解析、证书、邮件以及注册商方面的公开配置风险信号。它涵盖八项标准化检测。
| 检测项 | 关注点 | 潜在影响 |
|---|---|---|
| DNS 可解析性 | 域名是否能解析到有效的 IP 地址 | 解析失败或超时可能导致网站及其他用户入口点无法访问 |
| DNSSEC 验证 | 解析的信任链是否可被验证 | 解析结果更容易被伪造或篡改，用户可能被引导至伪造前端 |
| CAA 与 TTL 关联度 | 限制哪些 CA 可以签发证书，并评估关键记录的 TTL | 证书签发面被扩大，或事件发生时解析变更和恢复速度变慢 |
| CAA 与 CT 关联度 | CAA 授权范围与公开证书记录之间的关系 | 异常签发或过宽授权更难被及时发现和处理 |
| 邮件认证 | SPF、DKIM、DMARC 和 MTA-STS | 项目域名更容易被用于钓鱼邮件或虚假公告的冒充 |
| 域名锁定 | 公开 RDAP 状态中的转移锁定和注册局锁定信号 | 域名可能被未经授权地转移 |
| TLS 证书 | 证书有效性及即将到期信号 | 浏览器警告或服务中断，削弱用户对官方网站的信任 |
| 域名到期状态 | 域名到期和续费提醒信号 | 网站和邮件服务中断；域名一旦被释放，可能被用于品牌冒充 |
BDSS 并不等同于对项目 DNS 的完整安全认证。无法从公共互联网验证的控制项——如注册局锁定、变更审批、恢复流程——仍需依据项目自身的文档和流程进行审查。
4. DefiLlama Top 100 的外部扫描结果
本次评估于 2026 年 8 月 17 日完成，使用截至当日的 DefiLlama TVL Top 100 榜单。主域名的识别起点是项目呈现给用户的公开入口点。经人工确认后，重复候选项、非官方网站以及用途无法确定的域名被排除，最终保留 100 个唯一域名。每个域名均针对用户入口点风险基线运行了八项标准化检测。结果仅描述从公共互联网可观察到的配置状态；不能替代对内部流程的评估或正式认证。每项检测的结果为以下三种状态之一。PASS 表示公开可见的配置符合该检测项所实现的、源自 SEAL DNS 与注册商模块的外部可观察标准。WARN 标记需要关注的信号——例如证书或域名即将到期、CAA 授权的 CA 数量过多、TTL 过长。FAIL 表示未满足 SEAL 控制项的明确要求（例如 DMARC 未设置为 p=reject），或对应的安全实现未达标（例如 SPF DNS 查询次数超过十次）。
4.1 总体结果
本次扫描覆盖 100 个域名，每个域名接受八项标准化检测，共产生 800 项结果：232 项 FAIL，119 项 WARN。按域名统计，86 个至少触发一项 FAIL，13 个没有 FAIL 但至少有一项 WARN，仅有 1 个通过了全部检测。换言之，在所观察到的公共入口点中，全面覆盖 DNS 运营安全基线控制项仍属例外。
按检测类型划分，FAIL 结果集中于三个方面——CAA、DNSSEC 和邮件认证，而 WARN 结果最常出现在 CAA 授权范围和域名到期状态方面。下表给出了每项检测的 PASS、WARN 和 FAIL 分布情况，以及各结果的主要来源。
| 检测项 | PASS | WARN | FAIL | 说明 |
|---|---|---|---|---|
| DNS 可解析性 | 100 | 0 | 0 | 所有域名均正常解析 |
| DNSSEC 验证 | 53 | 0 | 47 | FAIL 主要源于缺少 DNSKEY 或父区 DS，或最终解析未能形成可验证的信任链 |
| CAA 与 TTL 关联度 | 24 | 4 | 72 | FAIL 全部源于关键域名未发现 CAA；WARN 源于 TTL 超出策略范围 |
| CAA 与 CT 关联度 | 15 | 13 | 72 | FAIL 全部源于关键域名未发现 CAA；WARN 源于超过五个 CA 获得 CAA 授权 |
| 邮件认证 | 62 | 0 | 38 | FAIL 主要源于 DMARC 未达到 p=reject、缺少 rua，或 SPF 查询次数超过 10 次 |
| 域名锁定 | 7 | 90 | 3 | FAIL 源于 RDAP 状态显示未设置转移锁定；WARN 源于注册局锁定状态无法确定 |
| TLS 证书 | 98 | 2 | 0 | WARN 表示证书剩余有效期不足 30 天 |
| 域名到期状态 | 90 | 10 | 0 | WARN 表示域名已进入 90 天到期提醒窗口 |
4.2 主要配置差距
综合来看，领先项目的公共 DNS 配置基线仍显不足，且这些差距并不集中于单一技术控制项。CAA 缺失、DNSSEC 信任链不完整、邮件认证策略宽松，以及仍需验证的注册商侧保护措施，分别影响着证书签发、解析可信度、品牌通信和域名控制权。这些因素共同构成了用户在到达官方入口点时所隐含依赖的条件。以下列出四个具有代表性的差距。
-
CAA 签发约束普遍缺失：72 个域名未配置 CAA。 CAA 记录限制了哪些 CA 可以为域名签发 TLS 证书 [9]。它的缺失并不意味着攻击者可以直接获取证书，但确实说明项目没有通过 DNS 设置额外的签发边界。如果域名验证或相关控制平面被攻破，能够接受证书请求的 CA 集合就更难被限制。对于 web3 前端而言，CAA 主要在复合攻击场景中起作用：攻击者若同时干扰域名验证、DNS 解析或流量转发，就不会面临额外的 CA 范围约束，这增加了伪造前端呈现浏览器信任证书的可能性。
-
DNSSEC 信任链不完整：47 个域名验证失败。 失败主要表现为缺少 DNSKEY（34 个域名）或缺少父区 DS（40 个域名），两者存在重叠。缺少这些记录时，外部验证解析器无法建立完整的 DNSSEC 信任链 [10]。DNSSEC 不能阻止注册商账户被接管或前端代码被篡改，但它有助于验证解析结果是否被伪造或缓存污染。对于要求用户连接钱包并签署交易的协议而言，缺少这一验证层意味着用户可能被引导至错误的地址、服务器或合约，而界面看起来基本没有变化。
-
邮件认证策略薄弱：38 项检测未通过。 部分域名同时存在多个问题：35 个尚未将 DMARC 策略提升至
p=reject[11]，6 个未配置rua汇总报告地址，4 个 SPF 授权链过长 [12]。宽松的 DMARC 策略削弱了对冒充邮件的强制处理力度，缺少rua削弱了持续监控能力，而超出 SPF 查询限制会导致验证错误。由于项目邮件经常承载安全公告、空投说明和迁移通知，这些差距使冒充邮件更容易成为进入伪造前端或钓鱼流程的有效入口。 -
域名控制保护仍待验证：3 个域名未显示转移锁定，另有 90 个域名的注册局锁定状态无法确定。 在公开的 RDAP 状态中，只有 7 个域名展示了相对完整的锁定信号；对于其余大多数域名，只能确认转移锁定，而是否启用了注册局锁定，则需通过注册商控制台或注册局文档进行核实。转移锁定是防止未经授权转移的基本措施；注册局锁定更适合用于承载主前端、文档和 API 的高价值域名。续费管理同样关乎控制权的连续性：扫描发现有 2 个 TLS 证书处于 30 天警戒窗口内，10 个域名处于 90 天到期提醒窗口内。对于承载关键入口点的域名，自动续费、分级提醒以及指定主备负责人等控制措施，可以防止证书或域名到期演变为服务中断或入口点控制权丧失。
5. 结果对当前 web3 DNS 安全状况的启示
扫描结果表明，领先 DeFi 项目的公共 DNS 配置基线仍覆盖不足。在 100 个域名中，仅有 1 个通过了全部检测，86 个至少触发一项 FAIL。主要差距涉及 CAA、DNSSEC、邮件认证和域名锁定——分别影响证书签发约束、解析验证、品牌通信以及域名本身的控制权。
这些差距并不局限于解析层或某一项技术控制。它们分布在域名、解析、证书和邮件等用户访问路径中的多个不同环节。CAA 和 DNSSEC 覆盖率偏低尤其说明，尽管域名控制权、证书和解析路径直接处于用户面前，这些入口点控制项在样本中尚未得到一致部署。这些外部信号并不表明任何项目已遭受入侵。但当攻击者干扰 DNS 解析、通过不规范流程获取有效证书、接管注册商账户或冒充官方邮箱时，缺失的控制措施会削弱已有的防御能力，使用户更容易被引导至伪造页面或钓鱼流程。证书和域名续费管理不足同样可能导致官方入口点中断。
BDSS 能够从公共互联网识别配置差距，并建立可比较的外部安全基线。然而，它无法充分证明诸如注册局锁定、注册商账户多因素认证、关键变更确认、监控告警或事件响应等运营控制措施——这些都无法仅凭公开记录建立。因此，公开信号适合用来描述行业整体状况，识别需要进一步验证的领域，但不应被解读为对任何项目实际运营能力的最终判断。在这一边界内，外部扫描与 SEAL Certifications 相互补充：前者使公开配置差距能够被持续观察和比较，后者则依据运营文档和真实流程，对域名资产、注册商访问控制、变更管理和事件响应等内部控制措施进行验证。作为首批获得认可的 SEAL Certifications 审计机构——也是亚洲唯一一家——BlockSec 可以在这一框架内，帮助项目系统性地评估其运营安全水平。
参考文献
[1] Security Alliance. SEAL Certifications Overview. https://frameworks.securityalliance.org/certs/overview/
[2] Security Alliance. SEAL Certification Framework: DNS Registrar. https://frameworks.securityalliance.org/certs/sfc-dns-registrar/
[3] Curve Finance. 2022 DNS incident statement. https://x.com/CurveFinance/status/1557505570533478403
[4] Curve Finance. 2025 domain incident statement. https://news.curve.finance/curve-domain-incident/
[5] Galxe. October 6th DNS Security Incident Statement & Guide. https://help.galxe.com/en/articles/8452958-october-6th-dns-security-incident-statement-guide
[6] Aerodrome Finance. Domain incident statement. https://x.com/AerodromeFi/status/1992097133869375783
[7] CoW Swap. Domain incident statement. https://x.com/CoWSwap/status/2044924940886163780
[8] Celer Network. cBridge routing incident statement. https://x.com/CelerNetwork/status/1560022871564775424
[9] Hallam-Baker and Stradling. RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record. https://www.rfc-editor.org/rfc/rfc8659.html
[10] Arends et al. RFC 4033: DNS Security Introduction and Requirements. https://www.rfc-editor.org/rfc/rfc4033.html
[11] Kucherawy and Zwicky. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). https://www.rfc-editor.org/rfc/rfc7489.html
[12] Kitterman. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email. https://www.rfc-editor.org/rfc/rfc7208.html
