1. 鏈下入口：web3 運營安全的起點
web3 項目的安全邊界早已超出智能合約的範疇。伺服器金鑰洩露、前端被篡改、DNS 解析遭劫持——這些都發生在合約之外,卻直接改變了用戶載入的頁面以及用戶簽署的交易。從用戶的角度來看,攻擊究竟發生在鏈上還是鏈下幾乎無關緊要。真正重要的是,他們是否被導向了錯誤的入口。
合約審計相對成熟。鏈下運營安全則並非如此:長期以來,業界都缺乏一個項目團隊可以持續套用、且第三方可以驗證的共同框架。SEAL Certifications [1]——由 Security Alliance 發布的開放式運營安全認證框架——正是針對這一空缺而建立的。它將運營安全分為六個模組:多簽操作、資金庫操作、事件響應、DevOps 與基礎設施、DNS 與註冊商,以及身分與帳戶管理。
本文順著這條線索,深入六個模組中的其中一個——DNS 與註冊商。它位於用戶抵達項目的路徑最前端,這使其成為攻擊者繞過合約層防禦最直接的方式。我們並未嘗試進行全面的運營安全評估。我們採取了外部視角,並提出了一個更聚焦的問題:頭部項目呈現給用戶的公開入口,配置得究竟有多完善?
為了回答這個問題,我們基於 SEAL DNS and registrar module [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 and registrar module [2] 中可從外部觀察到的控制措施建立了 BDSS。它並非旨在取代項目內部審查,而是在不觸及任何敏感運營資料的情況下,建立一個用於揭示公開配置缺口的基線。
SEAL DNS and registrar module [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 and registrar module 中可從外部觀察到的標準。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 源於超過五個獲得 CAA 授權的 CA |
| 電子郵件驗證 | 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
