DNS over TLS

OSのスタブリゾルバーから再帰リゾルバーへDNS専用TLS接続を作り、複数メッセージを再利用して往復する通常のWeb用HTTPS接続とは別のトランスポートとして運ぶ

接続確立から再利用まで

1. Connectスタブリゾルバーが設定済み再帰リゾルバーのDoTエンドポイントへTCP接続する。
2. HandshakeTLSバージョンと暗号スイートを合意し、リゾルバー証明書を設定名や事前に指定した公開鍵情報などで検証する。
3. FrameTCP上でメッセージ境界が分かるよう、二オクテットの長さフィールドをDNSメッセージの前へ付ける。
4. Exchange問い合わせを複数送信し、IDと内容から応答を対応させる。順序どおりとは限らない。
5. Reuse接続を再利用し、TLSハンドシェイクとTCPのスロースタートによるオーバーヘッドを減らす。
6. Reconnectアイドル時の切断、ネットワーク切替、エラーの後に再接続し、未完了の問い合わせを安全に扱う。

TLSサーバー認証を省くとアクティブ攻撃に弱い

暗号化だけして相手名を確かめないopportunistic privacy（オポチュニスティック・プライバシー／日和見型プライバシー）では、受動的な盗聴は減っても偽リゾルバーへの誘導を防ぎにくくなります。厳格な認証プロファイルでは、事前設定した名前や公開鍵情報を検証します。

利用者がリゾルバーアドレスを手入力する場合も、証明書検証に使う認証ドメイン名を対応させます。IPアドレスへ接続しただけで正しいサービスとは断定しません。

長い接続は性能と相関のトレードオフ

複数の問い合わせで一つのTCP・TLS接続を再利用すれば、ハンドシェイク回数を減らせます。問い合わせのパイプライン化と順不同の応答により、前の応答だけを待ち続ける時間を抑えます。

一方、同じ接続へ多くの問い合わせをまとめるほどリゾルバーは一連の行動を結び付けやすくなります。パディングや接続管理はトラフィック分析を完全には消しません。

DoHとの違いは専用通信路かHTTP利用か

DoHはHTTPS URI、HTTP意味、キャッシュ、多重化を使い、通常Webトラフィックと同じポートを通りやすい方式です。DoTはDNS専用ポートとプロトコルとしてネットワーク側が識別・方針制御しやすい反面、ブロックもしやすくなります。

どちらもクライアントから再帰リゾルバーまでのプライバシーを扱い、リゾルバー自体を信頼点として残します。アプリケーション独自DoHとOS全体DoTが同時に使われる場合もあります。

平文への切り替えと内部DNSを設計する

DoT失敗時にポート53へ戻すか、名前解決を止めるかでセキュリティと可用性が変わります。企業内部ゾーン、キャプティブポータル、ペアレンタル制御を必要とするネットワークではリゾルバー選択を管理します。

DoTの確認では「TLS接続済み」だけでなく、認証したリゾルバー名、代替処理条件、IPv4・IPv6経路、問い合わせログ、接続再利用の範囲まで見ます。

DoT connection、message framing、認証profileの確認資料：RFC 7858「Specification for DNS over Transport Layer Security」、RFC 8310「Usage Profiles for DNS over TLS and DNS over DTLS」