コンテンツにスキップ
Router.Homes

DNSを設定し、ルーター・クライアント・ブラウザーで確認する

目的

Section titled “目的”

次の3点を個別に確認できるようになります。

  • ルーターはどの上流DNSサーバーを使っているか
  • クライアントはOpenWrtからどのDNSサーバーを受け取っているか
  • ブラウザーがDoHでシステムのリゾルバーを迂回していないか

設定変更に失敗しても、名前解決できる状態に戻せます。

対象環境

Section titled “対象環境”
  • OpenWrt 25.12.6、既定の dnsmasq と odhcpd。25.12は apk、24.10は opkg を使います。
  • 確認コマンドに追加パッケージは不要です。unbound や https-dns-proxy を使っている場合は、先にどちらがポート53を使っているか確認してください。
  • 24.10でもメニュー名と設定キーはほぼ同じですが、パッケージ関連のコマンドは異なります。apk のコマンドを24.10にそのまま使わないでください。

DNSの経路と担当

Section titled “DNSの経路と担当”
場所 既定の担当 確認すること
WAN上流 DHCP/PPPoEクライアント cat /tmp/resolv.conf.d/resolv.conf.auto
ルーターのリゾルバー dnsmasq nslookup openwrt.org 127.0.0.1
LANへの通知 dnsmasq のDHCPオプション6、odhcpd のRDNSS クライアントに表示されるDNS
ブラウザー システムのリゾルバー、またはブラウザーのDoH ブラウザーのセキュアDNS設定

DNSサーバーを置き換える前に、どの層に問題があるかを切り分けます。

変更前の準備

Section titled “変更前の準備”
ルーターのシェルDHCP/DNS設定をバックアップする
ターミナルウィンドウ
cp /etc/config/dhcp /etc/config/dhcp.bak.$(date +%F)
uci export dhcp > /tmp/dhcp.before
uci show dhcp | grep -E 'dns|resolv|server|option'

LuCIとSSHには有線LANで接続できる状態を保ってください。変更中のDNSに、唯一の管理経路を依存させないでください。

期待される結果バックアップがあり、復元方法がわかっている。

最小手順

Section titled “最小手順”
ルーターのシェル上流DNSとdnsmasqの設定を確認する
ターミナルウィンドウ
cat /tmp/resolv.conf.d/resolv.conf.auto
uci show dhcp.@dnsmasq[0]
uci show network.wan | grep -E 'peerdns|dns'

/tmp/resolv.conf.d/resolv.conf.auto はWANクライアントが書き込みます。実際の dhcp.@dnsmasq[0].resolvfile の値を確認してください。noresolv='1' の場合、dnsmasqはこのファイルを無視し、server のリストを使います。

期待される結果現在のresolvfile、server、noresolvの値を説明できる。

LuCIWANにカスタムDNSを設定する（最も安全な最初の変更）

ネットワーク → インターフェース → WAN → 詳細設定 を開きます。

  1. 「ピアにより通知されたDNSサーバーを使用」のチェックを外します（peerdns が0になります）。
  2. 「カスタムDNSサーバーを使用」に、信頼できるDNSサーバーを追加します。例: 1.1.1.1、9.9.9.9
  3. 保存して適用し、必要ならWANを再接続します。

WANが一時的に途切れますが、LANのDHCP/DNS構成は変わらないため、元に戻しやすい方法です。

期待される結果WANを再接続すると、上流リゾルバーが設定した値になる。

ルーターのシェルdnsmasqが待ち受けており、新しい上流を読み込んだか確認する
ターミナルウィンドウ
netstat -lnp | grep ':53'
/etc/init.d/dnsmasq restart
logread -e dnsmasq | tail -20

dnsmasq が起動しない場合は、DHCPオプションの変更を止めてください。エラーメッセージから、構文エラーかポートの競合かを調べます。

期待される結果ポート53が待ち受け状態で、ログに設定エラーがない。

LuCIクライアントに通知されるDNSを確認する

ネットワーク → DHCPおよびDNS → DHCPサーバー → 詳細設定 を開き、「DHCPオプション」を確認します。オプション6がなければ、クライアントは通常ルーターのLANアドレスをDNSとして使います。オプション6があれば、そのアドレスを直接受け取ります。

ポート53で待ち受けていないアドレスを、クライアントのDNSに指定しないでください。

期待される結果クライアントがOpenWrtのLANアドレス、または意図したオプション6のアドレスを受け取る。

ルーターのシェルCLIでの同等の手順（任意）
ターミナルウィンドウ
uci set network.wan.peerdns='0'
uci -q delete network.wan.dns
uci add_list network.wan.dns='1.1.1.1'
uci commit network
ifup wan
cat /tmp/resolv.conf.d/resolv.conf.auto

変更後は logread -e dnsmasq で新しい上流を確認します。クライアントが古いDNSを受け取り続ける場合は、dnsmasqを再起動するか、DHCPオプション6を確認してください。

期待される結果resolv.autoに1.1.1.1が表示され、問い合わせが成功する。

クライアントからの確認

Section titled “クライアントからの確認”
ルーターのシェルルーター上でAとAAAAを確認する
ターミナルウィンドウ
nslookup openwrt.org 127.0.0.1
nslookup -type=AAAA openwrt.org 127.0.0.1

期待される結果どちらの問い合わせもタイムアウトせず応答が返る。

パソコンクライアントが実際に受け取ったDNSを確認する

Linux:

