V2Ray DNS設定ガイド｜ドメイン別DNS振り分けとDNS汚染対策

1. アプリ・コア・サーバーのDNSを区別する

DNS設定でまず確認するのは、「この設定を通じて問い合わせが行われるか」です。アプリがドメイン名をプロキシに渡すと、ルーティング判定や直接接続のためにコアが名前解決する場合と、ドメイン名をプロキシサーバーに渡してサーバー側で解決する場合があります。アプリがローカルでドメイン名をIPアドレスに変換してから、そのIPアドレスをプロキシに渡す場合は、クライアントのdnsセクションが問い合わせに使われるとは限りません。

このフローはローカルで名前解決が必要な場合を示したもので、プロキシ接続のたびにローカルDNSへ問い合わせるわけではありません。ドメインルールでプロキシ経由のアウトバウンドを選べる場合、接続先のドメイン名がそのままリモート側に送られることがあります。その場合、ローカルDNSのログにドメイン名が見当たらなくても、設定が機能していないとは限りません。

• システムDNS：OSのネットワーク設定で指定します。システムプロキシを有効にしただけでは、OSのDNSリクエストがすべてV2Rayに渡るわけではありません。
• コアのDNS：設定ファイルのdnsで定義し、コア内の関連する名前解決処理に使われます。システムの53番ポートを自動でリッスンするサービスではありません。
• ブラウザーのセキュアDNS：ブラウザーがHTTPS経由で独自に問い合わせ、OSのリゾルバーを経由しない場合があります。
• サーバー側のDNS：プロキシのアウトバウンドがドメイン名をリモート側に送った後の名前解決結果は、リモート側のDNSとネットワーク環境によって決まります。

2. servers・domains・queryStrategyの役割

serversでは利用するDNSサーバーを定義します。サーバーオブジェクト内のdomainsでは優先的に照会するドメインを指定し、queryStrategyでは問い合わせるアドレスファミリーを制御します。それぞれ「どこに問い合わせるか」「どのサーバーを優先するか」「どの種類のアドレスを取得するか」を設定するもので、サイトへの接続を決めるアウトバウンドルールとは別の設定です。

domainsは「指定したドメインだけがこのサーバーを使える」というアクセス制御リストではありません。一致したドメインは通常、優先的に問い合わせられます。一致しないドメインも、フォールバックによっていずれかのサーバーで解決される場合があります。中国本土向けサーバーにskipFallback: trueを設定するのは、一致しないドメインのフォールバック候補から除外するためです。すべてのDNSフォールバックを無効にする設定ではありません。

この記事では調査対象を絞るためにUseIPv4を使用しています。IPv4のほうが必ず速いという意味ではありません。ネットワークとノードの両方でIPv6が正常に使える場合は、UseIPに変更して再確認できます。この設定の影響は内蔵DNSの問い合わせに限られ、システム全体のIPv6を無効にするものではありません。

3. ドメイン別にDNSを振り分ける設定例

以下はトップレベル設定に追加するdnsセクションであり、単独で動作する完全なクライアント設定ではありません。既存のJSONに統合する際は、同じオブジェクト内にdnsを二重に追加せず、既存の同名フィールドを置き換えてください。geosite:cnを使う前に、実行ディレクトリでドメインルールのデータを利用できることも確認してください。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query"
      }
    ]
  }
}

1. geosite:cnに一致するドメインは、223.5.5.5に優先して問い合わせます。中国本土のサービスで一般的な、近隣サーバーへの名前解決結果を得やすくするためです。
2. 優先対象に一致しないドメインには、フォールバックリストのDoHサーバーを使用します。中国本土向けサーバーはskipFallbackにより除外されます。
3. 中国本土向けサーバーへの優先問い合わせに失敗した場合、フォールバックを別途無効にしていなければ、DoHが試されることがあります。この設定例が示すのは優先順位であり、完全な分離ではありません。

中国本土のドメインで失敗した後、他のDNSサーバーへの問い合わせも一切許可しない要件がある場合は、使用するコアの対応状況を確認したうえで厳密なフォールバック方針を設計してください。配列の順序から動作を推測することはできません。V2RayとXrayでは拡張フィールドや対応範囲が常に同じとは限りません。他のコア向けの高度なフィールドをコピーする前に、使用中のコアのドキュメントと起動ログを確認してください。

ここではIPアドレスを含むDoHのURLを使い、「DNSサーバーのドメイン名を先に解決する」依存を減らしています。ドメイン名を含むDoHサービスに変更する場合は、そのドメイン名を最初に解決する方法も用意してください。解決先のDNSサーバーを見つけるために自身の応答を待つ、循環依存を避ける必要があります。DoHのTLS証明書検証は有効なままにしてください。接続エラーへの対処として検証を無効にしてはいけません。

4. DNS問い合わせ自体のアウトバウンドルーティングを設定する

暗号化DNSとプロキシ経由の通信は別の設定です。DoHはDNSサーバーまでの問い合わせ内容を保護し、DNSサーバーへの接続を直接接続にするかプロキシ経由にするかはルーティングで決まります。現在のネットワークからリモートDoHに直接接続できない場合、URLを入力するだけではタイムアウトします。次の例では、DoHの接続先IPをプロキシ経由にし、中国本土向けDNSは直接接続にします。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "1.1.1.1/32"
        ],
        "port": "443",
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "223.5.5.5/32"
        ],
        "port": "53",
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

