DNS-AID、SVCBとDNSSECでエージェント発見レイヤーを構築――MCP・A2Aエンドポイントの中央ディレクトリ依存を解消

DNS-AIDは、エージェント相互運用スタックでまだ標準化されていないレイヤーの課題に取り組もうとしている。すなわち、中央レジストリサービスを知らないエージェントが、別の組織によって提供されるMCP、A2A、またはHTTPSエンドポイントをどのように見つけるかという問題だ。命名形式では、エージェントとプロトコルを `_<agent>._<protocol>._agents.<domain>` に組み込み、RFC 9460のSVCBレコードを使ってホスト、ポート、プロトコル情報を公開する。ケイパビリティ文書のURL、ハッシュ、ポリシー、バージョン、テナントスコープなどの追加メタデータはカスタムパラメーターに格納できる。カスタムSVCBパラメーターをサポートしないDNSプロバイダーでは、TXTレコードにフォールバックする。

この設計の主な利点は、既存のコントロールプレーンをそのまま活用できることだ。企業は自社ドメイン配下でエージェントを公開し、split-horizon DNSを通じて社内外のユーザーに異なる一覧を提示できるほか、DNSSECによってレコードが改ざんされていないことを証明できる。TLSA/DANEを使えば、サービス証明書をDNSのトラストチェーンに結び付けることも可能だ。DNSクエリには既存のキャッシュ機構とグローバルに分散した名前解決能力が備わっているため、エージェント名、エンドポイント、組織IDを単一のプラットフォームに預ける必要がない。仕様自体は通信プロトコルを限定しておらず、SVCBの `alpn` でMCP、A2A、または将来のプロトコルを示せる。

公開されているPythonツールキットにはCLI、SDK、MCP serverが含まれ、Route 53、Cloudflare、Infoblox、およびRFC 2136 Dynamic DNSをサポートする。また、`_index._agents` インデックスの管理、ケイパビリティ文書の取得、発見したエージェントの呼び出し、OpenTelemetry spansの出力も可能だ。短期クレデンシャルは呼び出しのたびにcallbackを通じて動的に取得できるため、長期有効なbearer tokenを発見データに固定して格納せずに済む。

ただし、DNSSECで確認できるのは「このドメインがこのレコードを公開した」という事実だけであり、エージェントの実際のケイパビリティ、モデル品質、実行プログラムの完全性、認可スコープを検証することはできない。ケイパビリティ検索には依然として追加のディレクトリが必要になる可能性があり、TTLキャッシュによって失効の反映も遅れる。さらに重要なのは、現時点の文書が個人提出のIETF Internet-Draftにすぎず、IETFの承認を明示的に意味しない点だ。リファレンス実装の規模も小さい。エンジニアリングチームは次の段階として、命名形式、カスタムSVCBパラメーター、失効セマンティクス、および他のエージェントディレクトリ方式との収束可能性を見極めたうえで、本番環境への導入を判断すべきだ。