1. オフチェーンの入り口:web3の運用セキュリティはここから始まる
web3プロジェクトのセキュリティ境界は、もはやスマートコントラクトの範囲を超えて拡大している。サーバー鍵の漏洩、フロントエンドの改ざん、DNS解決のハイジャック——これらはコントラクトの外部で発生するが、ユーザーがどのページを読み込み、どのトランザクションに署名するかを直接変えてしまう。ユーザー側からすれば、攻撃がオンチェーンで起きたかオフチェーンで起きたかはほとんど問題ではない。重要なのは、誤った入り口へ誘導されたかどうかだ。
コントラクトの監査は比較的成熟している。オフチェーンの運用セキュリティはそうではない。プロジェクトチームが継続的に適用でき、第三者が検証できる共有フレームワークが長らく存在しなかった。Security Allianceが公開した、オープンな運用セキュリティ認証フレームワークであるSEAL Certifications [1]は、まさにそのギャップを埋めるために構築されている。これは運用セキュリティを6つのモジュールに分けている:マルチシグ運用、財務運用、インシデント対応、DevOpsとインフラ、DNSとレジストラ、そしてアイデンティティとアカウント管理だ。
本稿はその流れをたどり、6つのうちの1つ——DNSとレジストラ——に焦点を当てる。これはユーザーがプロジェクトに到達する経路の最前線に位置しており、攻撃者がコントラクトレベルの防御を回避する最も直接的な手段となる。網羅的な運用セキュリティ評価を試みたわけではない。外部からの視点を取り、より絞り込んだ問いを立てた:主要プロジェクトがユーザーの前に提示する公開された入り口は、どれほど適切に設定されているのか?
これに答えるため、SEALのDNSとレジストラモジュール[2]に基づいてBlockSec DNS Security Scanner(BDSS)を開発し、DefiLlama TVL Top 100に属する100個のユニークなドメインに対して実行した——それぞれ8種類の標準化されたチェックを行い、合計800件のチェックとなった。手動での確認を経て、基礎的なギャップは広範かつ一部の管理項目に集中していることが判明した:**サンプルのうちすべてのチェックに合格したのはわずか1%**であり、10ドメインのうち9つ以上が少なくとも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]。これらの事例のいずれにおいても、オンチェーンのコントラクト自体は必ずしも破られていなかったが、アクセス経路が失われたことでユーザーの資金は依然としてリスクにさらされた。
原因は事例ごとに異なるが、ユーザーの入り口に直接関わる4つの攻撃経路に集約される。第一に、攻撃者がDNSレコードや解決経路を改変し、訪問者を悪意あるフロントエンドへ誘導する。第二に、証明書発行の管理が回避または誤設定され、スプーフィングされたサイトがブラウザに信頼されるTLS証明書を取得できてしまう。第三に、レジストラアカウントやドメインの管理権が乗っ取られ、ドメイン移管やNSなどの重要レコードの変更が可能になる。第四に、攻撃者がプロジェクトのブランドやメールを騙り、ユーザーをフィッシングページへ誘い込む。これら4つはいずれも同じ結末につながりうる:ユーザーが誤ったインターフェースに到達し、誤った署名、承認、またはトランザクションを完了させられる。
根底にあるのはこの点だ:ユーザーの入り口は単独のウェブページではなく、ドメイン管理、DNS解決、TLS証明書、公式コミュニケーションからなる信頼のチェーンである。 オンチェーンのコントラクトに欠陥がなくても、たった一つの環が壊れれば、攻撃者はプロジェクト自身のドメインやブランドを利用して、ユーザーを誤ったページや誤ったトランザクションフローへ誘導できる。プロジェクトチームにとって、目標は単一の設定を孤立して修正することではなく、ドメインが無許可で移管されないこと、解決が密かに変更されないこと、証明書発行が適切に制約されていること、そして公式メールが騙りにくいことを確保することである。以下の外部スキャンは、このチェーンのうち公開インターネットから観測可能な部分をカバーしている。
3. BDSS:設計と対象範囲
これらの入り口リスクを、チームが実際に対応できる作業へと落とし込むため、SEALのDNSとレジストラモジュール[2]における外部から観測可能な管理項目を基にBDSSを構築した。これはプロジェクトの内部レビューを置き換えることを意図していない。機密性のある運用資料に触れることなく、公開設定のギャップを明らかにするためのベースラインを確立するものである。
SEALのDNSとレジストラモジュール[2]は完全な評価フレームワークを定めており、解決、証明書、メール、ドメイン管理といった技術的管理に加え、ドメイン資産管理、アカウントアクセス制御、変更管理、監視とアラート、インシデント対応といった運用上の要件もカバーしている。
BDSSはこれを外部から観測・検証可能な管理項目に絞り込み、解決、証明書、メール、レジストラ側にわたる公開設定のリスクシグナルを大規模に識別できるようにしている。8種類の標準化されたチェックをカバーしている。
| チェック | 対象 | 潜在的な影響 |
|---|---|---|
| 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個のユニークなドメインが残った。それぞれについて、ユーザー入り口リスクのベースラインに対する8種類の標準化されたチェックを実行した。結果は公開インターネットから観測可能な設定状態のみを示すものであり、内部プロセスの評価や正式な認証の代替となるものではない。各チェックは3つの状態のいずれかに帰着する。PASSは、公開されている設定がSEALのDNSとレジストラモジュールから導出された、個々のチェックが実装する外部から観測可能な基準を満たしていたことを意味する。WARNは注意を要するシグナルを示す——期限が近い証明書やドメイン、多数のCAAが認可されたCA、過度に長いTTLなどだ。FAILは、SEALの管理項目の明示的な要件が満たされていない(例:DMARCがp=rejectに設定されていない)、あるいは対応するセキュリティ実装が満たされていない(例:SPFのDNSルックアップが10件を超える)ことを意味する。
4.1 全体結果
このスキャンは100個のドメインを対象とし、それぞれに8種類の標準化されたチェックを実施し、合計800件の結果を得た:232件のFAILと119件のWARNだ。ドメイン単位で数えると、86個が少なくとも1つのFAILを発生させ、13個はFAILはないが少なくとも1つのWARNがあり、すべてのチェックに合格したのはわずか1個だった。言い換えれば、観測された公開の入り口のうち、DNS運用セキュリティのベースライン管理項目を完全にカバーしているものは依然として例外的な存在である。
チェックの種類別では、FAILの結果はCAA、DNSSEC、メール認証という3つの領域に集中しており、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は5つを超える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信頼チェーン、緩やかなメール認証方針、そして依然として検証を要するレジストラ側の保護策は、それぞれ証明書発行、解決の信頼性、ブランドコミュニケーション、ドメイン管理に影響を与える。これらは合わせて、ユーザーが公式の入り口にアクセスする際に暗黙的に依拠している条件を構成している。以下、代表的な4つのギャップを示す。
-
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を担う高価値ドメインにより適している。更新管理も管理権の継続性に関わる:このスキャンでは、30日間のアラート期間内にあるTLS証明書が2件、90日間の失効リマインダー期間内にあるドメインが10件見つかった。重要な入り口を担うドメインについては、自動更新、段階的なリマインダー、そして主担当・副担当の指定といった管理策により、期限切れの証明書やドメインがサービス停止や入り口の管理権の喪失につながることを防ぐことができる。
5. これらの結果が今日のweb3のDNSセキュリティについて示すこと
このスキャンは、主要なDeFiプロジェクトにおける公開DNS設定のベースラインが依然として十分にカバーされていないことを示している。100個のドメインのうち、すべてのチェックに合格したのはわずか1個で、86個が少なくとも1つのFAILを発生させた。主なギャップはCAA、DNSSEC、メール認証、ドメインロックに関わるものであり、証明書発行の制約、解決の検証、ブランドコミュニケーション、そしてドメイン自体の管理に影響を与えている。
これらのギャップは解決層や単一の技術的管理項目に限定されるものではない。ドメイン、解決、証明書、メールという、ユーザーの入り口経路における複数の異なる環にわたって分散している。特にCAAとDNSSECのカバー率の低さは、ドメイン管理、証明書、解決経路がユーザーの目前に位置しているにもかかわらず、これらの入り口の管理項目がサンプル全体で一貫して導入されているわけではないことを示している。これらの外部シグナルのいずれも、プロジェクトが侵害されたことを示すものではない。しかし、攻撃者がDNS解決に干渉し、不正な手順で有効な証明書を取得し、レジストラアカウントを乗っ取り、あるいは公式メールを騙る場合、こうした管理の欠落は既存の防御を弱め、ユーザーがスプーフィングされたページやフィッシングフローへ誘導されやすくしてしまう。証明書やドメインの更新管理が不十分な場合も、公式の入り口を中断させる可能性がある。
BDSSは公開インターネットから設定のギャップを識別し、比較可能な外部セキュリティのベースラインを確立することができる。しかし、レジストリロック、レジストラアカウントのMFA、重要な変更の確認、監視とアラート、インシデント対応といった運用上の管理策を十分に示すことはできない——これらはいずれも公開記録のみからは確立できないものだ。したがって公開シグナルは、業界の状態を記述し、さらなる検証を要する領域を識別するのに適しているが、いずれかのプロジェクトの実際の運用能力に対する最終的な判断として読まれるべきではない。この境界の中で作業する限り、外部スキャンとSEAL Certificationsは互いを補完する:前者は公開設定のギャップを継続的に観測・比較可能なものにし、後者は運用ドキュメントと実際のプロセスを基に、ドメイン資産、レジストラアクセス制御、変更管理、インシデント対応に対する内部管理を検証する。第一期の認定を受けたSEAL Certificationsの監査人として——そしてアジアで唯一の存在として——BlockSecは、このフレームワークの中でプロジェクトが自身の運用セキュリティを体系的に評価することを支援できる。
References
[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
