iPhone の WireGuard DNS：ドメインは検索サフィックスにすぎない

リゾルバのアドレスと会社のドメインを 一行に書けば、そのドメイン内の名前だけがトンネルのリゾルバを使うと期待します。Apple のクライアントでは、いまやすべての名前がそこへ送られ、ドメイン内の短い名前も解決されます。この行は 二つの別のことを行い、そのうち 一つだけがトンネルがどのクエリを扱うかに関係します。もう 一つは入力の便宜であり、願望的な読み方によってポリシーへと格上げされたものです。

DNS 行は何に分解されるか

クライアントはエントリをリストとして読み、各項目を形で分類します。アドレスに見えるものは DNS サーバーになり、ドメインに見えるものは検索サフィックスになります。どちらもトンネルの設定に入りますが、フィールドは異なります。プライベートなリゾルバと 一つの内部ドメインを運ぶトンネルの例示行は次のとおりです。

DNS = 10.24.8.53, lab.internal.example

アドレスがリゾルバを提供します。ドメインはサフィックスを提供し、クライアントが短い名前を入力すると、システムが問い合わせの前に残りを補います。どちらも、リゾルバをそのドメインに限定することについては何も述べておらず、そこが人々が期待しても得られない部分です。プラットフォーム上でその制限を表現できるフィールドは 一つだけで、それはこのフィールドではありません。

Apple の 二つのフィールド、二つの異なる役割

Apple は DNS 設定オブジェクトでその区別を明示しています。検索ドメインのリストは、単一ラベルのホスト名を修飾するために使われるリストとして文書化されています：裸のホスト名を入力すると、システムが各サフィックスを順に追加することがあります。これは補完の規則であり、ルーティングの規則ではありません。そのリストの中の何も、どのサーバーに問い合わせるかを決めていません。

マッチドメインのリストは別のプロパティです。どの名前空間がこの DNS 設定の集合を使うかを決め、空のエントリは特定のサフィックスではなくデフォルトドメインを意味します。 パケットトンネル設定ジェネレータ Apple のクライアントではそのモデルに従います。解析された検索サフィックスを検索リストに入れ、サーバーがある場合はマッチリストを空文字列に設定します。結果は、システムが送るすべてに応答するトンネルのリゾルバと、短い名前を助けるサフィックスです。

つまり、その行のドメインは名前空間の選択子ではありません。別のドメインを追加してもトンネルが使うクエリは狭まらず、削除しても広がりません。変わるのは、いくつの短い名前が補完されるかだけです。

なぜすべての名前が依然としてトンネルのリゾルバに届くのか

マッチのエントリが空のとき、トンネルは会社のドメインだけでなく通常の名前の候補リゾルバになります。フルトンネルの構成では、すべてのトラフィックがもともとトンネル内にあるため、これはふつうほとんど問題になりません。分割トンネルでは大いに問題になります。公開名が、プライベートゾーンしか持たないリゾルバで解決されるようになり、失敗は壊れた VPN のように見えますが、実際には名前空間の一部にしか応答しないリゾルバなのです。トンネルは正常で、クエリは外に出て、応答は空で戻ってきます。

修正方法は 二つあり、どちらも異なる判断です。トンネルのリゾルバを、公開名を承認済みの経路で転送する完全なリゾルバにするか、ドメインのリストではなくクライアントの構成を変えて公開名をそこへ送るのをやめてください。前者はすべてのクエリをトンネル上に保ち、上流を信頼します。後者は一部のクエリをローカルに保ち、トンネルが落ちている間はプライベート名が解決されなくなることを受け入れます。

分割 DNS が実際に必要とするもの

名前空間に限定されたリゾルバポリシーには、それを表現できるクライアントが必要です: Apple のプラットフォームでドメインをマッチさせるか、使用する製品の同等の設定を行います。サーバーとサフィックスしか受け付けない構成フィールドでは、どのように句読点を打っても表現できません。プロファイルは、接続時のヒントではなく管理された構成を記述するため、ポリシーを運べます。ドメイン、サーバー、そしてそのドメインに到達できないときに何が起きるべきかを指定できます。これが設定と契約の違いです。

管理された Apple デバイスでは、通常、ドメイン固有の DNS 設定を運ぶ構成プロファイルを通じて配信されます。これは WireGuard の構成ファイルとは別の仕組みであり、クライアントがプロファイルを尊重する場合にのみ両立できます。二つの製品が同じように動作すると仮定する前に、クライアントがそのフィールドを実際に何と呼ぶかを確認してください。Mac 上の wg-quick スクリプトと iPhone の WireGuard アプリは似た行を読み、異なる層を通じてインストールします。

インストールされた設定を読むこと、構成ファイルではなく

Mac では、システムが最終的にどうなったかを調べられ、書いたファイルを読み直すよりも情報が多くなります。リゾルバのリストは、どのサーバーがどのドメイン用に構成されているかを示し、スコープ付きのクエリはどちらが勝ったかを示します。行を台無しにするクライアントは、書いたファイルではなくここにそれを示します。iOS には同等のコマンドラインがないため、そこでの証拠は結果です：トンネル経由で解決されるプライベート名と、その応答がどのリゾルバが答えたかを明かす公開名です。

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

この 二つのコマンドは、現在のリゾルバ構成とアクティブなサービスの DNS サーバーを出力します。トンネルのリゾルバがドメイン制限のないデフォルトリゾルバとして現れるなら、構成はクライアントが求めたとおりに動いています。それを直すには、メカニズムを変えることであり、二つ目のサフィックスを足して動作が変わることを期待するのではありません。