[ERC7529] DNSとブロックチェーンを結びつけるスマートコントラクト認証の仕組みを理解しよう！

Posted at 2025-12-11

はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

今回は、DNSのTXTレコードを活用し、企業ドメインとスマートコントラクトの関連性を安全に発見・検証する仕組みを提案しているERC7529についてまとめていきます！

以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。

他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。

概要

ERC7529は、DNS over HTTPS（DoH）を使って、DNSに登録されたTXTレコードをウェブアプリケーションから直接、安全に取得し、スマートコントラクトと一般的なDNSドメインを結びつけて確認できる仕組みをまとめたものです。
TXTレコードは、DNSが提供する自由形式のテキスト情報で、通常はメール送信元の正当性確認や、ドメイン所有者の証明に使われています。

DoHは、DNSをHTTPS経由で取得する仕組みをまとめた標準仕様で、第三者が途中で改ざん（tamper）しにくい安全な取得方法として導入されました。
DoHが広く利用されるようになったことで、ウェブアプリケーション側で直接DNSレコードにアクセスし、その結果を信頼して処理できるようになっています。

ERC7529では、このDoHを利用してDNSのTXTレコードを取得し、そこに「スマートコントラクトへの参照情報」を登録しておくことで、そのドメインとスマートコントラクトの紐づけが確認できるようになります。
これにより、スマートコントラクトの作者になりすます行為を防ぎ、検索エンジンを含む一般的なウェブの仕組みにおいて、スマートコントラクトを見つけやすくする効果があります。

例えば安定型のトークン（いわゆるステーブルコイン）を発行している企業であれば、ユーザーが自分のウォレットを使う時、そのコントラクトが本当に企業の管理するものかどうかを簡単に判定できるようになります。

動機

ブロックチェーンやデジタル資産を扱う企業が増えるにつれ、利用者が「どのスマートコントラクトがどの企業に属しているのか」を簡単に探し、確かめられる方法が求められています。
特に、一般的な企業の活動はドメイン名を中心として行われているため、ウェブの世界で使われている検索や確認の仕組みと相性の良い方法が必要です。

DoHによって DNSの情報を直接読み取れるようになる前は、アプリケーションはDNS情報を取得する時に、自前のサーバーや特定のサービスを経由する必要がありました。
この経路では、サービス提供者が応答を改ざんできてしまう可能性があるため、スマートコントラクトの検証に利用するには適していませんでした。
DoHの普及により、この問題が解消され、ウェブアプリケーションがtamper-resistant（途中改ざんが難しい）なDNS参照を直接行えるようになりました。

Cloudflareなどの事業者によれば、TXTレコードはメール送信の安全性確保やドメイン所有権確認に最も利用されているとのことです。
スマートコントラクトの発見と検証という用途は、これらと同様に「ドメインの所有者が何かを証明する」という性質を持っています。

TXTレコードにコントラクトへの参照を登録し、それを読み取って確認できるようにした場合、以下のような価値があります。

ドメインの所有者が管理するスマートコントラクトを利用者が自動的に見つけ、正当性を判断できるようになる
特定企業が発行したトークンやNFTが本物であるかどうか、利用者やアプリケーションが安心して確認できる
従来のウェブ検索エンジンからも、ドメインに紐づくスマートコントラクト情報を間接的にたどれるようになり、発見性が高まる

以下は、ERC7529の利用イメージを示す例です。

例 1：支払い処理サービスとステーブルコイン

ユーザーが merchant.com のECサイトで商品を購入するとします。
支払い処理は paymentprocessor.com が提供しており、その企業は独自のステーブルコインを発行しています。このステーブルコインはERC7529に準拠しています。

ユーザーが商品を購入すると、サイト内で paymentprocessor.com のページがiframeとして読み込まれます。
ユーザーのブラウザに対応ウォレットがインストールされていれば、ウォレットはiframeのドメイン情報からTXTレコードを調べ、どのスマートコントラクトが paymentprocessor.com に紐づいているかを安全に発見できます。
正しい関連付けを確認できた場合、ウォレットはユーザーに対して「発行元が確認されたステーブルコインで支払いますか？」といった操作を案内できます。

例 2：NFT マーケットプレイスでのブランド確認

