要約

  • RFC 9539 は Experimental RFC であり、再帰リゾルバーと権威サーバーがそれぞれ任意に 853 番ポートの DoT/DoQ を試す。目的は受動監視の低減であって、新しい認証制度の創設ではない。
  • この方式では、クライアントは身元を検証できない証明書も受け入れ、暗号経路が失敗すれば Do53 へ戻り得る。能動的な降格や中間者を防がず、DNSSEC の代わりにもならない。
  • 証拠はサーバー IP の能力履歴と、個々の問い合わせが実際に通った経路を分ける必要がある。競合の勝者、証明書判定、SNI、各タイマー、失敗理由、平文送信の有無を保存する。

緑になった時には遅かった

説明用の一回目の問い合わせを考える。再帰リゾルバーは権威 IP アドレス X に関する暗号経路の履歴を持っていない。解決を遅らせずに能力も調べるため、53 番ポートへ通常の DNS を送り、ほぼ同時に 853 番ポートで DoT または DoQ の接続を始める。

平文の応答が先に届く。未処理の質問に対応した正しい形式なので、リゾルバーはその内容を処理し、暗号経路上の同じ質問を「処理済み」とする。その数ミリ秒後に暗号ハンドシェイクが完了する。リゾルバーは X の能力を成功として記録し、RFC 9539 が例示する三日間の persistence 内では、後続の問い合わせを暗号経路だけへ送れる。

ここには矛盾がない。協調なしで導入し、利用不能な相手のために通常の DNS を壊さないことが実験の狙いだからだ。ただし、記録は三つに分かれる。名前解決は成功した。目的 IP は暗号接続に対応していた。最初の質問は平文で観測可能だった。監視画面が最後の接続状態だけを見て「暗号化済み」と表示すれば、第三の事実が消える。

証明書はさらに別の帳簿である。このプロファイルでは、クライアントは提示された証明書を受け入れなければならない。身元検証の失敗は分析用に残せるが、それを理由に接続を拒否して平文へ戻ってはならない。したがって受動監視には秘匿されても、能動的な中間者には対抗できない。accepted certificate は authenticated identity ではない。

認証基盤ではなく、限定された実験

RFC 9539 は 2024 年 2 月に Experimental として公開された。「暗号化 DNS」で保護されやすい stub-to-recursive の次に残る、recursive-to-authoritative の区間を扱う。RFC 7858 の DoT と RFC 9250 の DoQ を、この区間で一方的に試す運用状態機械である。

権威側は DoT、DoQ、または両方を 853 番ポートで提供できる。再帰側は通常の委任解決で得た IP を探査できる。ゾーンを登録する新制度も、許可レコードも、全員同時の移行日も必要ない。

この性質は RFC 7435 の Opportunistic Security と一致する。相手を認証できないからといって、すべてを平文のままにする必要はない。Heng Lu の Localized Future Decision と Voluntary Adoption の観点でも、共通仕様は相互運用の条件を示し、現実の変更は実装と運用者の採用によって生じる。RFC の発行だけではトラフィックは暗号化されない。

同時に、権限の範囲は狭い。RFC 9539 は権威サーバーの身元を認証せず、DNS 委任を書き換えず、853 番で応答した機械に新しい正統性を与えない。能動攻撃者は平文へ降格させたり、中間に入ったりできる。DNSSEC が担当する DNS データの認証とも別である。

状態は名前ではなく経路に属する

RFC 9539 は暗号対応の履歴をゾーン名や NS 名ではなく、権威サーバーの IP アドレスに結び付けるよう勧める。一つの NS 名が複数アドレスを持ち、同じアドレスが load balancer や anycast の背後に多くの実体を隠すからである。ある実体の成功を NS 名全体へ広げれば、次は 53 番しか持たない実体へ接続して余計な timeout を生む。

経路の鍵はさらに resolver source IP × authoritative destination IP × transport まで細かくなる。load balancer が client IP で backend を固定する場合、送信元が違えば到達先も違う。anycast でも経路変化によりサイトが変わる。「このサーバーは DoQ 対応」という表現より、「この送信元は、この時刻に、この IP へ、この transport で成功した」という記録が必要だ。

仕様の状態フィールドには、開始時刻、完了時刻、success/fail/timeout、最後の応答、resumption 情報、各 session に属する pending query が含まれる。再起動後、live session や query queue を残してはならないが、最近の能力履歴は保持できる。この区別により、古い socket を生きているように扱わず、経験だけを再利用できる。

