要約

  • ECHではHTTPS/SVCBレコードが稼働中の暗号設定になる。公開鍵は、接続先エッジが対応する秘密鍵を持つ場合にだけ有効である。
  • 「ECH有効」ではなく、DNS初回公開から全エッジ準備完了までの不一致時間を、accept・reject・retry・安全な無効化・失敗で測るべきだ。
  • retry設定は限定的な修復手段であり、原子的な配備証明ではない。継続的なretryはDNS版、エッジ群、バックエンドの不一致を示す。
  • DNSとエッジを統合した事業者は鍵管理、重複、観測を共通化できる。複数事業者では移植可能な版管理証跡が必要になる。

DNSが接続前の暗号状態を配る

RFC 9849は、真のサーバー名や機微な選好を持つClientHelloInnerと、経路から見えるClientHelloOuterを分ける。Outerは暗号化したInnerを運び、フロントサーバーはクライアントが取得したECHConfigに対応する秘密鍵で復号する。

RFC 9848はDNS Service Bindingのechパラメーターを定め、RFC 9460はSVCB/HTTPSレコードを接続命令の束として定義する。DNSは行き先だけでなく、最初のTLSメッセージをどう作るかまで配る。

配備順序には費用がある。全エッジを先に準備すれば新旧鍵の重複期間が必要になる。DNSを先に出せば、未準備の終端にクライアントが到達する窓が生まれる。証明書も通常HTTPSも正常なまま、最初のECHだけが失敗し得る。

一つの試行に四つの状態

ブラウザーはECHを試すか決める。Chrome Enterpriseのポリシーは、サーバー対応、HTTPS DNSレコード、rollout状態にも左右されると説明する。FirefoxのFAQはFirefox 119以降の既定有効化と、企業・ペアレンタル制御・信頼された中間装置による無効化を記す。

リゾルバーはブラウザーが何を知るか決める。RFC 9460はSVCB解決の抑止で安全上の利益も失われ得るとする。Cloudflareの運用文書はHTTPS応答の抑止やcanaryドメインをローカル制御として示し、HTTPSレコードの書換えがDNSSEC検証と衝突し得ると警告する。

権威DNSは版、TTL、aliasを制御し、エッジは各群の秘密鍵を制御する。必要な証跡はECHConfigListのhash、config_id、DNS初見、TTL、群別ready時刻、accept、retry、古いcacheの尾を一つの版に結び付ける。

retry成功は初回の不一致を消さない

サーバーは古い設定を持つクライアントへretry設定を返せる。重要な復旧機能だが、二回目の成功が一回目を原子的に変えるわけではない。追加接続と遅延で不一致を修復した事実が残る。

RFC 9849は、retry設定から始めた接続に対してさらにretry設定を受け入れないよう勧める。複数の不整合なサーバー設定も想定される原因として挙げる。訂正が次の訂正を要求するなら、どの版が権威かを在庫が答えられていない。

retryは設定版、リゾルバー、クライアント、エッジ群別に測る。計画された切替の短い尾と、一拠点で続く集中は別物である。全体平均は不良群を小数点以下に埋めるための優秀な土木機械だ。

匿名集合にも運用上の一貫性が要る

ECHのプライバシー目標はSNI暗号化だけではない。同じ匿名集合のサービスが外から似て見える必要がある。HelloRetryRequest cookie、鍵名、拡張順、エラーの差は条件によってバックエンドを識別し得る。標準が記述するのはそのリスク機構であり、この証拠包は特定のproduction配備で匿名集合が縮小した測定結果を含まない。

RFC 9849はsplit modeでの差異を扱う。RFC 9934は秘密鍵と対応するECHConfigListを格納するPEM形式を標準化する。形式の互換性は配布の完了ではない。制御装置にある正しいファイルは、終端がacceptを示すまで計画にすぎない。

RFC 9180のHPKEは暗号カプセルを保護する。暗号が正しくても、最後のエッジがまだ知らない鍵に正しく暗号化することはできる。

統合された運用境界の価格

DNSとエッジを持つ事業者は、鍵のstage、全体ready確認、公開、重複、retry観測、旧鍵廃止を一つの境界で行える。CloudflareはFree zoneでECHを既定有効とし、他planで設定可能としている。普遍的な成功率ではないが、協調が製品機能になる例である。

複数CDNでは共通ECH設定、複数service binding、経路ごとの異なる能力のいずれかを選ぶ。鍵保管、TTL、cache、緊急rollback、ready証明は契約項目になる。標準は表現を定めるが、変更会議には出席しない。

証拠が一社の内部グラフにしかなければlock-inが生じる。移行には鍵だけでなく、どの場所がいつreadyだったかという信頼履歴の再構築が必要だ。外部hash、時刻、群、acceptの証跡が出口を作る。

この協調premiumとlock-inの結論は、分割されたcontrol surfaceから導いた分析上の推論であり、観測済みの市場状態ではない。domain ownerは重複計画とportability、DNS providerは公開・TTL・cache証拠、edge providerはsecret配布・fleet telemetry・rollback、enterpriseはresolver policy testとsupport、end userはfirst-attempt failureとretry latencyを負担する。契約は金銭と労働を移せるが、費用そのものは消せない。

反証できる運用基準

各rotationで設定hash、DNS観測、TTL、対象edge、active時刻、初回accept、retry、遅延、安全な無効化、失敗、rollback完了を残す。

新設定が対象edgeの99.999%以上で復号可能になった後にだけDNSへ出現し、不一致が0.01%未満、retryのp99が25ミリ秒未満、古い設定がTTL+30秒以内に消え、共通の専用オーケストレーションなしの複数事業者切替でも同じ結果なら、協調制約の仮説は弱まる。初回の1%以上がretryし、二TTLを超える不一致群があるか、300秒でrollbackできなければ強まる。

これは将来の反証条件で、観測済み市場統計ではない。未知を精密に見せないための境界である。