『前バージョンの主張は誤りだった』と自分で書く珍しいIETFドラフト──MCPサーバーをDNSで見つけるdraft-morrison-mcp-dns-discoveryを読む

「あるドメインの裏にMCPサーバーが立っているかどうか」を、DNSに問い合わせるだけで機械的に確認できるようにする——IETF個人ドラフト「Discovery of Model Context Protocol Servers via DNS TXT Records」（著者B. Morrison氏、Alter Meridian Pty Ltd所属、rev05は2026年7月22日提出）の本文を読んだ。この記事でこれまで扱ってきた個人ドラフトの多くとは違い、このドラフトには「過去の版で自分が主張したことは間違っていた」と明示的に書かれた箇所が複数ある。

3行まとめ

• このドラフトは3種類のDNS TXTレコードを定義する。_mcp.<domain>はMCPサーバーのエンドポイントURL・対応プロトコル・トランスポート・暗号学的身元・機能プロファイルを、_org-alter.<domain>は運営組織の法人格・登記番号・活動地域などを、_alter.<domain>はEd25519署名付きの「ハンドル」と公開鍵を紐づける身元エンベロープを広告する
• v05は「前の版（v04）を訂正するだけで、新しい仕組みは導入しない」と明記した改訂で、個人単位の身元エンベロープをDNSに公開することを「列挙・サイズ・削除困難性の観点からNOT RECOMMENDED（非推奨）」に格下げしている
• v04が主張していた複数のセキュリティ上の防御（IdentityLogによる証人メカニズムなど）について、v05は「この防御は仕様通りには機能せず、v04がそう機能すると主張したのは誤りだった（this defence does not hold as specified, and revision 04 was wrong to claim it did）」と明示的に撤回している

3種類のTXTレコード

サービス発見用の_mcp.<domain>レコードは、次のようなABNF文法を持つセミコロン区切りのキー・バリュー列として定義されている。

_mcp.<policy-domain>. IN TXT "<record-value>"

mcp-record = version *( ";" field )
version    = "v=mcp1"
field      = url-field / proto-field / transport-field / pk-field / ...
url-field  = "url=" https-uri
pk-field   = "pk=" algo ":" base64url

_org-alter.<domain>は運営組織の身元、_alter.<domain>はEd25519署名済みの「ハンドル（~handle）」を公開鍵に紐づける個人単位の身元エンベロープを扱う。この3種類は独立して発行でき、ドラフトは「ドメインはこれら3つのレコードの任意の組み合わせを公開してよい（MAY）」——サービスのみ、身元のみ、エンベロープのみ、あるいはその交差のいずれでもよい、としている。

v05の自己修正——「NOT RECOMMENDED」への格下げ

このドラフトの要約には、珍しく率直な改訂の説明がある。

This revision (v05) corrects earlier ones and introduces no new mechanism. It withdraws several claims that v04 could not support, marks publication of a per-individual envelope in DNS as NOT RECOMMENDED on enumeration, size, and erasure grounds

（この改訂（v05）は以前の版を訂正するものであり、新しい仕組みは導入しない。v04が裏付けられなかった複数の主張を撤回し、DNSへの個人単位のエンベロープ公開を、列挙・サイズ・削除困難性の観点から非推奨（NOT RECOMMENDED）に位置づける）

「列挙（Enumeration）」の問題は本文でこう説明されている。

Where a zone co-hosts several handles at one owner name, a single query returns the entire set. That is a membership roll, published to the internet, retrievable by anyone, and the individuals listed in it cannot each consent to the disclosure of the others.

（あるゾーンが複数のハンドルを同一の所有者名でホストしている場合、1回の問い合わせで全件が返る。これは、インターネットに公開され、誰でも取得できる会員名簿のようなものであり、そこに列挙された個人それぞれが、他者の情報開示に同意する立場にはない）

「その防御は機能しない」という自己批判

セキュリティ考慮事項では、より踏み込んだ自己批判が書かれている。