三日の persistence、一日の damping、四秒の handshake timeout は推奨初期値であり、普遍的な最適値ではない。大規模リゾルバー、衛星回線、小規模権威、段階的に更新する anycast は別の判断をし得る。値は公開すべき運用事実である。一回の成功が平文を何日抑え、一回の失敗が暗号の再試行を何日止めるかを、その値が決めるからだ。

failure、clean close、query timeout

暗号ハンドシェイクが失敗すると、リゾルバーは session を消し、status を fail とし、他経路で覆われない質問を Do53 へ移す。damping が過ぎるまで同じ IP の暗号探査を控える。接続後のプロトコル障害も同様である。

一方、権威サーバーが資源管理のため正常に接続を閉じた場合は違う。未回答の質問には代替経路が要るが、clean close は「一日間この IP が非対応」という判断ではない。次の問い合わせで暗号接続をすぐ試せる。個別 query の timeout も session 全体の failure ではなく、別の transport、別の権威 IP、同じ session の別 query が生きている可能性がある。

これらを一つの encrypted=false にすると監査不能になる。TLS alert は互換性問題かもしれない。無応答の 853 は未実装、filter、rate limit のどれでもあり得る。clean close は適切な負荷制御かもしれない。DNS の SERVFAIL は application response であって transport failure ではない。能動攻撃者は一部の故障を作り、平文への移行を誘える。理由、発生時刻、対象 query、再試行可能時刻を結び付けなければならない。

この実験は availability を優先する。権威サーバーが暗号接続を偶然提供しただけでは、将来も維持するという認証済みの約束にはならない。fail closed の将来方式には、downgrade-resistant signal、server authentication、zone または NS などの scope が要る。それなしに 853 の停止を全面障害へ変えれば、任意の改善が新たな停止権限になる。

暗号化、相手の身元、DNS データ

第一の問いは transport が暗号化されたかである。成功した TLS/QUIC session は、その上を通った bytes にだけ答える。第二は相手が意図した権威サーバーかである。RFC 9539 は任意証明書を受け入れるため答えない。第三は DNS answer が真正かである。DNSSEC は有効な chain と signed data があるとき、Do53、DoT、DoQ の別に関係なく判定する。

平文でも DNSSEC-valid なら data authenticity はあり得るが confidentiality はない。暗号化しても証明書未検証で DNSSEC chain もなければ、受動監視への confidentiality はあっても peer identity と data origin は証明されない。両方を単に secure DNS と呼んではならない。

SNI は別の漏えいを生む。同じ IP に複数の NS 名が向く場合、clear ClientHello の SNI がどの zone 関係を調べているか示し得る。この unilateral profile では SNI を送らないことが推奨される。必要なら ECH が軽減するが、IP、timing、size を消さず、証明書を認証済みにもしない。

RFC 7830 の EDNS padding と RFC 8467 の policy はサイズ分析を弱める。RFC 9156 の QNAME minimisation は各権威へ見せる名前を減らす。暗号、最小化、padding は別々の漏えい面を扱い、相互に代用できない。

一つの IP にいる複数実体

権威実装は encrypted と unencrypted の両 transport で同じ zone data を使わなければならない。transport の違いで response size、EDNS、TC bit が変わることはあるが、DNS の内容そのものを別管理してはならない。

しかし同じ IP の背後で rollout が割れることはある。load balancer が DoT 対応 backend と未対応 backend を交互に選び、anycast のサイトごとに更新時刻が違えば、再帰側には success と timeout が揺れて見える。RFC は短時間で pool 全体を有効化する、client IP で安定 mapping する、または対応済み backend だけへ暗号接続を送る案を示す。

これは fleet の一致を保証する文章ではなく、測るべき義務である。source cohort、anycast site、時刻ごとに比較し、handshake 後に DNS response がない事象も数える。encrypted と Do53 で同じ zone generation が返ることも確認する。一回の成功は一経路の証拠にすぎない。

証拠行は query から始める

保存項目は query ID、QNAME、QTYPE、QCLASS、生成時刻から始まる。resolver source、authoritative destination、NS/zone context、vantage を続け、試した transport、port、ALPN、開始と完了を並べる。

どの outstanding queue が query を持ち、どの response を処理したかを残す。暗号側には certificate fingerprint、certificate form、identity verification、SNI/ECH、session/resumption、early data、failure class が要る。policy 側は persistence、damping、timeout。DNS 側は raw response または hash、RCODE、flags、DNSSEC result、他 transport との比較である。

結果として、その query が Do53 を通ったか、fallback 時刻、次回 probe 時刻、pool/anycast cohort、再検討 trigger を保存する。全体指標は一度でも handshake した IP 数ではなく、実際に各 transport で処理された query の割合で出す。

privacy の価値は listener の設定数ではなく、守られた質問数にある。

参照資料