ターミナルウィンドウ
resolvectl status
cat /etc/resolv.conf
nslookup openwrt.org

Windows:

ターミナルウィンドウ
ipconfig /all
nslookup openwrt.org

macOS:

ターミナルウィンドウ
scutil --dns
nslookup openwrt.org

期待される結果クライアントのDNSがDHCPまたは静的設定と一致し、名前解決できる。

パソコンブラウザーがルーターを迂回していないか確認する

Chrome/Edge: chrome://settings/security、または「プライバシーとセキュリティ → セキュリティ → セキュアDNSを使用する」。Firefox: 設定 → プライバシーとセキュリティ → DNS over HTTPS。DoHがオンだとシステムのリゾルバーがまったく使われないことがあり、「ルーターのDNS設定が効かない」ように見えます。

期待される結果テスト中はDoHがオフ、または向き先を正確に把握している。

パソコンIPv6の名前解決とRA/RDNSSを確認する
ターミナルウィンドウ
nslookup -type=AAAA openwrt.org
ip -6 route

上流にIPv6プレフィックスがない場合、IPv4の結果からIPv6のDNSが正常だと判断しないでください。

期待される結果IPv6の上流があればAAAAが解決できる。なければ不足している条件を記録する。

失敗時の分岐と復旧

Section titled “失敗時の分岐と復旧”

ページは開かないが、IPアドレスへのpingは通る

Section titled “ページは開かないが、IPアドレスへのpingは通る”

まずDNSを疑います。

  1. クライアントのリゾルバーを確認します: resolvectl status、ipconfig /all、scutil --dns
  2. ルーターでポート53とdnsmasqのログを確認します: netstat -lnp | grep ':53'、logread -e dnsmasq
  3. ブラウザーのDoHを確認し、一時的に無効にします。
  4. DHCPオプション6に誤ったアドレスがないか確認します。

LuCI/SSHにつながらない

Section titled “LuCI/SSHにつながらない”

DNSの変更を止めます。有線のクライアントをLANに接続し、同じサブネットの静的アドレスを設定して、ゲートウェイがOpenWrtのLANアドレスであることを確認します。コンソールまたはSSHから復元します。

ターミナルウィンドウ
cp /etc/config/dhcp.bak.YYYY-MM-DD /etc/config/dhcp
uci commit dhcp
/etc/init.d/dnsmasq restart

WANのDNSを変更した場合は、上流DNSの自動取得に戻します。

ターミナルウィンドウ
uci set network.wan.peerdns='1'
uci -q delete network.wan.dns
uci commit network
ifup wan

WANのDNSを変えたのにクライアントが古いリゾルバーを使う

Section titled “WANのDNSを変えたのにクライアントが古いリゾルバーを使う”

resolv.auto が変わったか、次にdnsmasqが新しい上流を読み込んだかを確認します。

ターミナルウィンドウ
cat /tmp/resolv.conf.d/resolv.conf.auto
logread -e dnsmasq | tail -20
/etc/init.d/dnsmasq restart

resolv.auto が変わっていなければ、network.wan.dns と peerdns を確認します。クライアントが古いDNSを受け取り続ける場合は、DHCPオプション6とブラウザーのDoHを確認してください。

dnsmasqが起動しない

Section titled “dnsmasqが起動しない”

何度も再起動せず、エラーを読みます。

ターミナルウィンドウ
logread -e dnsmasq | tail -50
dnsmasq --test

よくある原因は、別のリゾルバーによるポート53の占有、構文エラー、到達できない上流です。まずバックアップを復元し、カスタム設定は1つずつ戻してください。

E2ラボ検証（2026-10-20）

Section titled “E2ラボ検証（2026-10-20）”
  • 環境: PVE 9.2.2 シングルNIC、OpenWrt 25.12.6 VM 200。WAN 192.168.50.77/24、LAN 192.168.1.1/24
  • ベースライン: resolv.auto は nameserver 192.168.50.1。nslookup openwrt.org 127.0.0.1 はA/AAAAを返した。
  • カスタム: peerdns=0 と network.wan.dns=1.1.1.1。resolv.auto は nameserver 1.1.1.1 に変わり、問い合わせは成功した。
  • 障害: dnsmasqの上流を到達不能な 192.0.2.1 に設定すると、ランダムな .example.com の問い合わせは connection timed out; no servers could be reached を返した。noresolv/server を削除して peerdns=1 に戻すと名前解決が復旧した。
  • クライアント: netnsのDHCPで 192.168.1.116/24、DNS 192.168.1.1 を取得。dig @192.168.1.1 openwrt.org は成功し、ping 192.168.50.1 も通った。
  • 未検証: ブラウザーのDoH、IPv6の上流/RA/RDNSS、物理LANクライアント、長期の安定性

出典とレビュー

Section titled “出典とレビュー”
  • このページにはE2のラボ再現があります。ブラウザーのDoHとIPv6の上流は未検証のため、検証済みとは記述しないでください。
  • 根拠: docs/dns-e2-run.md と tests/recipes/dns-25.12-x86.md
  • メニューやバージョンが変わったら testedVersions と lastVerifiedAt を更新してください。25.12の手順に24.10の opkg コマンドを入れないでください。

出典

Router.Homes

独立した OpenWrt の実践ノートです。各ページにファームウェア、デバイス、パッケージマネージャー、元に戻す手順を明記しています。

アイコン：Solar by 480 Design, CC BY 4.0