スマホの Private DNS が VPN の名前解決を壊す理由

トンネルは接続されたままで他の指標も正常に見えるのに、アプリが名前を解決できない。スマホでは、VPN プロファイルではなく端末が選んだリゾルバーが原因であることが多い。二つの設定が同じ問い合わせの主導権をそれぞれ主張できる。どちらが勝つのか、そもそもその問いに答えられるのかを突き止めるほうが、トンネルに触るより速い。

二つの設定が同じ名前を決める

スマホの Private DNS 設定は端末用のリゾルバーを選び、自動選択から指定ホスト名までのモードがある。VPN プロファイルも同時に独自のリゾルバーを押し込め、両者は別の画面で、別の管理者によって構成される。どちらもすべてのアプリで必ず他方を上書きするわけではない。だからこそ動くトンネルと失敗する問い合わせが矛盾なく共存する。

ブラウザー内の安全な DNS が独自のプロバイダーを選ぶことがあるため、ブラウザーは第三の層を加えられる。エラーを出したアプリだけが、三つのうちどれが答えたかを示す信頼できる手がかりになる。リゾルバー側も答えられなければならない。社内だけの名前は公開リゾルバーのデータにないため、問い合わせは接続ではなく内容で失敗する。

必要な名前でモードを選ぶ

端末が社内名を解決する必要があるなら、リゾルバーはそのゾーンを持つもの、つまり通常はトンネルのリゾルバーか、組織が文書化した分割 DNS の構成でなければならない。公開名だけが重要なら、厳格な暗号化リゾルバーは平文の問い合わせも排除する妥当な選択だ。判断は名前から導かれ、暗号化への好みからではない。

失敗時の挙動もモードによって変わる。リゾルバーに到達できない厳格な選択はすべての名前で失敗を生むが、許可されたフォールバックのあるモードなら公開名は動かし、社内名だけを壊しておける。その違いは、設定画面を開く前に自分がどのモードかを教えてくれる。管理された端末では承認済みポリシーが決め、利用者は安全にそれを回避できない。個人の構成なら、文書化した比較を一度すれば衝突を特定でき、意図したプライバシー設定は、無効のままにせず後で元に戻すべきだ。

どのアプリが問い合わせているか確認する

報告したアプリで失敗を再現し、そのエラーが名前のエラーか接続のエラーかを記録する。あるアプリで名前のエラーが出て別のアプリでページが開くなら、壊れたトンネルではなく二つのリゾルバーの証拠だ。

adb shell settings get global private_dns_mode
adb shell settings get global private_dns_specifier
adb shell dumpsys connectivity | grep -i -m 5 dns

これらのコマンドは端末の現在の構成を読むもので、メーカーのビルドでは基になる値の名前が変わったり制限されたりするため、出力は仕様ではなく手がかりとして扱う。Android の Private DNS のドキュメントには、モードと端末が期待するホスト名の形式が書かれている。

その答えを、VPN プロファイルが押し込むリゾルバーと比べる。食い違うなら衝突を見つけたことになり、残る問いは組織がどちらを勝たせたいかだ。

比較を一度したら意図した設定に戻す

設定を一つ変え、二つの名前を再テストし、設定を元に戻す。許可的なモードのまま放置された端末は社内名を解決しつつ、公開の問い合わせをすべて最初に答えた相手へ静かに送り、これは誰も記録していないプライバシーの変更だ。

結果は規則として書く、つまり社内名はこのリゾルバー、公開名はあちらで解決し、ブラウザーは端末に従うか従わない。リゾルバーを名指しする規則は検証できるが、VPN を直したというメモは検証できない。次に、端末のほかの何かが変更したリゾルバーに依存していないか確認する。更新確認、キャプティブポータルの検出、メールクライアントはそれぞれ独自の要求を出し、利用者が無関係な問題として報告する形で失敗する。