この記事は、Shadowrocketの基本的な接続設定を済ませ、DNSの選択やドメイン名の名前解決に関する問題を調べたい方に向けた内容です。まず、DNSサーバー・問い合わせ方式・問い合わせの通信経路を区別します。次にシステムDNS、カスタムDNS、DoHを一つずつ比較し、最後にConfigのルールと接続ログで結果を確認します。
DNS設定で変わること
DNSはドメイン名をIPアドレスに変換します。Webサイトを開く際、クライアントは通常AレコードまたはAAAAレコードを取得し、対応するアドレスへ接続します。AはIPv4、AAAAはIPv6のアドレスです。名前解決に成功しても、その後のTCP、TLS、プロキシ接続が成功するとは限りません。「Webページが開かない」原因をすぐにDNSと決めつけないようにしましょう。
以下はトラブルシューティング用の概念図で、すべての接続が必ず同じ順序で処理されるわけではありません。ドメインルールは接続先IPの取得前に判定できる一方、IPルールは名前解決の結果に依存する場合があります。また、プロキシ接続によってはドメイン名の解決をリモート側で行います。
確認すべきことは3つです。どのDNSサーバーに問い合わせるか、どのプロトコルで問い合わせるか、問い合わせ自体がどの通信経路を通るかです。サーバーのアドレスを変更しても分かるのは1つ目だけです。DoHを選ぶと主に2つ目が変わります。DNSの通信経路は現在の設定や接続条件にも左右されるため、入力内容だけでは判断できません。
システムDNS・カスタムDNS・DoH
システムDNSは通常、デバイスが接続中のネットワークから提供されるDNS設定を使います。比較の基準として使いやすく、社内ネットワーク、学校のネットワーク、家庭内LANの内部ドメインにも対応しやすい方法です。ただし、Wi-Fiからモバイル通信に切り替えると、実際に使われるDNSサーバーが変わることがあります。ネットワークごとに結果を記録しましょう。
| 設定方法 | 設定で指定する内容 | 適した状況 | 主な確認項目 |
|---|---|---|---|
| システムDNS | システムのDNS設定を使用 | 基準となる状態の確認、ローカルDNSが必要なドメインへのアクセス | ネットワークの切り替え、内部ドメイン、システム設定 |
| カスタムDNS（従来型） | DNSサーバーのアドレスを指定 | 使用するDNSサーバーを固定でき、そのサーバーに接続できる場合 | UDP / TCP 53番ポートへの接続、応答レコード |
| DNS over HTTPS | 指定したエンドポイントへHTTPSで問い合わせ | 暗号化したDNS通信が必要で、エンドポイントへHTTPS接続できる場合 | 完全なURL、証明書、時刻、初期名前解決 |
「カスタム」と「暗号化」は別の要素です。通常のDNSサーバーのIPアドレスを手動で入力しても、DoHにはなりません。また、DoHを使えば現在のネットワークに最適なアドレスが返るとも限りません。DNSリゾルバーは問い合わせ元や独自の方針に応じて、異なるCDNのアドレスを返すことがあります。DNSを変更した後にWebページの表示が遅くなっても、問い合わせ自体が遅くなったとは限りません。
DoHが暗号化するのは、デバイスからDoHエンドポイントまでのDNS問い合わせ通信です。エンドポイントが受け取る問い合わせを隠すものではなく、Webサイト自体のHTTPSに代わるものでもありません。また、すべてのアプリが同じDNS経路を使うわけではありません。アプリによっては独自のキャッシュや名前解決機能を使うため、検証時に分けて確認してください。
判断のポイント：まず現在の基準を保ち、次に通信方式を変更
システムDNSで対象サイトに安定してアクセスできる場合は、その結果を記録します。名前解決の問題が明確にある場合や、暗号化したDNS通信が必要な場合に限って、カスタムDNSまたはDoHを試してください。プロキシ、ルール、DNSを同時に変更しないようにしましょう。
ShadowrocketでDNSを設定する
以下では、iPhone / iPad版のHome、Config、Settingsを使って説明します。まずHomeで現在の接続を確認し、Configで有効な設定を確認してから、Settings → DNSで名前解決の設定を確認します。プラットフォームによって画面構成は異なるため、モバイル版の操作位置をそのまま当てはめないでください。
- Homeで現在の接続とGlobal Routingの選択内容を記録し、現在のConfigを複製して保存します。プロキシやサブスクリプションは利用中のサービス提供元から入手してください。この記事では関連サービスを提供・推奨していません。
- Settings → DNSで現在の設定を確認します。同時に、有効なConfigの
[General]にdns-serverがあるかも確認してください。一か所だけ変更して、実際の設定が変わったと判断しないようにしましょう。 - まずシステムDNSでアクセスをテストし、その後DNSの項目だけを変更します。DoHを使う場合は、DNSサービスが案内する完全なHTTPSエンドポイントを入力してください。サービスの紹介ページURLは入力しません。
- 保存後に接続を確立し直し、同じドメイン名にもう一度アクセスします。以前の結果が残る場合は、設定が反映されていないと判断する前に、キャッシュやアプリの既存接続を確認してください。
以下の2つのカードは項目の意味を確認するためのもので、実際に使えるDNSサービスではありません。例の192.0.2.53は文書用の予約アドレス、dns.example.comは例示用のホスト名です。利用する権限があり、接続可能だと確認できている値に置き換えてください。
従来型DNSの確認
- 設定画面
- Settings → DNS
- システム設定値
system- アドレスの例
192.0.2.53（形式の説明用）- 設定項目
[General]内のdns-server
IPアドレスを入力すると問い合わせ先は指定されますが、通信は暗号化されません。
DoHの確認
- プロトコル
https://- エンドポイントの例
https://dns.example.com/dns-query- パス
- 実際に利用するDNSサービスが指定するパス
- 証明書の要件
- 証明書が有効で、エンドポイントのホスト名と一致していること
DoHエンドポイントはサブスクリプションURLではありません。DNS設定にサブスクリプションの内容を入力しないでください。
ConfigファイルでDNSを管理する場合は、まず以下の最小限の設定でシステムDNSを基準にできます。これは設定ファイルの一部分であり、プロキシやルールの設定は含みません。既存ファイル全体を置き換える設定として使わないでください。リモートConfigの更新でファイル内容が変わることがあるため、更新後に該当項目を再確認してください。
[General]
dns-server = systemDNSとルールによる通信の振り分け
Global RoutingのProxy、Direct、Config、Sceneはそれぞれ異なるルーティングモードであり、DNSプロトコルの種類ではありません。ProxyとDirectは全体の通信先を選択します。Configは現在の設定内のルールに従い、Sceneは選択中のシーンの設定に従います。ルールを調べるときは、想定したモードになっているかを先に確認してください。Directでのアクセス結果だけを根拠に、プロキシルールが適用されたとは判断できません。
以下の設定例では、ドメインルール、IPルール、最終ルールの順に並べています。example.comと192.0.2.0/24は構文の例です。PROXYの振り分け先には、現在のConfigで利用できるプロキシポリシーが必要です。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIXはドメインの末尾に一致するルールです。例では指定したドメインとそのサブドメインが対象になります。このルールでリクエストのポリシーは決まりますが、DNSサーバーが指定されるわけではありません。IP-CIDRはIPアドレスの範囲に一致するルールです。例のno-resolveは、このルールのためにドメイン名の名前解決を新たに行わないことを示します。リクエストに接続先IPがすでに含まれていれば、IPアドレスによる判定は行われます。GEOIPはIPアドレスの割り当て情報に基づいて判定します。ページの内容で判定するものではありません。名前解決で得られるIPアドレスが変わると、このルールの判定結果も変わることがあります。FINALは、それ以前のルールに一致しなかったリクエストを処理します。ルールは上から順に評価されるため、範囲の広いルールを先に置くと、後続の細かなルールに一致しなくなる場合があります。
DoHの問い合わせにもサーバーへの接続が必要です。エンドポイントにドメイン名を使う場合、通常は最初にその名前解決が必要です。これを初期名前解決といいます。初期名前解決やエンドポイントへの接続に失敗すると、通常のWebサイトも名前解決待ちになることがあります。「エンドポイントへの接続にプロキシが必要」な一方で「プロキシ接続にはそのエンドポイントでの名前解決が必要」という循環依存を作らないようにしてください。
DNS設定の反映を確認する方法
確認するのは設定、DNS問い合わせ、通信経路の3つです。画面上で保存済みと表示されても、入力が受け付けられたことしか分かりません。Webサイトが開いても、利用可能な経路でアクセスできたことしか示しません。確実に判断するには、現在の設定、問い合わせ結果、実際の接続ログを照合します。一度ページが表示されたかどうかだけで判断しないでください。
- 条件を固定する。同じデバイス、同じWi-Fi、同じプロキシ、同じGlobal Routing、同じドメイン名を使い、DNSだけを変更します。変更前後で、名前解決のタイムアウト、接続タイムアウト、TLSエラーが発生するか記録します。
- 問い合わせを確認する。現在のプラットフォームで利用できるDNS問い合わせツールや接続ログで、対象ドメインのA / AAAAの結果を確認します。ツール側で別のDNSサーバーを指定した場合、確認できるのはそのサーバーだけです。Shadowrocketの現在の設定が反映された証明にはなりません。
- エンドポイントを確認する。DoHを使う場合は、エンドポイントのホスト名に対応する接続ログを探し、実際のポートを確認します。HTTPS接続が記録されても、DNSの応答が正常に返ったとは限りません。エラーログもあわせて確認してください。
- ルールを確認する。対象リクエストに適用されたルール、ポリシー、通信経路を確認します。名前解決は成功しても想定外のポリシーが適用されている場合は、DNSサーバーを交換し続けるのではなく、Configでルールの順序を見直してください。
- 再テストする。接続を確立し直し、アプリを再起動してから再度テストします。その後、モバイル通信に切り替えて別途テストしてください。ネットワーク切り替え後のテストは最初の比較と分け、ネットワークの違いをDNSの違いと混同しないようにします。
キャッシュは判断に大きく影響します。システム、ブラウザー、アプリ、DNSリゾルバーはいずれも結果をキャッシュすることがあり、既存の接続が再利用される場合もあります。ページがすぐに開いても、新しいDNS問い合わせが行われたとは限りません。DNSを変更した後も以前のIPアドレスが表示されるからといって、設定変更が失敗したとは限りません。設定を何度も切り替えるのではなく、ログの新しい問い合わせ時刻と接続時刻を照合してください。
判断のポイント：まず名前解決を確認し、次に通信経路を調べる
妥当なA / AAAAの結果が得られているのに、その後の接続がログ上でタイムアウトする場合は、接続先アドレスへの到達性、IPv6の経路、プロキシの通信経路を確認します。DNSの変更を定番の対処法として繰り返さないでください。
DNSのよくある質問と対処法
DoHを設定したらWebサイトがすべて開かなくなりました。まず何を戻せばよいですか？
まず変更前のシステムDNS設定に戻し、接続を確立し直してください。それですぐにアクセスが復旧する場合は、DoHの完全なURL、エンドポイントの初期名前解決、証明書、デバイスの時刻を順に確認します。エラーを回避するために証明書の検証を無効にしないでください。エンドポイントのパスが間違っている場合も、問い合わせに失敗することがあります。
自宅では使えるのに、会社の内部ドメインにアクセスできないのはなぜですか？
まず、そのドメインのDNSレコードが社内DNSでのみ提供されているかを確認してください。外部のDNSリゾルバーは通常、社内のレコードを知りません。そのネットワークで必要なシステムDNSに戻すか、管理者が確認したドメイン別のDNS設定を使います。社内ドメインをまとめて外部エンドポイントで試さないでください。
IPアドレスは名前解決できるのに、Webページの読み込みが終わりません。どうすればよいですか？
Homeで接続状態とGlobal Routingを確認し、Configで適用されたポリシーを確認します。AとAAAAの結果も個別に確認してください。IPv6の接続だけ失敗する場合は、IPv6の通信経路を調べます。名前解決の成功とIPアドレスへの接続可否は別の問題です。DNSの結果だけで通信経路の状態を判断しないでください。
DNSの確認ページに別のリゾルバーが表示されます。設定が反映されていないのでしょうか？
必ずしもそうとは限りません。確認結果にはDNSサービスの上流や出口が表示されることがあり、アプリが独自の名前解決を使う場合もあります。まずテスト時にShadowrocketが接続中だったかを確認し、現在のConfig、DNS問い合わせ、エンドポイントの接続ログを調べてください。表示された事業者名だけでDNSの通信経路を判断することはできません。
サブスクリプションの更新がタイムアウトします。まずDNSを変更すべきですか？
まず、サブスクリプションのドメイン名の名前解決に失敗したのか、HTTPS接続に失敗したのか、サービス提供元からエラーが返されたのかを切り分けます。サブスクリプションは利用中のサービス提供元から入手してください。リンク切れや利用権限の問題は、サービス提供元に確認します。ログで名前解決の失敗が明確に確認できた場合に限り、この記事のDNS比較手順を使ってください。
実際に使うネットワークで安定して名前解決でき、社内ネットワークへのアクセスやプライバシーの要件にも合う設定を選びます。通常利用に戻す前に、文書用の例示値を削除し、必要なOn Demandの条件を復元して、検証済みのConfigを保存してください。以後、ネットワークと設定を同時に変更する場合は、比較用の基準を改めて記録します。