ShadowrocketのDNS設定｜システムDNS・カスタムDNS・DoHの選び方

DNS名前解決とルールによる通信振り分けの違い

DNSはドメイン名をIPアドレスなどのレコードに変換します。ウェブサイトを開く際、名前解決は接続プロセスの一部にすぎません。アドレスを取得した後も、経路選択、通信接続、TLSハンドシェイク、ページリソースの読み込みが必要です。そのため「DNS変更後に開けた」は調査の手がかりになりますが、「ページが開かない」ことだけでDNS障害とは断定できません。

Shadowrocketの dns-server は名前解決に使う上流サーバーを指定し、ルール内の DIRECT と PROXY は該当する通信の処理方法を指定します。別々の設定です。暗号化DNSを使ってもウェブ通信が必ずプロキシ経由になるわけではなく、システムDNSを使っても必ず直接接続になるわけではありません。

この流れは、切り分けるべき調査段階を示したもので、すべてのルールが名前解決の完了を待つという意味ではありません。DOMAIN-SUFFIX はドメインの末尾で直接照合できます。IP-CIDR と GEOIP はIPアドレスで照合するため、ドメイン名しかない場合は名前解決が必要になることがあります。ルールは上から順に評価され、末尾の FINAL が一致しなかった通信を処理します。DNSを変更してもルールの順序は変わりません。

システムDNS・カスタムDNS・DoHの使い分け

「システム」と「カスタム」は名前解決サーバーの取得元を表し、DoHは問い合わせの伝送方式を表します。分類の観点は同じではありません。DoHのURLを手動で入力する場合も、実質的にはカスタムの名前解決先を指定しています。名称だけで比べず、ネットワークからの到達性、内部ドメインの要件、問い合わせの伝送方式を考慮して選びましょう。

Configで変更する前に、現在の設定を確認

この記事では、設定ファイルの [General] セクションを編集する方法を基準に説明します。特定バージョンの画面上のボタン配置には依存しません。Homeでは接続状態とGlobal Routing、Configでは設定ファイル、Settingsではアプリの設定を確認できます。有効化されていないファイルだけを編集しても、通常、現在の接続で使われている設定は変わりません。

1. Homeで現在の接続項目とGlobal Routingの設定値を記録します。ルールを使ってテストする場合は、Configモードにして、現在有効な設定ファイルを確認してください。
2. Configを開き、現在の設定をバックアップまたは複製します。元のDNS行とほかのGeneral設定を残し、複数の条件を同時に変更しないようにします。
3. ファイルの編集機能を開き、[General]を探します。dns-serverがすでにある場合はその行を編集し、切り替えのために同じ設定を複数行追加しないでください。
4. 保存後、テスト用ファイルが有効になっていることを確認します。いったん切断してから再接続し、新しい設定でテストします。
5. 比較を始める前に、Wi-Fiとモバイル通信のどちらを使っているか、テストするドメイン、発生している現象、元に戻す方法を記録します。

[General] セクションにおけるdns-serverの3つの記述例

以下は互いに併用しない最小構成の例です。毎回1つだけ選び、現在の設定にある該当項目と置き換えてください。これらの短い例で設定ファイル全体を上書きすると、既存のルールやほかの設定が失われます。独自のドメインマッピングやDNS関連の設定がある場合は、その動作もあわせて確認してください。

システムDNSを使う

[General]
dns-server = system

systemはシステムが提供するDNSを使う指定です。比較の基準として適しており、特に現在のネットワークで内部ドメインの名前解決が必要な場合に便利です。「システム」は特定のDNSサーバーのアドレスを固定するものではありません。Wi-Fi、モバイル通信、システムのネットワーク設定を切り替えると、名前解決先が変わることがあります。

カスタムの通常DNSを指定する

[General]
dns-server = 1.1.1.1

1.1.1.1は通常DNSアドレスの記述例であり、すべてのネットワークでの利用を推奨するものではありません。信頼でき、現在のネットワークから到達可能だと確認したDNSサーバーを使用してください。IPアドレスを入力するだけで通常DNSがDoHに変わるわけではなく、問い合わせがプロキシ経由で送信されるかどうかも判断できません。

