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

リゾルバーのアドレスとDNSの通信方式を分けて考える

DNSは、ドメイン名をIPアドレスなどのレコードに変換する仕組みです。システムDNSは、現在のネットワークやシステム設定から取得したDNS設定を指します。カスタムDNSは、使用するリゾルバーを指定する設定です。DNS over HTTPS（DoH）は、DNSクエリをHTTPSで送信する通信方式です。そのため、カスタムDNSとDoHはどちらか一方を選ぶものではなく、指定したリゾルバーへの問い合わせにDoHを使うこともできます。

選ぶ際は、まず「どのリゾルバーに問い合わせるか」と「どの経路で問い合わせるか」を確認します。リゾルバーを変更すると応答するアドレスが変わる場合があり、通信方式を変更するとクエリの経路や保護方法が変わります。どちらもWebサイト自体のHTTPS設定を変更するものではなく、接続先への接続を保証するものでもありません。

DNSの問い合わせとWebサイトへの接続は別々に確認する

一般的なドメインへのアクセスでは、アプリが接続先のアドレスを取得してから接続を確立します。実際にはキャッシュが使われたり、アプリ自体やプロキシ側で名前解決したりする場合があります。毎回すべての処理が端末上で行われるとは限りません。

切り分けでは、「名前解決の結果が返ったか」と「結果を取得した後に接続できたか」を分けて記録します。アドレスが返っていれば、その問い合わせには応答があったということです。ただし、そのアドレスが現在の通信経路で使えるか、接続先のポートに到達できるか、TLS接続が成功するかは、別途確認が必要です。ブラウザーでページを開けないというだけでは、DNS障害とは判断できません。

ポートに到達できることは、確認項目の一つにすぎません。DoHには正しいHTTPSパスと有効な証明書も必要です。通常のDNSアドレスのポートを53から443に変えても、自動的にDoHサービスになるわけではありません。また、DoHが暗号化するのはリゾルバーのエンドポイントまでの問い合わせ通信です。リゾルバーから問い合わせ内容が見えなくなるわけではなく、すべての通信が自動的にプロキシ経由になるわけでもありません。

変更前にバックアップし、DNS処理に現在の設定が関与しているか確認する

ShadowrocketのHomeで現在の接続状態とGlobal Routingを確認し、Settings → DNSでDNS設定を確認します。さらにConfigで現在使用中の構成ファイルを確認してください。構成ファイル内のDNS項目も実際の動作に影響する場合があります。Settingsにアドレスを入力しただけでは、最終的にどのリゾルバーが使われているか判断できません。具体的な項目や選択肢は、アプリ内の表示を確認してください。

1. 現在の値を記録する。DNS項目、現在の構成名、Global Routingの選択内容を記録します。構成ファイルを変更する前にコピーを保存し、必要に応じて個別に戻せるようにします。
2. 基準となる状態を確認する。現在のネットワークで、正常にアクセスできることが分かっている公開ドメインを開きます。ローカルネットワークのリソースが必要な場合は、実際に使用しているローカルドメインも比較対象にします。
3. DNSだけを変更する。すでに利用しており、使用が認められているリゾルバーの設定を使い、サーバーやルール、プロトコルのパラメーターは同時に変更しません。
4. 接続を再確立する。保存後に接続をいったん切断して再接続し、改めてアクセスします。既存の接続やキャッシュに以前の結果が残る場合があるため、ページを一度更新しただけで判断しないでください。
5. ネットワークごとに確認する。実際に使用するWi-Fiとモバイル通信のそれぞれで検証します。Settings → On Demandを設定している場合は、テスト中に自動再接続が発生していないかも確認してください。

DoHのエンドポイントにドメイン名を使う場合、HTTPS接続を確立する前にそのドメイン名のアドレスを取得する必要があります。これは初期名前解決またはbootstrapと呼ばれます。エンドポイントを解決する唯一の方法が、まだ確立されていない同じDoH接続に依存しないようにしてください。現在の設定にこの依存関係がある場合は、同じURLを何度も入力し直すのではなく、初期名前解決の設定を確認します。証明書の名前照合に失敗する可能性があるため、エンドポイントのドメイン名を安易にIPアドレスへ置き換えないでください。

DNSとルールによる振り分けの関係：アドレスが返ってもルール適用とは限らない

Home → Global RoutingのConfigは、現在の構成ルールに従って通信を処理します。ProxyとDirectは異なる全体ルーティングの選択肢であり、それぞれのテスト結果をConfigでのルール検証の代わりにはできません。Sceneを使用している場合は、そのSceneで実際に有効なルーティング設定も先に確認してください。DNSの問い合わせ経路と、接続先に適用されたポリシーは別々に確認します。