IdentityLog witness. This defence does not hold as specified, and revision 04 was wrong to claim it did. Revision 04 stated that substitution of a locally-minted envelope that had not been witnessed would fail, and that an attacker would have to corrupt a log mirror. Neither is true of the mechanism this document specifies.

（IdentityLogの証人機構。この防御は仕様通りには機能せず、v04がそう機能すると主張したのは誤りだった。v04は、証人を経ていないローカル生成のエンベロープへの差し替えは失敗するはずであり、攻撃者はログミラーを改ざんする必要があると述べていた。しかし、いずれもこの文書が規定する仕組みの実際とは異なる）

IETFの個人ドラフトは何度も改訂を重ねる過程で内容が変わっていくものだが、「前の版の自分の主張が技術的に誤りだった」とここまで明示的に書き記す例は、この一連の記事で読んできた他のドラフト群と比べても目立って珍しい。

_mcpレコードが運ぶ13個のフィールド

サービス発見用の_mcp.<domain>レコードが実際に運ぶ情報は、Section 5.3で1フィールドずつ定義されている。必須はv（バージョン、リテラル文字列mcp1固定）とurl（サーバーエンドポイントの、httpsスキーム必須のURL）の2つのみで、残りはすべて任意（OPTIONAL）だ。本文を確認すると、次の13フィールドが定義されている。

特にtransportフィールドの扱いは、このドラフト自身の改訂履歴が絡んで複雑になっている。v04以前（rev01）ではprotoフィールドがトランスポートを兼ねる設計だったため、v05は「transportフィールドを出す発行者はproto=mcpも必ず出さなければならない（MUST）」という規則を追加し、旧世代クライアントが未知の値に遭遇したら安全側にスキップする、という後方互換の読み取り手順（Step A→Step Bの2段階）をSection 5.3.5でかなりの分量を割いて説明している。単純に見える2つのフィールドの背後に、版をまたいだ互換性の作り込みがある。

実装は「truealter.comの1レコードだけ」——v05が書き直した実装状況セクション

このドラフトのSection 19（Implementation Status、RFC 7942に基づく）は、前節までの自己修正よりもさらに率直だ。冒頭の一文がこうだ。

This section was materially wrong in revision 04, which described a deployment that does not exist. It is rewritten here against the zone as it actually resolves and the code as it is actually written. What follows is deployed, and nothing else is claimed.

（このセクションはv04で実質的に誤っており、実在しない導入事例を記述していた。ここでは、実際に解決されるゾーンと実際に書かれたコードに即して書き直している。以下に書かれているものだけが実際にデプロイされており、それ以外は主張しない）

著者自身のドメインtruealter.comについて、実際に何が動いていて何が動いていないかを本文から拾うと次の通り。

ドラフトは、Section 7が定義する「Envelope Record」について「この文書の執筆時点で、著者の知る限りこのゾーンにも他のどのゾーンにも準拠デプロイは存在しない。仕様化され、検証器には実装されているが、未公開のままだ」と明記している。設計自体は書けていても、動いている実例は自分のドメインの中の1レコードに限られる、という状態だ。

関連ドラフト群の相互関係までは検証していない

このドラフトの著者B. Morrison氏は、この記事で以前扱った「MCPツールサーフェス名のIANAレジストリ」ドラフトの著者と同一人物で、同じorg_alter_という接頭辞を使う関連ドラフト群を構成している。この記事ではその関連ドラフト群全体の相互関係までは検証していない。DNSSECの検証やDANE TLSAピンといった、このドラフトが要求する暗号学的な前提条件の実装可否についても、この記事では専門的な評価をしていない。この記事を書いている自分自身はDNS運用の実務経験がなく、この設計が実際にどこまで導入されうるかについても検証できていない。日本語ではZenn・Qiitaともに、このドラフト単体を扱った記事は検索時点で見当たらなかった。

関連記事: MCPの『誰が・どのツールを呼んでいいか』をOAuthの外側で決める──OpenID AuthZENのCOAZ-MCPドラフトを読む

感想・指摘はコメント欄へ。