要約

  • HTTPS DNSレコードは接続手順を公表するが、接続試験を実行するものではない。
  • 実際の選択は、優先度、理解できるパラメータ、名前解決結果、クライアント能力で変わる。
  • アドレスヒント、ALPNの広告、フォールバック後の成功は別々の証拠である。
  • 運用準備の確認には、観測したRRsetと重要な各クライアント群の認証済み応答を結ぶ検証記録が必要だ。

新しいHTTPSレコードがDNSに現れた瞬間、展開画面が緑になる場面を考える。レコードはHTTP/3とIPv6アドレスヒントを示す。通常のブラウザ監視ではページが開くため、移行は完了扱いになる。ところが、あるモバイル接続群からのHTTP/3はすべて失敗している。ページが届くのは、クライアントが元のエンドポイントのHTTP/2へフォールバックするからだ。

DNSレコードが虚偽なのではない。公表を配信と同一視した判断が誤っている。

RFC 9460 はSVCBとHTTPSリソースレコードを定義し、通常の接続を開始する前に代替エンドポイントと接続パラメータをクライアントへ伝える。往復時間の削減、HTTP/3への直接接続、非標準ポート、関連パラメータの一体的な提示に役立つ。これは有用な制御面情報だが、合成トランザクションではない。

レコードの構造は選択を左右する。SvcPriorityがゼロならAliasModeで、サービス解決を別名へ委ねる。ゼロ以外ならServiceModeで、TargetNameとサービスパラメータを結び付ける。小さい値が優先される一方、同じ優先度のレコードはランダムに並べ替えられる。「HTTPS RRあり」だけでは、クライアントが利用可能だった候補も、選んだ対象も、その理由も残らない。

互換性にも境界がある。mandatoryは理解必須のキーを示す。一つでも未対応なら、そのクライアントは当該レコードを利用できない。alpnはアプリケーションプロトコルを広告し、no-default-alpnはURIスキームが通常含意する既定プロトコルを外せる。同じ正常なRRsetでも、ブラウザ、OS、ライブラリ、管理端末ポリシーによって利用可能な選択肢が変わる。

ipv4hintとipv6hintは過大評価されやすい。早い試行を可能にする。RFC 9460では、AまたはAAAAレコードがローカルにある場合はそちらを優先し、ない場合はTargetNameを照会して、以後の接続では得られたアドレスを使うことが推奨される。ヒントは経路の存在、UDPの通過、NATやファイアウォールの動作、宛先の待受けを証明しない。試行先の情報であって、パケット到達証明ではない。

TLSの認証境界も残る。SVCBによる別名化は、認証すべきオリジンを変えない。クライアントは元のサービス名に対して証明書を検証する。したがってDNS応答が正しく理解されても、広告された対象で証明書、SNI、TLSハンドシェイクが失敗し得る。

HTTP/3について、RFC 9114 はアプリケーションをQUIC上に置き、QUICは RFC 9000 が定義する。DNSの後にも、QUIC接続、TLS認証、HTTP/3設定、アプリケーション応答が続く。それぞれが独立して失敗する。「HTTP/3有効」という一つの表示に圧縮すると、障害箇所を示す証拠が失われる。

フォールバックは証拠欠落を見えにくくする。RFC 9460は、不正形式または非互換のレコードを拒み、SVCBを使わない接続へ戻る場合を定める。ユーザーの要求が成功しても、代替先は未試行または失敗済みかもしれない。可用性には有益だが、代替先の受入れ証明ではない。

一度の失敗を一般化することもできない。クライアントがALPNに未対応、特定リゾルバーの応答を観測、同優先度の別対象を選択、プロキシを利用、ローカルでUDPを遮断、古いDNS情報を保持、といった可能性がある。運用準備はクライアント群ごとの主張であり、一台から普遍化できない。

エンドポイントの運用準備検証記録は、サービス名、リゾルバー、ネットワーク、クライアント版、観測地点、時刻から始める。完全なHTTPS RRset、DNS検証結果、TTLとキャッシュ年齢、選択した優先度・対象・対応済みパラメータ、解決または提示されたアドレス、各レコードを採用・除外・拒否した理由を保持する。

次に実行を追う。試したアドレス、プロトコル、ポート、QUICまたはTCPの結果、交渉したALPN、証明書名と検証結果、HTTP状態、表現の指紋、フォールバックの有無である。最後にクライアント群、所要時間、終端結果、運用準備を承認できる責任主体を記録する。

こうすれば、「HTTPS RRを観測」はリゾルバーが返した事実、「代替先を選択」はServiceModeを採用した事実、「HTTP/3接続」はQUIC・TLS・HTTP/3が成立した事実、「サービス配信」は目的のアプリケーション処理が成功した事実として分けられる。同じ時系列に並べても、前者から後者を自動生成してはならない。

分離は診断にも効く。無視されたレコードは互換性と必須キー、解決後のQUIC失敗は経路と伝送ポリシー、TLS失敗はオリジンの認証情報と配備状態を調べる。フォールバックのみ成功なら、サービスは維持しつつ代替先の承認を保留する。

HTTPSレコードは、公開され観測されたサービス接続情報として有用である。運用準備が整ったと言えるのは、その接続情報に従った特定クライアントが、認証済みのアプリケーション結果を返してからだ。

情報源

RFC 9460 — SVCBとHTTPSリソースレコード; RFC 9114 — HTTP/3; RFC 9000 — QUIC.