はじめに
自宅ネットワークで独自のDNSサーバーを運用していると、「設定したはずのDNSサーバーが使われていない」という不可解な現象に遭遇することがあります。本記事では、その代表的な原因であるIPv6のDNS配布の仕組みと、あわせて知っておきたい暗号化DNS(DoH/DoT)、通信経路の見分け方をまとめます。
IPv6環境でDNS設定が「素通り」される現象
何が起きるか
ルーターのDHCP設定で「配布するDNSサーバー」を自前のDNSサーバーに変更したにもかかわらず、端末が相変わらず外部の(意図しない)DNSサーバーを使い続けてしまうことがあります。
原因：IPv6のルーターアドバタイズ(RA)
IPv4環境では、DHCPサーバーがIPアドレスと一緒にDNSサーバーの情報を配布するのが一般的です。一方IPv6環境では、RA(Router Advertisement、ルーターアドバタイズ)という仕組みの中で、DNSサーバー情報を配布するRDNSSオプションが定義されています(RFC 8106)。これにより、IPv6ホストはDHCPv6を使わなくても、ネットワーク設定とDNS情報を同時に取得できます。
自宅がIPoE系のIPv6接続(いわゆる「v6プラス」等)を使っている場合、ISP側のIPv6ネットワークが、ルーターを介してLAN内に直接DNSサーバー情報を配布していることがあります。多くのOSは、IPv4のDHCPで配布されたDNSサーバーよりも、こちらのIPv6経由のDNSサーバー情報を優先して使ってしまうことがあり、結果として「IPv4側でDNS設定を変更したのに反映されない」という現象が起こります。
見分け方
nslookupのようなコマンドを実行した際、サーバー欄が想定していたDNSサーバーのIPアドレスではなく、見慣れないIPv6アドレスになっている場合、この現象が疑われます。
対処法(OSごとの違いに注意)
| 環境 | 対処法 |
|---|---|
| Windows | ネットワークアダプターの設定で、IPv6のチェックを外して無効化する(比較的簡単) |
| iOS(iPhone) | 手軽な無効化トグルが存在しない。DNSサーバーを手動で固定する必要がある(設定→Wi-Fi→該当ネットワークの詳細→DNSを構成→手動) |
ルーター側でIPv6のDNS用ポート(UDP/TCP 53)をフィルタリングでブロックしても、「別の参照先に自動フォールバックする」保証はなく、根本解決にならない場合がある点にも注意が必要です。恒久的に複数端末で解消したい場合は、LAN内DNSの事情に依存しない経路(外部公開用のトンネル経由でアクセスする等)を検討するのも1つの手です。
DoH／DoTとは(暗号化DNS)
従来のDNS通信は暗号化されておらず、経路上の第三者に「どのドメインへアクセスしようとしているか」を読み取られる可能性がありました。これを解決するのが DoH(DNS over HTTPS) と DoT(DNS over TLS) という、DNS通信を暗号化する仕組みです。
| 方式 | 内容 |
|---|---|
| DoT(DNS over TLS) | DNS通信をTLSで暗号化し、専用のポート853を使う(RFC 7858) |
| DoH(DNS over HTTPS) | DNS通信をHTTPS化し、通常のWebトラフィックと同じポート443を使う |
両者の実質的な違いは、暗号化そのものよりも見分けやすさにあります。DoTは専用ポート(853)を使うため、通信の発生自体は外部から観測できます(中身は読めない)。一方DoHは、通常のHTTPS通信と同じポート443を使うため、DNSの問い合わせであること自体を他のHTTPS通信に紛れ込ませることができます。
自宅DNSサーバーのアップストリーム(上流の問い合わせ先)設定にDoH/DoT対応のリゾルバを指定しておくと、自宅から外部への名前解決の内容が経路上で読み取られるリスクを減らせます。
通信経路をレスポンスヘッダーで見分ける
同じドメイン名が、状況によって異なる経路(例：外部公開用のCDN経由、あるいは宅内のリバースプロキシ経由)でアクセスできてしまう構成では、「今どちらの経路でアクセスしているか」が見た目だけでは分かりにくいことがあります。
こうした場合、ブラウザの開発者ツール(F12) → Networkタブでレスポンスヘッダーを確認すると、経路を判別できることがあります。たとえばCloudflareを経由した通信にはcf-rayというヘッダーが付与されます。
-
cf-rayヘッダーが含まれている → Cloudflareのネットワークを経由している -
cf-rayヘッダーが含まれていない → Cloudflareを経由せず、別の経路(宅内プロキシ等)でアクセスしている
cf-rayの値は「一意なリクエストID」と「処理したデータセンターを示す空港コード」がハイフンで区切られた形式になっており、本来はCloudflareのサポートに問い合わせる際の識別子として使うものですが、副次的に「その通信がCloudflareを経由したかどうか」を判定する目印としても利用できます。
まとめ
| 現象・技術 | 内容 | 対処・活用法 |
|---|---|---|
| IPv6のDNS素通り | IPv6のRA(RDNSSオプション)が配布するDNS情報が、IPv4のDHCP設定より優先される | Windows: IPv6無効化。iOS: DNSサーバーの手動固定 |
| DoT | DNS通信をTLSで暗号化(専用ポート853) | 通信の暗号化。ポート番号で識別可能 |
| DoH | DNS通信をHTTPSで暗号化(ポート443) | 通信の暗号化。他のHTTPS通信に紛れ込む |
cf-rayヘッダー |
Cloudflareを経由したリクエストに付与される識別子 | レスポンスヘッダーを見て通信経路を判別する目印にできる |
