エージェントリソース

​
DNS によるエージェントの発見を検討する

DNS-AID は、DNS の SVCB レコードでエージェントの接続情報やメタデータを発見するための IETF Internet-Draft です。RFC として確定した標準ではありません。すべてのサイトに導入を求める要件ではなく、利用するクライアントと公開するサービスに応じて採用を検討します。

Orchestor は DNS-AID を自動診断していません。 診断画面に項目があることは、DNS を問い合わせた証拠ではありません。対象サイトの公開状態は未確認であり、Orchestor の再スキャンでは DNS-AID を検証できません。

​
草案が扱う発見方法

本ページは draft-mozleywilliams-dnsop-dnsaid-02（2026年5月27日、有効期限2026年11月28日）を参照しています。採用時には版とクライアントの対応状況を確認してください。

  • 既知のエージェントを探す：エージェントの primary owner name に対する SVCB 問い合わせから、接続先などを取得します（第3.1節）。
  • 組織内のエージェントを探す：_index._agents.<domain> への SVCB 問い合わせで、組織のインデックスを指す情報を取得します。インデックスが提供するデータ、プロトコル、スキーマは、この草案では定義されていません（第3.2節）。

組織インデックスへの問い合わせで回答がないことから、すべての個別エージェントのレコードが存在しないとは判断できません。

​
発見と認証・認可を分ける

仕組み確認できることそれだけでは確認できないこと
SVCB による発見公開された接続先とメタデータ接続成功、利用者の権限、操作の成功
検証済みの DNSSECDNS データの出所と完全性エージェントの善性、アプリケーションの利用権限
DANE TLSA草案で述べる方式に沿った TLS エンドポイントの認証アプリケーションの利用者認証や認可

草案は DNSSEC なしの導入も可能としていますが、DNS データの真正性保証は検証された DNSSEC の信頼の連鎖に依存します。TLSA を使う場合は DNSSEC 署名を必要とします。DNS の公開を理由に、既存の OAuth、API キー、ワークスペース認可を外してはいけません（第1.1節、第6.1〜6.4節）。

​
採用前に確認すること

  1. DNS-AID を実際に利用するクライアントと、その版・対応する発見方法を確認します。
  2. 公開する既存の MCP や A2A サービス、接続先、公開メタデータ、認証手順を特定します。スコアのためにサービスを新設しません。
  3. primary owner、接続先、パラメーターの意味を、採用する仕様とクライアントの実装で照合します。追加 SvcParamKey の番号は草案では IANA 割当待ちで、実験的な仕組みも残っています。名前・値・互換性を推測してレコードを作りません（第5節、第7.1節）。
  4. DNS 応答と接続先の公開メタデータを別々に確認し、その後に必要な認証と実際の操作を検証します。各確認で得た事実と、未検証の動作を分けて記録します。

クライアントや公開対象が決まっていない場合は、DNS 設定を変更する前にその選択を行います。本ページは、本番へそのまま適用できるレコード例や、Orchestor 自身が DNS-AID を公開済みであることを示すものではありません。

​
仕様