ShadowrocketのDNS設定ガイド：システムDNS・カスタムDNS・DNS over HTTPSの選び方

DNS名前解決とGlobal Routingの通信経路を区別する

DNS（ドメインネームシステム）は、ドメイン名を接続先のアドレスに変換します。ページを開くには名前解決が必要ですが、その後にもルール判定、接続確立、TLSハンドシェイク、応答の受信があります。Webページが開けないからといって、原因がDNSとは限りません。DNSサーバーを変更しても、あらゆる接続タイムアウトが解消されるわけではありません。

この流れは、問題が発生している段階を切り分けるためのものです。すべてのリクエストが必ず同じ順序で処理されるわけではありません。キャッシュの有無、ドメインルールの先行判定、リモートでの名前解決、アプリ独自の名前解決方法などにより、実際の処理は異なります。特にドメインルールは、ローカルでIPアドレスを取得する前に判定されることがあります。

• Home → Global Routingは、通信に適用するルーティング方式を決める設定であり、DNSサーバーの選択とは別です。
• Configは、現在の設定ファイルにあるルールに従って通信を振り分けます。ProxyとDirectは、全体の通信経路としてプロキシまたは直接接続を選択します。
• Sceneはシーンを選択する機能です。問題を調べる際は、現在のシーンと実際に使用されている設定を記録してください。名前解決のプロトコルとして扱わないようにしましょう。
• Settings → On Demandは、接続を開始する条件を設定します。テスト中にネットワーク状況が変わると接続状態も変化する場合があるため、あわせて記録してください。

すでにサブスクリプションを利用している場合、更新によって通常更新されるのは接続項目です。現在のConfigにあるDNS設定も更新されたとは限りません。問題を調べる前に、選択中の接続先、有効な設定、Global Routingの状態をそれぞれ記録し、混同しないようにしましょう。

システムDNS・カスタムDNS・DoHの選び方

システムDNSは、現在のシステムのネットワーク環境に応じたDNS設定を使います。Wi-Fiとモバイル通信では設定が異なる場合があります。カスタムDNSは名前解決先を指定する設定です。通常のDNSサーバーアドレスを入力した場合、一般的なDNS通信が使われます。DNS over HTTPS（HTTPS経由のDNS、DoH）は問い合わせの通信方法を変更するもので、より速い応答や現在のネットワークに適したアドレスが返ることを保証するものではありません。

DoHエンドポイントには、明示的に別のポートを指定する場合もあります。HTTPSサイトにアクセスできても、特定のDoHエンドポイントに接続できるとは限りません。サーバーのドメイン名、ポート、リクエストパス、証明書が一致している必要があります。問い合わせの通信が暗号化されても、名前解決先は問い合わせを処理し、その内容を確認できます。これをもってすべての通信が隠されるわけではありません。

現在のConfigでDNSを確認し、一項目ずつ変更する

まずConfigで現在有効なファイルを確認し、[General]とdns-serverの項目を確認します。アプリ内のDNS設定はSettings → DNSから確認できます。有効になっていない設定ファイルだけを変更し、その後、DNS設定が反映されていないと誤認しないようにしてください。

1. 元の値を残す。現在の設定をコピーして復元用の控えを作り、DNSの項目、Global Routingの状態、現在のネットワークを記録します。設定に認証情報が含まれている場合は、控えを安全に保管してください。
2. テスト対象を決める。正常にアクセスできることが分かっている公開ドメインと、実際に問題が起きているドメインを一つずつ選びます。LAN内の名前は公開ドメインと分けてテストしてください。
3. 変更するのはDNS設定だけ。有効な設定のdns-serverを確認するか、該当するDNS設定画面で現在の値を確認します。通信経路、ルール、IPv6、On Demandを同時に変更しないでください。
4. 保存して再接続する。現在の接続を終了してから再接続し、新しいリクエストを送信します。すでに開いているページ、既存の接続、キャッシュからの応答だけでは、十分な確認になりません。
5. 失敗した段階を確認する。名前解決のタイムアウト、接続のタイムアウト、証明書エラーのどれかを確認します。結果が悪化した場合は元の設定に戻し、再接続してください。

以下の2つの例は、同じ項目の異なる書き方を示しています。同じ設定ファイルに両方を重複して追加しないでください。実際のファイルにある他の必要な設定は残します。例に合わせるために、数行の記述で設定ファイル全体を置き換えないでください。

[General]
dns-server = system

[General]
dns-server = https://resolver.example.com/dns-query

設定がリモート更新で管理されている場合は、更新によってローカルの変更が上書きされないか、先に確認してください。控えを残してテストし、更新後は前回の入力内容ではなく、有効な設定ファイルに現在記録されている値を確認しましょう。

DoHと通常のDNSのアドレスの入力・確認方法