nftmarketplace.io にアクセスしたユーザーが、自分の好きなブランド（例：theirfavoritebrand.com）の限定NFTを購入したい場合を考えます。
NFTマーケットプレイスはERC7529を利用して、ユーザーがブランドのドメイン名で検索できるようにし、見つかったNFTが本当にそのブランドに属しているかを示すことができます。

ユーザーにとっては「これは本物のブランドが発行したNFTである」という確認が容易になり、企業側にとっても資産の偽造を防ぎやすくなるというメリットがあります。

仕様

`eTLD+1` の定義

まず、ドメインを扱う際の重要な考え方として eTLD+1 が登場します。

ドメイン名は最後のドットより後ろがトップレベルドメイン（TLD）です。
例えば、 .com や .net のような部分です。
もし、TLDの直下にあるドメインだけが登録可能だったとすると、myexample.com の下にある abc.myexample.com や def.myexample.com は同じ組織が管理していると判断できます。

ところが実際には、.ac.uk のようにTLDの下にさらに登録階層があり、その階層ごとに別の組織がドメインを登録できるケースもあります。
このように、組織が登録可能な最小単位となるドメインを**eTLD（effective TLD）**と呼びます。

例として以下のようになります。

ドメイン名	eTLD	eTLD+1
`myexample.com`	`.com`	`myexample.com`
`sussex.ac.uk`	`.ac.uk`	`sussex.ac.uk`

eTLD+1 は、eTLDにその直上のラベル（組織が登録したドメイン）を合わせたものです。
eTLD+1 が同じであるドメインは同一組織が所有していると判断できるため、ERC7529ではこの単位を使ってスマートコントラクトと組織を関連付けます。

TXTレコードにおけるコントラクト情報の登録

ERC7529では、eTLD+1 を所有する組織が、自分の管理するDNSにTXTレコードを追加し、関連付けたいスマートコントラクトのアドレスを記述する必要があります。

TXTレコードは大量のデータ保存を目的とした仕組みではないため、DNS事業者ごとに文字数制限があります。
ただし、EVM互換チェーンのアドレス表記は42文字程度であり、多くのDNS事業者は複数のコントラクトアドレスを記載できる容量を提供しています。
また、ひとつのホストに複数の TXTレコードを持つこともでき、DoH（DNS over HTTPS）ではそれらをまとめて取得できます。

TXTレコードの形式は以下です。

項目	内容
HOST	`ERC-7529.<chain_id>._domaincontracts`（chain_id は対象チェーンの数値）
VALUE	`アドレス1,アドレス2,…`

EVMアドレスはERC1191形式（チェックサムを含む表記）で記述することが推奨されています。
これによりブラウザ側がアドレスの正当性を簡単に検証でき、誤ったチェーンに接続するリスクを減らせます。

ERC1191については以下の記事を参考にしてください。

TXTレコードはDoHを使うことで、ウェブアプリケーションから直接取得できます。
取得コード例は以下です。

await fetch("https://example-doh-provider.com/dns-query?name=ERC-7529.1._domaincontracts.myexample.com&type=TXT", {
  headers: {
    Accept: "application/dns-json"
  }
})

このように、安全にDNS情報を取得できることで、ウェブアプリケーションが仲介サービスを介さずに正しいコントラクト情報を参照できます。

スマートコントラクトとドメインの関連付け

スマートコントラクトは、必要に応じてERC7529を実装することができます。
この実装により、コントラクトがどの eTLD+1 に属しているかをチェーン上で確認できるようになります。

コントラクト側では、以下の要素を保持します。

eTLD+1 の文字列を keccak256 でハッシュ化した値をキーとする domains マッピング
ドメインを追加する addDomain
ドメインを削除する removeDomain
ドメインが紐づいているかを確認する checkDomain

これにより、外部から「このコントラクトは特定のドメインと関係があるか」を確認できるようになります。
さらに、AddDomain と RemoveDomain のイベントを発行すれば、クライアント側が履歴を追跡して、どのドメインが現在有効なのかを把握することもできます。

コード例は以下です。