proxyとdirectはこの例で使用するアウトバウンドのタグです。既存のoutboundsにあるtagと完全に一致させてください。次のルールは既存のルーティングの前方に追加し、既存のルール全体を置き換えないでください。一致しない通信は後続のルールまたはデフォルトのアウトバウンドで処理されます。この例ではデフォルトのアウトバウンドを定義していません。

• 通常のHTTPS形式のDNSアドレス：この例のhttps://による問い合わせは、コアのルーティング制御に従って送信されます。そのため、DoHの接続先に対するルーティング設定が必要です。
• ローカル直接接続を意味する形式のアドレス：たとえば、対応するコアでのhttps+local://は動作が異なります。この例のプロキシ経由ルーティングの想定をそのまま当てはめないでください。
• プロキシノードのアドレスにドメイン名を使う場合：ノードのドメイン名を独立して名前解決できるようにしてください。そうしないと、「リモートDNSへの接続にはプロキシが必要だが、プロキシへの接続にはそのDNSが必要」という依存の循環が起きることがあります。

routing.domainStrategyとdns.queryStrategyは別の設定です。ここでのAsIsは、IPルールを適用するためにルーティングがドメイン名を積極的に解決しないことを意味します。IPIfNonMatchに変更すると、ドメインルールに一致しない場合に名前解決を試みてからIPルールを適用します。IPアドレスで振り分ける必要がある場合に有効にしてください。「DNSを機能させるため」という理由だけで、むやみに変更しないでください。

5. v2rayNで適用して動作を確認する

まず現在の設定をバックアップしてからDNSを変更してください。v2rayNは画面の設定に基づいてコアの設定を生成します。一時生成されたファイルを直接編集すると、ノードの切り替えやコアの再起動後に上書きされることがあります。一般的な画面では「設定」→「DNS設定」から開きますが、画面のバージョンによって項目が異なる場合があります。別のコアの項目ではなく、使用中のコアに対応するDNS設定を編集していることを確認してください。

1. コアと設定の読み込み元を確認する。現在のノードで使用するコアを確認してください。この記事のJSONはV2Ray/Xrayの設定構造を対象としています。他のコアのDNSフィールドをそのまま流用することはできません。
2. DNSとルーティングを個別に保存する。DNSの編集欄には、その欄で指定された形式のオブジェクトだけを入力してください。トップレベルのJSON全体を1つのサーバー入力欄に貼り付けてはいけません。ルーティングタグは実際に生成された設定に合わせてください。
3. コアを再起動して起動ログを確認する。まずJSONの構文エラー、未対応フィールド、ルールデータの不足などを解消してから、Webページをテストしてください。コアが正常に起動していなければ、ネットワークテストを比較しても意味がありません。
4. テスト条件をそろえる。中国本土のサービスのドメインを1つ、プロキシ経由で接続するドメインを1つ選び、アプリが独自のセキュアDNSを使っているか記録してください。変更後はテスト対象のアプリを再起動し、既存の接続を再利用しないようにします。
5. 接続経路を確認する。必要に応じて一時的にログレベルを上げ、1.1.1.1:443への接続がプロキシのアウトバウンドに一致するか、223.5.5.5:53への問い合わせが直接接続されるか確認してください。調査後はログレベルを元に戻します。

Windowsでipconfig /flushdnsを実行すると、システムDNSのキャッシュは消去できますが、ブラウザー独自のキャッシュやコアのすべてのキャッシュは消去されません。単独で実行したnslookupがテストするのは通常、システムで指定されたDNSサーバーです。コアのdnsセクションが有効になったことを、これだけで証明することはできません。

6. DNS汚染対策の限界とよくあるトラブル

DNS汚染対策の基本は、対象ドメインの問い合わせを信頼できるDNSサーバーに送り、問い合わせの通信経路を保護することです。中国本土向けのUDP DNSは引き続き暗号化されていません。中国本土のサービスに適した名前解決のためにこの記事では使用していますが、DoHと同等の通信保護があるという意味ではありません。この経路で問題が起きる場合は、使用中のコアが対応し、ネットワークから到達できる暗号化DNS方式に切り替え、ルーティングを再確認してください。

同じドメインでもDNSサーバーによって異なるアドレスが返ることがあり、それだけでDNS汚染とは限りません。コンテンツ配信ネットワーク（CDN）は、リゾルバーの場所やネットワーク方針に応じて異なるノードを返す場合があります。反対に、もっともらしいパブリックIPアドレスが返ってきても、名前解決結果が信頼できるとは限りません。アドレスが一致しないという理由だけで静的なIPアドレスを設定しないでください。アドレスが古くなるおそれがあり、通常のサーバー振り分けも回避されます。

• 原因を特定できなくなるのを避けるため、DNSサーバー、問い合わせるアドレスファミリー、アウトバウンドルートは一度に1つだけ変更してください。
• 一時的なデバッグログには、アクセスしたドメイン名や接続情報が含まれることがあります。ログを共有する前に、サブスクリプションURL、認証情報、その他の機密情報を削除してください。
• 最終確認では、一度Webページを再読み込みするだけでなく、中国本土向けの接続、プロキシ経由の接続、コア再起動後の設定保持も確認してください。