通常のDNSアドレスとDoH URLは、自由に置き換えられる形式ではありません。前者はサーバーアドレスを示し、後者にはプロトコル、ホスト名、リクエストパスも含まれます。通常のDNSアドレスの先頭にhttps://を付けても、そのサーバーが自動的にDoHに対応するわけではありません。

ドメイン名で指定するDoHエンドポイントには、事前の名前解決が必要です。HTTPS接続を確立する前に、エンドポイント自体のアドレスを取得しなければなりません。事前の名前解決が使えない場合、「DNSサーバーのドメイン名を調べるために、まずDNSが必要」という依存関係が生じることがあります。その場合は、現在のネットワークの基本的な名前解決とエンドポイントへの接続経路を確認してください。同じ理由で接続できないエンドポイントを次々に追加するのは避けましょう。

• アドレスに到達できても、プロトコルが使えるとは限らない：IPアドレスに接続できても、指定ポートがDoHを提供しているとは限りません。
• HTTP応答があっても、問い合わせの成功とは限らない：ブラウザーでエンドポイントを開いてエラーページが表示されても、それだけでDoHサービスの障害とは判断できません。通常のブラウザーアクセスは、適切な形式のDNS問い合わせとは異なります。
• 証明書エラーの原因を調べる：デバイスの時刻、ホスト名、ネットワークのログイン状態を確認し、証明書検証を無効にする方法で解決しようとしないでください。

ルール・IPv6・LAN内の名前解決が結果に影響する理由

DNSがアドレスを返した後も、通信には適用されるルーティング判定が必要です。DOMAIN-SUFFIXはドメインの末尾を、IP-CIDRはIPv4アドレス範囲を、GEOIPはIPアドレスの地理的な割り当てを基準に判定します。DNSサーバーを変更すると返されるアドレスが変わり、それに応じてアドレスを基準にしたルールの判定結果も変わる場合があります。

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

上の例は構文とマッチングの関係を示すもので、完全な設定ではありません。DIRECTは直接接続、PROXYはプロキシ経由を表します。実際に使う際は、現在の設定が認識するポリシー名を確認してください。ルールは上から順に評価され、FINALがそれ以前のルールに一致しなかった通信を処理します。アドレス範囲はドキュメント用の例であり、普段の振り分け設定にそのまま使わないでください。

• no-resolveは、そのアドレスルールのためにドメイン名を積極的に名前解決しないことを示します。「すべてのDNSを無効にする」という意味ではなく、すでに取得した名前解決結果を消去するものでもありません。
• 同じドメイン名のAレコードとAAAAレコードが、異なるアドレスを返す場合があります。AAAAレコードが取得できても、IPv6の接続経路が現在利用できるとは限りません。
• 会社や家庭のネットワークで使う内部ドメインは、ローカルDNSに依存している場合があります。外部DNSに変更した後、公開サイトにはアクセスできるのに内部ドメインだけ失敗する場合は、別途確認が必要です。
• アプリによっては、独自の暗号化DNSやキャッシュを利用します。特定のアプリの動作が変わらないからといって、ShadowrocketのDNS設定が保存されていないとは限りません。

ログインが必要なWi-Fiを利用する場合は、まずネットワーク認証を済ませてからカスタムDNSを確認してください。認証前にHTTPSエンドポイントへ接続できない、証明書エラーが出る、外部へのリクエストがすべてタイムアウトするといった場合は、DNSの記述ミスではなく、ネットワークへのアクセスが許可されていない可能性があります。

変更後の確認方法：ページが開くかだけでなく、失敗した段階を記録する

同じネットワーク、同じ通信経路、同じルーティング方式で確認します。まず元の設定で基準となる結果を記録し、その後に候補の設定へ切り替えます。各回のリクエスト時刻、対象ドメイン、アドレスが返ったか、その後の接続結果を記録してください。キャッシュからの即時応答と、DoH接続を初めて確立する際の所要時間を直接比較しないでください。

アプリ内ログは問題の切り分けに役立ちますが、リクエストによって記録される項目は異なる場合があります。新しいDNSの行がログにない場合、キャッシュが使われた可能性も、別の場所で名前解決された可能性もあります。実際のリクエスト時刻やルーティング記録と照らし合わせて判断し、ログの一行がないことだけを根拠に結論を出さないでください。

1. 再現性のある問題が起きるドメインで、元の設定と変更後の設定の結果をそれぞれ記録します。
2. AまたはAAAAレコードを取得できたか確認し、その後、接続に使われたアドレスと適用されたポリシーを確認します。
3. プライバシーの検証が必要な場合は、自分で管理するテスト用ドメインとサーバーの記録だけを使用してください。名前解決に使われた送信元アドレスが異なっていても、必ずしも異常とは限りません。
4. 比較が終わったら、確認済みの変更だけを残し、テスト値を削除して、復元用の控えを保管します。

よくある質問：設定を保存しても反映されない場合