テレビをSmart DNSリゾルバに向けると、一つのストリーミングアプリが動き出し、結論はひとりでに書かれます。これは安くて導入が速いVPNだ、と。そうではありませんし、その差は揚げ足取りではありません。変わったのは、テレビがホスト名はどこにあるのかと尋ねたときに受け取った答えです。変わっていないのは、すべてのパケットが今もそのままの形で家を出て、同じ経路を、ISPがすでに知っている同じアドレスから出ていくことです。神話は、DNS設定がトンネルだというものです。現実はもっと狭く、そして見ればわかる通りもっと役に立ちます。

神話:DNSを変えると通信の経路が変わる

通常のDNSはアプリにどこへ接続するかを伝えます。Smart DNSサービスは選ばれたホスト名に対して、プロバイダー自身のインフラに属するアドレスを返すので、アプリはサービスへ直接ではなくそこへ接続します。プロバイダーはその一つの流れを実際の宛先へ中継します。端末上のほかの何も動きません。

テレビやゲーム機でこの仕掛けがそもそも動くのはそのためです。クライアントも、インターフェースも、ルートテーブルの項目も、暗号化層もありません。端末はいつも通りに、名前を解決し、返ってきた先へ接続しているだけです。変えたのは答えであって、すべてのパケットの通り道ではありません。

この呼び名は無関係なDNSプロジェクトでも使われるので、名前から機能を推測せず、プロバイダー自身の文書を確認してください。標準のSmart DNSプロトコルはありません。ある製品の対応範囲は、別の製品について何も確かなことを語りません。

実際に振り向けられるもの、そうでないもの

端末ごとではなく流れごとに並べれば、その違いはすぐに見えます。

FlowSteered by Smart DNS?Why
A supported streaming hostnameYes, usuallyThe resolver returns a provider address for that name
The same app's other hostnamesOnly if the provider lists themSteering is per-name, and lists are curated
Your browser, email, game downloadsNoTheir names resolve to the ordinary destination
Traffic from devices not using that resolverNoNothing forces a device onto a particular resolver
Payload encryptionNoUnrelated to name resolution

実際に確かめられます。プロバイダーのリゾルバにホスト名を問い合わせ、同じ名前を公開リゾルバに問い合わせてください:

dig +short @<provider-resolver> example-stream.example
dig +short @1.1.1.1 example-stream.example

答えが違えば名前の層で振り向けられている証拠です。同じ答えなら、そのサービスがその名前を対象にしていないか、端末がそのリゾルバを使っていないかのどちらかです。DNSの設定ミスに見え、よく壊れたアカウントと誤解される失敗です。

二つ目の失敗にも同じ匂いがあります。多くのプロバイダーは今使っている公開アドレスで認可するので、アカウントはアドレスが変わるまで機能します。キャリアグレードNATの回転や、その上に重ねたVPNはそのアドレスを動かし、名前解決は成功し続けるのにリレーはあなたを拒否します。登録簿の項目はアクセス制御であって、独占的な出口の証明ではありません。

暗号化DNSはまったく別の第三のものです

HTTPS上のDNSとTLS上のDNSは、端末とリゾルバの間のやり取りを守ります。問い合わせを暗号化して認証するので、ローカルネットワークはそれを読んだり書き換えたりできません。DoHはそれをポート443の通常のHTTPS通信に載せて運ぶので、フィルターにはウェブ通信のように見えます。これは問い合わせの機密性の機能です。

サービスを振り向けるのは別の機能です。答えそのものが仲介者を指します。一つの製品が両方を同時に提供することはあり、多くがそうしていますが、一方が他方を意味するわけではありません。問い合わせを暗号化しても、動画の一バイトも他国を通ったことはありません。

つまり「暗号化DNS」は、誰があなたの問い合わせを読めるかという問いに答えます。誰があなたの通信を見られるかには答えず、新しい出口アドレスも与えません。DNS over HTTPSの仕様が、その保護が何を覆うのかについての正しい参照であり、ルーティングについては何も述べていません。

それぞれの構成で誰が何を見るか

Smart DNSでは、リゾルバはあなたが引く名前を見て、プロバイダーのリレーはそれが運ぶ接続を見て、ISPはそれ以外のすべてを、どのアドレスにいつどれだけ接続したかという開かれたテキスト構造として今も見ています。振り向けられた流れでは内容は宛先までTLSで守られるので、リレーは読めない暗号化セッションを転送しますが、あなたが接続したこと、どこから、どれだけの時間かは見えます。

VPNでは、トンネル事業者があなたの通信と宛先を見ます。これは一つの集中した信頼の判断です。ISPは一つの端点への暗号化された流れだけを見ます。露出は異なり、自動的に少ないわけではありません。どちらのモデルも、一つのサイトが開くかどうかで評価すべきではありません。

速度はラベルではなく経路に従います。選択的なリレーは無関係な通信を回り道に載せずに済ませられ、そうでなければすべてをトンネルに入れる端末にとって実際の利点です。それは保証でもなく、どの構成も、積極的に検知しようとするサービスへの恒久的なアクセスを約束しません。

Smart DNSが正しい道具となるのは

端末がVPNクライアントをまったく動かせないとき、つまりテレビ、ゲーム機、ネットワークスタックが固定されたセットトップボックスのとき、そして名前のある一つのサービスだけが重要なときに、本当に正しい道具です。その端末のすべてのパケットをトンネルに入れたくないと意図する場合にも妥当です。

要件が暗号化、端末全体の出口アドレス、またはローカルネットワークとISPからの保護であるときは、間違った道具です。それらはトンネルの性質であり、どのリゾルバ設定も生み出しません。そして同じ端末でVPNを動かし続けるなら、登録に基づく認可が壊れると予想してください。あなたの公開アドレスは今やトンネルのものだからです。

この判断を順にたどり、最初に当てはまる行で止めてください:

  • 通信を暗号化し、端末全体を新しい出口に置く必要がありますか。VPNを使い、接続表示ではなくルートと除外を確認してください。
  • トンネルできない端末で、名前のあるいくつかのサービスだけが必要ですか。Smart DNSは釣り合っています。
  • 問い合わせを非公開にしたいが、通信は動かしたくないのですか。それは暗号化DNSで、上のどちらでもありません。
  • プロバイダーが現在のアドレスに依存していますか。それが変わる瞬間に破綻すると考えてください。

関連記事