要約

  • SVCBとHTTPS RRは、代替接続先と固有のパラメータを一つに束ね、発行者の推奨順序を示す。DNSSECはその発行を認証できるが、クライアントの互換性、経路の到達性、TLSのサービス認証までは証明しない。
  • 実行権限はクライアントにある。壊れたレコードと非互換レコードを除外し、必須キーを解釈し、同順位を無作為化し、プロキシとアドレスの方針を適用し、接続とフォールバックを経て元のオリジンを検証する。

優先順位の低い数字を出せば、全利用者がそこへ移る――そう考えると、運用データを読み違える。ある端末は第一候補のHTTP/3へ直行する。別の端末は必須キーを理解できず第二候補へ進む。さらに別の端末は、すでに第二候補と互換性のある接続を開始しており、そのまま再利用する。三者とも同じ署名済みRRsetを見ている。

ゾーンが示すのは推薦を含む選択集合である。現在の状態を持つクライアントが、その集合から実行可能な接続を作る。両者を一つの「DNSによる経路指定」と呼ぶと、責任の位置が消える。

RFC 9460は、汎用SVCBをRRタイプ64、HTTP向けのSVCB互換HTTPSをタイプ65として定義した。アプリケーションとの最初の往復を待たず、代替接続先とプロトコル情報を得られることが利点である。

SvcPriorityが0ならAliasModeとなり、サービスをTargetNameへ委ねる。正の値ならServiceModeで、TargetNameと同じレコード内のSvcParamsが一つの接続候補を構成する。ALPN、ポート、アドレスヒントを接続先ごとに束ねるため、独立したRRsetの更新から不整合な組合せを作りにくい。

AliasModeはCNAMEと同一ではない。問い合わせたSVCB互換タイプにだけ作用し、他のRRタイプをまとめて別名化しない。現行仕様ではAliasModeのパラメータは無視され、追跡できる別名段数も実装が制限する。未対応クライアントのためにA／AAAAを残す必要もある。apexでの委譲を可能にしても、全クライアントを強制移行させる機能ではない。

ServiceModeでは、クライアントが適合性を判定する。不正なワイヤ形式はRRset全体の拒否につながり、認識したパラメータ同士が矛盾するレコードも使えない。未知のキーは通常無視できるが、mandatoryに列挙されたキーを理解できなければ、そのレコードを互換候補から外す。

この仕組みは拡張性の代価を明示する。古い実装は任意機能を無視できる。一方、必須指定は、その機能なしでは正しく動かない接続先を曖昧に使わせない。したがってmandatoryは普及を促す飾りではなく、対応クライアントを意図的に狭める契約である。

2026年6月25日に更新されたIANAのSVCBサービスパラメータ登録簿には、mandatory、ALPN、既定ALPNの抑止、ポート、IPv4／IPv6ヒントに加え、ECH、DoHパス、OHTTP、TLS対応グループ、DNS over CoAP、PvD、ネームサーバーのトランスポート別運用信頼度が載る。登録は番号と意味を固定するが、全実装への普及や全プロトコルでの安全性を保証しない。

優先順位も命令ではない。正の値が小さいほど発行者の推奨は強いが、同順位のレコードはクライアントが無作為に並べ替えて均等化する。SRVのような重みはない。通常は上位の互換候補から試し、失敗すれば下位へ進む。

それでも順序は絶対ではない。RFC 9460は複数候補の並行試行、複数TargetNameの先読み、追加DNS問い合わせが不要な候補の優先、進行中の互換接続の継続を認める。DNSの順位だけから、利用されたソケットを逆算することはできない。

ALPNは発行と実行の境を示す。SvcParamは接続先が提供するプロトコル群を表す。クライアントが対応分だけを残し、RFC 7301に従ってTLSハンドシェイク内で実際のプロトコルを合意する。h3という文字がDNSにあっても、端末がQUICを実装し、経路がUDPを通し、サーバーが交渉に成功するとは限らない。

IPヒントも同様である。A／AAAAが手元にあればヒントを無視し、なければTargetNameのアドレスを問い合わせて将来の接続に使うのがRFC 9460の基本だ。回答が届けば、ヒントで始めた接続を切り替えることもできる。ヒントを永続的なアドレス権限として扱うと、地理的な負荷分散を外すおそれがある。

複数のアドレスがあれば、Happy Eyeballs v2のような方法でIPv6とIPv4を競わせられる。勝者はゾーンファイルではなく、その瞬間のクライアントとネットワークが観測した結果である。

DNSSECが証明する範囲は発行である。HTTPS RRは自動的に真正になるわけではない。RFC 9460はDNSを攻撃者が操作し得る経路としてモデル化し、署名と検証を任意とする。A／AAAAをDNSSECで保護するクライアントは、偽SVCBによる迂回を防ぐため同じ方針を適用すべきである。RFC 4035が検証状態を定義する。

SecureなRRsetは、署名ゾーンがその内容を発行したと示す。接続先が稼働中か、プロキシが許可するか、必須キーを実装しているか、証明書が正しいかは示さない。真正な推薦と成功した接続は、異なる証拠である。

HTTPSのオリジンはTargetNameへ移らない。TLS SNIとHTTPのHost／:authorityは元のオリジンを示し続ける。RFC 9525も、SVCB／HTTPSを使って接続情報を得ても、HTTPやDNS over TLSのPKIX検証要件は変わらないと明記する。CDNへ運用を委ねても、サービス名を定義する権限まで自動移転しない。

RFC 7838のAlt-Svcも、ホスト、ポート、プロトコルを変えながらオリジンを保つ。クライアントは安全基準に沿って代替を選ぶ。HTTPS RRは同種の情報を最初のHTTP応答より前にDNSで得る点が異なり、鮮度にはDNS TTLを使う。RFC 9110が定めるHTTPオリジンと権限は、どちらの経路より上位に残る。

フォールバックは段階導入を可能にする。HTTPのような既存プロトコルでは通常SVCBは任意で、互換候補が失敗すれば従来接続へ戻れる。しかし第一候補のECHやHTTP/3を意図的に失敗させれば、利用者を弱い特性へ追い込める。Alt-Svcもこの降格危険を指摘する。性能向上と最低限守るべき安全性を、同じ「失敗時は戻る」で処理してはならない。

名前ベースのプロキシでは、解決主体も変わる。プロキシがA／AAAAを引く一方、クライアントが別の経路でSVCBを解決すれば、宛先を余計な相手へ漏らしかねない。適切な私的解決を用意できなければ、任意型クライアントはSVCBを無効化し、依存型は設定を無効と扱う。使用時の互換性はプロキシ能力まで含む。

RFC 9461はDoT、DoH、DoQ向けのSVCBマッピングを定める。共通形式だけで接続の意味は完結せず、プロトコルごとに安全なキー、認証、フォールバックを決める必要があることの実例である。

Heng Luの動作するコードを第一に置く議論、最小仕様と局所的な将来判断、現実の層を分ける視点を当てはめると、監査順序が明確になる。仕様、ゾーン発行、リゾルバー応答、クライアント選択、TLS交渉、アプリケーション結果を別々に証明する。

必要なのはタイプ65の応答だけではない。RRsetとDNSSEC、クライアント版、理解したキー、プロキシ方式、選択レコード、アドレス試行、ALPN、証明書、フォールバック理由、最終応答を一つの鎖にする。発行者は候補を証明できる。実際の接続を証明できるのは実行経路である。