{
  /// @notice Optional event emitted when a domain is added
  /// @param domain eTLD+1 associated with the contract
  event AddDomain(string domain);

  /// @notice Optional event emitted when a domain is removed
  /// @param domain eTLD+1 that is no longer associated with the contract
  event RemoveDomain(string domain);

  /// @dev a mapping from the keccak256 hash of eTLD+1 domains associated with this contract to a boolean
  mapping(bytes32 => bool) domains;

  /// @notice a getter function that takes an eTLD+1 domain string and returns true if associated with the contract
  /// @param domain a string representing an eTLD+1 domain
  function checkDomain(string calldata domain) external view returns (bool); 

  /// @notice an authenticated method to add an eTLD+1 domain
  /// @param domain a string representing an eTLD+1 domain associated with the contract
  function addDomain(string calldata domain) external;

  /// @notice an authenticated method to remove an eTLD+1 domain
  /// @param domain a string representing an eTLD+1 domain that is no longer associated with the contract
  function removeDomain(string calldata domain) external; 
}

クライアント側での検証

クライアントアプリケーションは、以下の2つの観点から検証を行えます。

TXT レコードから得た情報をもとに検証する方法
取得したTXTレコードに記載されたコントラクトアドレスを順にチェックし、それぞれに対してRPC経由で checkDomain を呼び出します。
このとき、TXTレコードの対象 eTLD+1 を渡し、コントラクトが true を返すかどうかを判定します。
コントラクト側が保持する情報をもとに検証する方法
コントラクトに対して、AddDomain / RemoveDomain イベントを確認します。
これにより、そのコントラクトがどの eTLD+1 に紐づいているかを知ることができます。
得られた eTLD+1 に対してTXTレコードを取得し、そこに該当コントラクトアドレスが含まれているかを確認します。

クライアントは最終的に以下の点を確認する必要があります。

TXTレコードが正しい eTLD+1 から取得されている
そのレコードの VALUE に対象コントラクトアドレスが含まれている
コントラクト側の domains マッピングでも同じ eTLD+1 が登録されている

これにより、ドメインとコントラクトの相互確認が成立し、高い信頼性をもって「正しい企業・組織が管理するコントラクトである」と判断できます。

補足

ERC7529では、TXTレコードのホスト名（HOST）の付け方に、はっきりとした意図があります。
大きく分けて、以下の2点です。

既存の仕組み（DKIM）に寄せて分かりやすくすること
プログラムから機械的に扱いやすくすること

まず、HOST名の構造はDKIM（メールの送信者認証技術）の命名ルールを真似ています。
DKIMでも特定のサブドメイン名のパターンにTXTレコードを置き、そこに公開鍵や設定を載せています。
ERC7529も同じように、「決まった形式のサブドメイン名にTXTレコードを置けばよい」という形にすることで、DNS管理者やツール開発者にとって理解しやすい設計にしています。

HOST名の基本形は以下です。

ERC-7529.<chain_id>._domaincontracts

ここで <chain_id> は、対象となるブロックチェーンネットワークのチェーンIDを10進数で書いたものです。
例えば、Ethereum Mainnetなら 1、Sepoliaなら 11155111 です。
そのため、ホスト名の具体例は以下のようになります。

対象チェーン	`chain_id`	HOST 例
Ethereum Mainnet	1	`ERC-7529.1._domaincontracts`
Sepolia	11155111	`ERC-7529.11155111._domaincontracts`

先頭に ERC-7529 を付けているのは、他の用途で使われているTXTレコードとの名前の衝突を避けるためです。
メールや他の認証用途など、TXTレコードを使う仕組みはすでに多数ありますが、ERC-7529 という接頭辞を付けることで、「これはERC7529用のTXTレコードだ」と一目で識別できるようにしています。

また、<chain_id> をHOST名の一部として埋め込んでおくことで、クライアントアプリケーションは以下のような流れで処理できます。

あるドメインと、対象のチェーンIDを元にHOST名を組み立てる。
そのHOSTに対するTXTレコードをDoHで問い合わせる。
返ってきた VALUE をスマートコントラクトアドレスの一覧として扱う。

このように、チェーンごとに明確にTXTレコードが分かれているため、「このドメインはこのチェーン上で、どのコントラクトアドレスを公開しているか」をプログラムから簡単に把握できます。

さらに、ERC7529が重視しているのは「DNSとブロックチェーン、2つの独立した情報源が互いに整合しているかを確認する」という点です。

