要約

  • Changshan Suの個人草案は、AIゲートウェイをLAN内で見つけ、経路や公開機能を知らせるDNS-SDレコードを提案する。
  • 発見されたサービスは「候補エンドポイント」。信頼を確認してから、リクエストや認証情報を送る。

プリンターが見つかっただけなら、身元調査まで始める必要はない。AIゲートウェイには、もっと高くつく問いが付いてくる。次のリクエストの料金を払うAPIキーを、誰に渡すのか。

2026年10月26日、Changshan Suは「DNS-Based Service Discovery for AI Gateways」の第00版を個人のInternet-Draftとして提出した。Datatrackerの記録では個人提案で、RFCストリームも予定RFCステータスもない。_ai-gateway._tcpは提案中のサービス名で、IANA登録済みの名前ではないと草案自身が記す。

仕組みの土台は既存のDNS-SDだ。PTRでサービスのインスタンスを列挙し、SRVで宛先ホストとTCPポートを示し、TXTにサービス固有の短い情報を載せ、AまたはAAAAでホストのアドレスを得る。Suの提案は、ゲートウェイのマウントパス、通信の保護、認証の要否、対応プロトコルを短い項目で知らせる。クライアントは固定アドレスを設定に埋め込まず、相手が何を提供すると告知しているかを読める。

容量は意図的に絞ってある。既定のTXTは200バイト未満を目指し、レコード全体は400バイト以内。名前、ポート、パスと数個の申告なら入る。憲法は入らないし、数バイト余計に詰めても決定権は生まれない。

草案が選んだ言葉は「候補エンドポイント」だ。クライアントはサービスレコードを解析した。だが、まだ相手を信頼していないし、認証情報を渡す許可も出していない。提案される順序は、探索、解決、検証、接続、信頼確認、そしてリクエスト。モデル一覧を取得するかは任意だ。APIキーをTXTに書く場所はない。

この順番が必要なのは、LANが機器に名乗らせる場所であって、他人の秘密を使わせる相手を審理する場ではないからだ。草案のセキュリティ節は、同じネットワーク上の参加者がmDNSを偽造し、auth=0を名乗り、SRVを自分の管理するホストへ向けられると説明する。告知されたidは本人確認書類ではない。クライアントは利用者の承認、事前設定された信頼ルール、または検証済みのTLSサーバーIDに頼る。再利用可能なAPIキーを平文HTTPやWebSocketで送るのは、信頼済みのローカル環境として利用者か管理者が明示的に認めた場合に限る。新しい平文の告知で、HTTPSやWSSで信頼済みのゲートウェイを格下げしてもいけない。

RFC 6763にとってDNS-SDの仕事は明快だ。名前の付いたサービスを見つけること。RFC 6762はリンク内のmDNSを定め、名前の衝突処理が協調的な参加者を前提にすると説明する。どちらも、見つかった機器にクライアントの資格情報を使う権利を与えない。呼び鈴は「ゲートウェイはこちら」と知らせる。鍵を持つ人がドアを開けるか決める。

だから三つの判断を分ける設計が効く。発見は場所を示す。TLSのIDは応答したサーバーを確かめる手掛かりになる。クライアントの信頼ルールが、そのサーバーに秘密を渡すか決める。三つを「見つかりました」の緑ランプにまとめれば、ディレクトリーの掲載が許可証に化ける。草案は最後の決定を利用者や管理者に見える位置へ置いた。

現時点の証拠は仕様書であり、現場報告ではない。Datatrackerにあるのは個人の第00版だけだ。提出された資料には相互接続試験、実装比較、導入数がない。採用状況を述べるには、一手の試験報告が必要になる。今見るべきなのは三つの判断の間にある画面だ。承認を求めるなら、ホスト、ポート、パス、TLS状態、認証要件を利用者に示すべきだ。「AIゲートウェイを発見」は検索結果。「この相手に鍵を使わせる」は認可の決定である。

出典