DNS 経由の VPN は VPN の DNS サーバーとは違う

DNS 経由の VPN はトランスポートの考え方を表すものであり、端末を独自のリゾルバーに向けることの同義語ではありません。混乱を解く問いは単純で、DNS メッセージが実際に何を運んでいるのかということです。通常の VPN は、対象のアプリがプライベート名を解決できるようリゾルバーを設定することがあり、そのリゾルバーを変えても変わるのは名前解決だけです。三つの構成は用語を共有するだけで、それ以外はほとんど共通していないため、以下の確認を順番に行ってください。

三つの構成を切り分ける

一つ目の構成では、VPN がリゾルバーまたは名前ポリシーの設定を提供します。アプリのデータは引き続き自身のネットワーク接続を通り、トンネルはどのサーバーが問い合わせに答えるかに影響するだけです。

二つ目では、暗号化 DNS が DNS のやり取りそのものを保護します。DNS over HTTPS と DNS over TLS は選択したリゾルバーへの問い合わせを包み、他のアプリのパケットは運びません。また、選んだリゾルバーから問い合わせ名を隠すこともなく、これはローカルネットワークから隠すこととは別の信頼境界です。

三つ目では、協調するクライアントが他のデータを DNS メッセージに符号化し、協調するエンドポイントがそれを再構成します。通常のリゾルバーの経路がトランスポートになり、リゾルバーは名前サービスではなくデータ経路の一部になります。

DNS メッセージが何を運ぶかを確認する

リゾルバーを変えて、アプリの通信経路が変わるか観察します。アプリが同じソケットで同じアドレスに接続したままなら、変わったのは名前解決だけです。

DNS で運ばれるトンネルには、サーバー側の対応する構成が必要です。Iodine は文書化された例で、その プロジェクトのドキュメントは DNS を通る IP トンネルを説明しており、符号化を理解するサーバー側コンポーネントを必要とします。Android で公開リゾルバーのアドレスを入力してもそのエンドポイントは得られず、二つの製品が共有するマーケティング用語はプロトコル仕様ではありません。

パケットキャプチャが決定的な確認です。リゾルバーへの通常の問い合わせしか見えなければ、トンネルはありません。問い合わせ名と応答に符号化されたペイロードが見えれば、搬送路を見つけたことになり、次の問いはどれだけ動かせるかです。

コミットする前に容量を確認する

DNS は問い合わせと応答のために設計されており、大量配信向けではありません。符号化のオーバーヘッド、メッセージサイズの制限、リゾルバーの挙動がすべて公称経路の一部を占めるため、実効容量は下位のリンクが示すより小さくなります。自分の経路で測っていないスループットの数値は、予算ではなく仮説として扱ってください。要求応答型の搬送路では上りと下りが異なる制限に当たるため、両方向を測ってください。

どのトラフィックをトンネルに入れるかもクライアントが決める必要があります。ローカルの VPN サービスインターフェースはパケットを集められますが、そのインターフェースは遠隔のトランスポートがパケットをどう保護し転送するかについては何も語りません。搬送路がストリームではなく要求応答プロトコルの場合、フラグメンテーションと再送の挙動は異なり、開いたままの接続は対話的な遅延についてほとんど何も示しません。

運ぶつもりのトラフィックで測ってください。定期的心拍には問題なく見えるトンネルが、対話的なセッションには使えないことがあり、逆もまた真です。

搬送路の安全性を確認する

DNS のカプセル化が機密性や強い認証を提供すると仮定しないでください。リゾルバーの経路とトンネルのエンドポイントは実装が露出するものを見ることができ、その露出は設計によって異なります。

暗号化と搬送路の選択は別々の性質です。トンネルは素の IP 経路の上で暗号化でき、DNS で運ばれるトンネルはペイロードの保護があってもなくても構築できます。いずれにせよアプリの HTTPS はそのままにし、トンネルの名前ではなく実際のセキュリティ設計を評価してください。

要件がローカルネットワークからのプライバシーなら、暗号化 DNS とデータトンネルはその異なる部分に応えます。どちらかを選ぶ前に、どの観察者に対して守るのかを書き留めてください。

修正を実際の障害に合わせる

通常の遅い VPN では、DNS で運ばれるトンネルに置き換えると問題の上に制約されたトランスポートを追加することになります。無線品質、輻輳、サーバー負荷を修復するものではなく、通常はそれらをより目立たせます。

プライベート名の障害では、まず意図したリゾルバーポリシー（どのサーバーが答えるべきか、どの名前が対象範囲か、クライアントに使用が許可されているか）を確認してください。そのうえで要件に合う承認済みのトランスポートを選び、次の障害で同じ調査をやり直さないようリゾルバー設定を変更記録に残してください。

チェックリストは短く、構成を特定し、メッセージが何を運ぶかを確認し、容量を測り、そのうえで信頼を見直します。症状と合わない手順があれば、他の二つの構成がまだ関与しています。