ドメインルールは利用可能なドメイン情報をもとに照合し、IPルールは接続先のアドレスをもとに照合します。IPによる判定が必要な通信では、名前解決の結果が後続のルール適用に影響する場合があります。ただし、すべてのルールで端末上のDNS問い合わせが必要という意味ではありません。アプリが直接IPアドレスに接続する場合、照合対象となる元のドメイン名が存在しないこともあります。

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

• DOMAIN-SUFFIX,example.com,PROXYは、example.comとそのサブドメインに一致するルールで、指定されたポリシーに従って処理します。
• IP-CIDR,192.0.2.0/24,DIRECT,no-resolveは、アドレス範囲を指定するルールの例です。no-resolveは、このルールとの照合のためにドメイン名の名前解決を新たに行わないことを示します。
• GEOIP,CN,DIRECTは、IPアドレスの国・地域データベースに基づいて照合します。ドメイン名の文字列で判定するものではありません。
• FINAL,PROXYは、前のルールに一致しなかった場合に適用されるフォールバックです。ルールの順序は結果に影響し、通常は上から順に確認されます。

ここでの説明は構文の概要です。例に使ったドメイン名やIPアドレス範囲はドキュメント用で、そのまま使える完全な設定ではありません。DNS変更後にアクセス先が別のIPルールに一致した場合は、まず応答アドレスを比較し、その後ルールの順序を確認してください。一つのドメインを直すために、すべてのルールを削除しないでください。リゾルバーへの問い合わせもプロキシ経由にする場合は、「プロキシ接続前の名前解決が必要なのに、その名前解決が同じプロキシに依存する」という循環依存がないかも確認します。

現象ごとに原因を切り分け、すべてのタイムアウトをDNSの問題と決めつけない

再テストのたびに、現在のネットワーク、問い合わせたドメイン名、応答またはエラー、その後の接続結果の4点を記録します。比較時は構成と接続先をそろえ、キャッシュにも注意してください。HomeのConnectivity Testは接続状況を確認する手掛かりになりますが、一度の遅延測定はダウンロード速度ではなく、すべてのドメインが正常に解決できる証明にもなりません。

NXDOMAINは、リゾルバーがドメイン名は存在しないと応答したことを意味します。「応答が届かなかった」タイムアウトとは異なります。SERVFAILは、リゾルバーが処理を完了できなかったことを示し、上流サーバー、DNSSEC検証、その他の名前解決障害が原因の可能性があります。まずドメイン名の入力を確認し、同じドメインを基準となるDNS経路で問い合わせた結果と比較してください。異なるエラーをすべて「ネットワークが遅い」とひとまとめにしないでください。

検証後は、元に戻せる設定記録を保管する

最終的な選択は、実際のアクセス要件に合わせて決めます。システムDNSは現在のネットワークとの比較に適しています。リゾルバーを固定する方法は、問い合わせ先を明確に管理したい場合に向いています。DoHは、HTTPSでの問い合わせが必要で、エンドポイントに正常に接続できる環境に適しています。いずれの方式を使う場合も、一度の問い合わせ時間だけで判断せず、公開ドメイン、ローカルドメイン、現在のルールによる振り分けをあわせて確認してください。

• 設定の入手元を記録する。リゾルバーの設定値と用途を記録します。公開するスクリーンショットには、個人用のアドレス、認証情報、サブスクリプションの内容を表示しないでください。
• 自動更新を確認する。既存のサブスクリプションの更新とローカル構成の変更は別の操作です。更新後は関連設定を再確認し、更新による変化をDNSの不安定さと取り違えないようにします。
• 元に戻す手順を残す。元のDNS値とGlobal Routingの選択内容を記録します。問題が起きた場合は、まず基準の設定に戻してから一つずつ再テストします。
• 変更は一度に一つずつ検証する。ルールとDNSの両方を調整する場合は、2回に分けて保存とテストを行い、それぞれの結果を変更内容に対応させます。

ShadowrocketはAppleプラットフォーム向けのクローズドソースの有料アプリで、主にiPhoneとiPadで使用できます。その他のデバイスとの互換性とシステム要件は、App Storeの掲載内容をご確認ください。アプリは買い切りで、アプリの購入と通信サービスは別です。この記事は、利用者が自分の設定を用意していることを前提としています。ノードやサブスクリプションの提供・販売・推奨は行っていません。