スマートコントラクト側の domains マッピングは、addDomain / removeDomain を通じてのみ更新されます。
これらの関数が適切に認可制御されていれば、domains の内容はコントラクトの管理者だけが操作できます。
TXT レコードに書かれるコントラクトアドレスは、eTLD+1 を所有するドメイン管理者だけが変更できます。

この2つが一致しているということは、「同じ組織がDNSとスマートコントラクトの両方をコントロールしている」ことの裏付けになります。
クライアントは、DNSのTXTレコードと、チェーン上の domains の両方を確認することで、組織とコントラクトの結びつきを、より高い信頼度で判断できるようになります。

セキュリティ

ERC7529は、仕組みの一部として従来のDNSを前提にしているため、DNSにまつわる攻撃の影響を受ける可能性があります。
その代表例が「ドメインハイジャック（domain hijacking）」です。
これは、攻撃者がドメインの管理権限を奪い、DNS設定を書き換えてしまう攻撃です。

DNSに依存する以上、ドメインハイジャックなどによってTXTレコードが不正に書き換えられれば、攻撃者が別のコントラクトアドレスを紐づけることも形式上は可能になります。
そのため、ドメインの管理自体をしっかり保護しておくことが前提になります。

もう1つの重要なポイントは、スマートコントラクト側の設計です。addDomain と removeDomain のような関数には、必ず認可（オーナーや管理者のみ実行できるような制御）が必要です。
ここが甘いと、攻撃者が自分の管理するコントラクトに対して、無関係なドメインを勝手に紐づけることができてしまいます。
その結果、正しいドメインとの関連付けが壊れ、検証が成り立たなくなります。

ただし、攻撃者が「あるドメインと特定コントラクトを、あたかも正しく関連付いているように見せかける（偽の正当性を作る）」ためには、次の両方を同時に乗っ取る必要があります。

ドメインのDNS設定（TXT レコード）
スマートコントラクト（またはその管理権限）

DNSのみ、またはスマートコントラクトのみの片側だけを攻撃しても、もう一方の情報と整合しないため、ERC7529の想定する検証フローでは不正が露呈します。
したがって、実際に偽の関連付けを成立させるには、企業のDNS管理だけでなく、コントラクトのデプロイや権限管理にも侵入しなければなりません。

さらに、DNSを乗っ取れる攻撃者は、同じドメインを使っているメールシステム（MX レコードや SPF/DKIM/DMARC など）にも介入できる可能性が高く、ビジネスのメール通信も危険に晒されることになります。
その意味で、ERC7529におけるセキュリティリスクは、既存の「ドメインを中心としたインターネットの信頼モデル」が抱えるリスクと密接に結びついていると言えます。

まとめると、ERC7529は DNSとブロックチェーンという2つの独立した基盤を組み合わせることで、片側だけの攻撃では破れない検証モデルを提供しますが、その一方で、DNS自体を守る責任や、スマートコントラクト側の認可設計を適切に行う責任は、依然として運用者にあります。

参考実装

function checkDomain(
  string calldata domain
) external view returns (bool) {
return domains[keccak256(abi.encodePacked(domain))];
}

function addDomain(
  string memory domain
) external onlyRole(DEFAULT_ADMIN_ROLE) {
domains[keccak256(abi.encodePacked(domain))] = true;
emit AddDomain(domain);
}

function removeDomain(
string memory domain
) external onlyRole(DEFAULT_ADMIN_ROLE) {
require(domains[keccak256(abi.encodePacked(domain))] == true, "ERC7529: eTLD+1 currently not associated with this contract"); 
domains[keccak256(abi.encodePacked(domain))] = false;
emit RemoveDomain(domain);
}

引用

Todd Chapman (@tthebc01), Charlie Sibbach charlie@cwsoftware.com, Sean Sing (@seansing), "ERC-7529: Contract Discovery and eTLD+1 Association [DRAFT]," Ethereum Improvement Proposals, no. 7529, September 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7529.

最後に

今回は「DNSのTXTレコードを活用し、企業ドメインとスマートコントラクトの関連性を安全に発見・検証する仕組みを提案しているERC7529」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

Twitter @cardene777

他の媒体でも情報発信しているのでぜひ他も見ていってください！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up