なぜDNS設定は個別に注目する価値があるのか

DNS関連の問題は通常2つの形で現れます:DNS汚染(ドメインの解決結果が改ざんされ、アクセス異常や誤ったページへのリダイレクトが発生する)とDNS漏洩(プロキシは有効になっているが、DNSリクエストが依然としてローカルのISPで解決されており、プロキシを経由していないため、実際にアクセスしようとしている内容が露見してしまう)です。解決方法は異なりますが、いずれもdnsセクションを適切に設定することで解決できます。

Fake-IPモード:不要な往復を省く

標準的なDNS解決の流れは:アプリがドメインをリクエスト → DNSサーバーが実際のIPを解決 → 接続を開始、というものです。このプロセスには余分なネットワーク往復が発生し、DNSサーバー自体が信頼できない場合は汚染される可能性もあります。

Fake-IPモードの動作は:解決リクエストが発生した時点で、まず予約アドレス範囲に属する「偽IP」を返し、クライアントはこの偽IPがどのドメインに対応するかを記憶します。実際に接続を開始する段階になってから、必要に応じて本当の解決を行うか、直接プロキシ経由で転送します。この効果により、ほとんどのシーンで往復の問い合わせが不要になり、また大部分のトラフィックは最終的にプロキシ経由と判断されるため、プロキシノード側で解決されるIPは汚染されにくくなります。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "time.*.com"
    - "dns.msftncsi.com"

fake-ip-filter:どのドメインを除外すべきか

Fake-IPはほとんどのシーンで問題ありませんが、いくつかのドメインは必ず除外する必要があります。そうしないと「デバイス同士が発見できない」「ゲームアクセラレーターが機能しない」「内部ネットワークサービスへのアクセスが異常」といった状況が発生します:

ほとんどの主要クライアントには、デフォルトで比較的完全な除外リストが事前に用意されているため、通常はゼロから自分で書く必要はありません。特定のLANサービスに接続できない場合は、そのドメインをfake-ip-filterに追加すれば通常は解決します。

DoH / DoT:DNSクエリ自体を暗号化する

Fake-IPが解決するのは「実際に解決を行うかどうか」の問題であり、DoH(DNS over HTTPS)/ DoT(DNS over TLS)が解決するのは「解決プロセス自体が傍受・改ざんされないか」という問題です——本来平文だったDNSリクエストを暗号化チャネルにカプセル化して送信することで、ISPや中間ノードはあなたがどのドメインを問い合わせているか見ることができず、返された結果を改ざんすることもできなくなります。

dns:
  enable: true
  nameserver:
    - "https://doh.pub/dns-query"
    - "https://dns.alidns.com/dns-query"
  fallback:
    - "https://1.1.1.1/dns-query"
    - "https://8.8.8.8/dns-query"

nameserverはデフォルトの解決アップストリームで、fallbackは中国本土の解決結果が理想的でない場合のバックアップアップストリームです。クライアントは解決結果に基づいてfallbackに切り替える必要があるかを自動的に判断します。

振り分け解決:中国本土と海外のドメインで異なるアップストリームを使う

さらに進んだ方法として、nameserver-policyを使って中国本土のドメインには中国本土のDNSを、海外のドメインには海外の暗号化DNSを指定し、解決速度と耐汚染性を両立させます:

dns:
  nameserver-policy:
    "geosite:cn":
      - "https://doh.pub/dns-query"
    "geosite:geolocation-!cn":
      - "https://1.1.1.1/dns-query"

これにより、中国本土のサイトはローカル回線での解決が速くなり、海外のサイトは暗号化アップストリームでの解決がより安全になり、両者は互いに影響しません。

自分がDNSの問題に遭遇しているかどうかの見分け方

プロキシがすでに正常な接続を示している(出口IPが既に切り替わっている)にもかかわらず、特定のサイトの読み込みが異常に遅い、またはコンテンツが表示されるべきでないページにリダイレクトされる場合、大抵はプロキシ回線の問題ではなくDNSレベルの問題です。クライアントの「接続 / Connections」パネルで具体的にどのドメインの解決が異常かを観察し、上記の設定と照らし合わせて一つずつ確認できます。内部ネットワークのデバイスに接続できない場合は、まずfake-ip-filterに該当ドメインが漏れていないか確認してください。

最後に

DNS設定は「一度設定すればあとはそのまま」というタイプのものであり、ほとんどのサブスクリプション提供者のデフォルト設定は日常使用には十分です。実際に手を加える必要があるのは、通常は内部ネットワークデバイスへのアクセス異常や、DNSプライバシーへのより高い要求がある場合で、上記の考え方に沿って該当するフィールドを調整すれば十分です。