DNS over HTTPSのエンドポイントを指定する

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

dns.example.comは予約済みの例示用ドメインです。上記のアドレスは記述形式を示すだけで、実際の名前解決には使えません。利用する場合は、DNSサービスが提供する完全なDoHエンドポイントに置き換えてください。https://、ホスト名、パスが必要です。/dns-queryは一般的なパスですが、実際のエンドポイントの指定に従ってください。サービスのトップページだけを入力しないでください。

DoHは問い合わせの伝送を解決するもので、通信の出力先確認に代わるものではない

DoHは、クライアントと名前解決エンドポイント間のDNS問い合わせをHTTPSで保護します。ただし、名前解決サービスが問い合わせ内容を処理する必要がなくなるわけではなく、ウェブサイトとの接続に必要なTLSの代わりにもなりません。地理的位置、キャッシュ、サービスのポリシーによって応答アドレスが異なる場合がありますが、その違いだけでは誤りや高速化の根拠になりません。

DoHエンドポイントにドメイン名が使われている場合、クライアントはまずそのエンドポイントのアドレスを取得する必要があります。これは一般に名前解決のブートストラップと呼ばれます。エンドポイントのドメインを解決できない、証明書の検証に失敗する、またはエンドポイントへのHTTPS接続が確立できない場合、設定の記述が正しくても正常に名前解決できないことがあります。

• 名前解決結果を確認：対象ドメインからアドレスが返るか、明確な不存在の応答があるか、それともタイムアウトが続くかを確認します。これらは別々の状態です。
• 問い合わせ経路を確認：通常DNSのポート53、またはDoHエンドポイントへのHTTPS接続に到達できるかを確認します。
• 接続先を確認：アドレスを取得した後、対象ウェブサイトへの接続、TLSハンドシェイク、またはリソース取得に失敗していないかを確認します。
• ルールの適用を確認：Global RoutingがConfigの場合、該当するドメインルール、IPルール、最終ポリシーを確認します。

Global RoutingのProxy、Direct、ConfigをDNSの種類と一対一に対応づけないでください。これらは通信の処理モードです。Sceneは状況に応じた切り替えに使うもので、4つ目のDNSプロトコルではありません。比較可能な結果を得るため、DNSのテスト中は同じモード、接続項目、ルールファイルを維持してください。

キャッシュによる誤判定を避け、同じ手順で確認する

ブラウザー、システム、アプリには、接続や名前解決のキャッシュが保持される場合があります。設定変更直後に開いていたページが引き続き読み込めても、新しいDNSサーバーが有効になった証拠にはなりません。初回の読み込みが遅い場合も、新規接続時のハンドシェイクが影響している可能性があります。一度のページ読み込みだけで判断せず、同じ対象を繰り返し確認してください。

1. 基準の状態を記録：同じネットワークで元の設定を使い、よく見るウェブサイトと問題のあるウェブサイトにアクセスします。「名前解決タイムアウト」「接続タイムアウト」「ページの一部のリソース読み込み失敗」など、具体的な状態をそれぞれ記録します。
2. DNSだけを変更：接続項目、Global Routing、ルールはそのままにし、dns-serverだけを変更して保存した後、再接続します。
3. 新しいリクエストを発生させる：開いているページを閉じてから再度アクセスし、接続記録やログで確認できる情報もあわせて調べます。プライベートブラウズでも、システムのDNSキャッシュが消去されるとは限りません。
4. 元の設定に戻して比較：元のDNS設定に戻し、もう一度試します。どちらの設定でも失敗する場合は、DNSサーバーを何度も変更せず、接続先サービス、通信の出力先、ルールを引き続き確認してください。
5. ネットワークの違いを個別にテスト：最後にWi-Fiとモバイル通信を切り替えて再テストします。DNS変更と同じテストでネットワークも同時に切り替えないでください。

DNS設定に関するよくある質問