VPN と併用する TLS 上の DNS：どこが保護されるのか

TLS 上の DNS は、クライアントとそのクライアントが選んだリゾルバーの間のやり取りを暗号化するが、リゾルバーは依然として名前を読む。この一文で、DoT と VPN の組み合わせに関する混乱の大部分は解ける。暗号化された問い合わせがどの経路を通るかはトンネルが決め、リゾルバーは何が問い合わされたかを依然として知る。どちらの仕組みも他方を代替せず、どちらも他方を不要にしない。

四つの検査によって、手元にある構成が思い込んでいる構成と同じかどうかが決まる。

検査 1：暗号化が覆う範囲

DoT は DNS のやり取りを TLS で包むので、経路上の観測者は問い合わせの中の名前ではなく、アドレスとポートへの接続を見る。リゾルバー自身が復号して応答する。HTTPS 上の DNS と比べてみるとよい。どちらも暗号化するが、使うトランスポートが異なるため、ウェブのトラフィックを許可するネットワークが DoT 接続を自動的に許可するわけではない。

この違いは、キャプティブポータルやフィルタリングする中間装置が 443 を許可し 853 を遮断しているときに効いてくる。そこで動いた道具は、もう一方が動く証拠にはならない。

検査 2：問い合わせが通る経路

経路はクライアントのポリシーの問題である。DoT リゾルバーにはトンネルの中からも、外からも、ネットワークに応じて変わる経路からも到達できる。どれになるかは経路と、クライアントが自身の DNS ソケットを保護しているかどうかで決まる。すべてのトラフィックを取り込むトンネルは、リゾルバーのアドレスが何と言おうと、通常は問い合わせも一緒に運ぶ。

テストで第三者のリゾルバーのアドレスが見えたからといって 迂回の証拠にはならず、暗号化が見えたからといって意図した受け手だという証拠にもならない。リゾルバーと経路を別々に読み、その組み合わせが設計どおりかを判断する。

検査 3：内部名

内部名を公開している組織には、そのレコードを保持するリゾルバーが必要である。公開 DoT サービスはあなたの非公開名前空間を知らず、クライアントをそちらに向けるとそれらの名前は確実に失敗する。管理された端末で誰かが暗号化 DNS を有効にしたときの、最もよくある実務上の後退がこれである。

内部サフィックスには内部リゾルバーを残し、ポリシーが求めるならその区間を暗号化する。公開プロバイダーに置き換えるのではなく。

検査 4：失敗時の挙動

到達可能なリゾルバーのない厳格なリゾルバー設定では、トンネルが上がったまま名前解決の失敗が起きる。鍵や証明書に触るのではなく、プラットフォームのモードとその文書化されたフォールバックを見る。

平文 DNS を黙って使うフォールバックは、便宜ではなくポリシーの決定である。失敗を見えるようにするのか、より弱い何かに落とすのかを決め、その答えを書き留める。

証明書を信じ、応答を信じない

サービスについて文書化されたプロバイダーのホスト名と検証設定を使う。見慣れないリゾルバーが応答するように TLS 検証を切ると、検証されていない端点への暗号化された経路が手に入る。これは置き換えた平文の問い合わせより、ある一点で悪い。安全に見えるのだ。DNS over TLS の仕様は、その検証の背後にある認証の期待を述べている。

認証できないリゾルバーからの応答は、結果ではなく主張である。

これで説明できないこと

DoT はリゾルバーから名前を隠さず、接続先のアドレスをネットワークから隠さず、問い合わせがトンネルを通ったかどうかも決めない。これらは三つの別々の問いであり、三つの別々の答えがある。

リゾルバーの同一性、通過経路、内部名のポリシーを三行で書き留める。次に受ける DNS の問いは、そのどれかになる。