VPNなしの暗号化DNSが隠すのは問い合わせであり、あなたのアドレスではない

自宅のネットワークが表示されるDNS漏えいテストは、暗号化DNSが失敗した証拠でも、何かがうまくいった証拠でもない。このテストが答えるのは一つだけだ。この問い合わせがこのネットワークからどのリゾルバーに届いたのか。それが問題かどうかは、何から誰を守ろうとしていたかで決まる。

テストを実行する前に目的を書き出す。

ステップ 1：本当に求める保護を言葉にする

三つの目的が混ざっている。経路上の観測者に問い合わせを読ませたくないのかもしれない。特定のリゾルバーに受け取らせたくないのかもしれない。訪問するウェブサイトに自宅のアドレスを見せたくないのかもしれない。暗号化DNSは一つ目に効き、二つ目を誰が満たすかを変え、三つ目には何もしない。

VPNは三つ目に効き、事業者によっては一つ目にも効く。どちらの道具も他方の上位集合ではない。

ステップ 2：リゾルバーを選び、その身元を検証する

DNS over TLSはリゾルバーとのTLSセッションで問い合わせを包み、DNS over HTTPSはHTTPリクエストで包む。RFC 7858とRFC 8484が両方を記述しており、どちらもトンネルを必要としない。運用上重要なのは、証明書が設定した名前に対して検証されることだ。間違った相手との暗号化セッションは、正しい相手との平文より悪い。つまり、プラットフォームが提供するなら厳格モードを使い、検証に失敗すると後退する機会主導モードは使わない。設定を信じる前にセッションを直接確認する：openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief。

ハンドシェイクは設定したリゾルバーを示し、検証できる証明書チェーンを返すべきだ。

ステップ 3：失敗時の挙動を決める

どの実装にも到達不能な暗号化リゾルバーに対する方針があり、その方針こそがプライバシーの判断だ。厳格モードは検索を失敗させ、これは目に見えて煩わしい。機会主導モードは平文で再試行し、これは見えず、重要なその日に目的を台無しにする。意図的に選び、選択を要件の隣に記録する。

systemd-resolvedではDNSOverTLS=yesを使いopportunisticは使いません；Androidでは自動ではなくPrivate DNSのホスト名モードを意味する。

実際に何が有効かは次のコマンドで確認する：resolvectl status | grep -i -A1 "dns over tls"。再読み込みされていないdrop-inファイルは何も変えないからだ。

ステップ 4：アプリがシステムのリゾルバーに従うか確認する

独自の安全なDNS設定を持つブラウザーはシステム構成を完全に迂回し、組み込みリゾルバーを持つコンテナランタイムやハードコードされたリストを読む言語ランタイムも同様だ。システムに従わせるか、明示的に設定して記録する。そのうえで各々のフォールバック挙動を見る。すべてが閉じた失敗をするわけではない。実際の一覧は短い。ブラウザー、コンテナランタイム、そして併用しているVPNクライアントだ。

組織の内部名は承認済みの内部リゾルバーに留める。テストを整った見た目にするために公開サービスへ送るのは、意図的に別の問題を作ることだ。

ステップ 5：要件に照らして漏えいテストを読む

予期しないリゾルバーを報告するテストは手がかりであり、判決ではない。意図した暗号化リゾルバー、アプリ固有の設定、あるいは知らなかった平文へのフォールバックを観測したのかもしれない。報告されたリゾルバーをステップ 2 で設定したものと比べ、結果をステップ 1 の目的と比べる。

目的が問い合わせをローカルネットワークから遠ざけることなら、通常のリゾルバーを示すテストは実際の所見だ。目的が閲覧時の匿名性なら、どのDNS設定もそれを与えなかっただろう。

受け入れ条件は目的の言葉で書く。これらの検索はこの条件でこの検証済みリゾルバーを使う。それより広い主張は検証できない。