Unbound を再起動するコマンドは、systemd を使う Linux なら sudo systemctl restart unbound です。ただし設定を読み直すだけなら、プロセスを止めずに済む unbound-control reload のほうが影響は小さく、どちらの場合も先に unbound-checkconf で設定を検査しておくと「再起動したら起動しなくなった」を防げます。この記事では、再起動と再読み込みの違い、安全な手順、再起動後の確認、起動しないときの原因の調べ方を順に説明します。
再起動と再読み込みの違い
Unbound の「再起動」には、実際には影響の大きさが違う3つの操作があります。目的に合わせて選ぶと、利用者への影響を小さくできます。
- **プロセスの再起動（
systemctl restart unbound）**：Unbound を止めてから起動し直します。停止から起動までの間は名前解決ができず、キャッシュも空になります。待ち受けアドレスやポート、chroot、usernameなど、起動時にしか反映されない設定を変えたときに使います。 - **設定の再読み込み（
unbound-control reload）**：プロセスは動かしたまま設定ファイルを読み直します。ただしキャッシュはこのとき捨てられるので、直後は外部への問い合わせが増え、応答が一時的に遅くなります。 - **キャッシュを残した再読み込み（
unbound-control reload_keep_cache）**：比較的新しい版の Unbound に追加されたコマンドで、設定を読み直しつつ、可能な範囲でキャッシュを残します。手元の版で使えるかはunbound-control -hの一覧で確認してください（2026年10月現在、古い LTS ディストリビューションの標準パッケージでは使えないことがあります）。
設定を変えていないのに「名前解決がおかしいので再起動したい」という場合は、再起動よりもキャッシュの削除のほうが目的に合っていることがほとんどです。特定のドメインだけなら unbound-control flush_zone example.com、1つの名前なら unbound-control flush www.example.com で済み、ほかの利用者のキャッシュは残ります。
再起動の前に設定を検査する
Unbound は設定ファイルに1か所でも文法の誤りがあると起動しません。稼働中のプロセスを止めた後に起動に失敗すると、そのサーバーを使っているすべての端末で名前解決が止まります。再起動や再読み込みの前に、次のコマンドで設定を検査します。
# 設定ファイルの文法と参照先ファイルを検査する
sudo unbound-checkconf
# 設定ファイルの場所が既定と違う場合は明示する
sudo unbound-checkconf /etc/unbound/unbound.conf問題がなければ no errors in /etc/unbound/unbound.conf のように表示されます。エラーのときはファイル名と行番号が出るので、その行を直してから再度検査します。include: で分割した設定ファイル（Debian・Ubuntu 系の /etc/unbound/unbound.conf.d/ など）も検査の対象になります。
設定を変える前には、元のファイルをコピーしておきます。起動しなくなったときに、すぐに元へ戻せます。
sudo cp -a /etc/unbound/unbound.conf /etc/unbound/unbound.conf.bak-$(date +%Y%m%d)再起動の手順
systemd の環境（多くの Linux）
sudo unbound-checkconf && sudo systemctl restart unbound
sudo systemctl status unbound --no-pager&& でつないでおくと、検査に失敗したときは再起動が実行されません。systemctl reload unbound も使えますが、何が実行されるかはユニットファイルの ExecReload 次第です。systemctl cat unbound で中身を見てから使ってください。
FreeBSD
FreeBSD では、OS に同梱されている Unbound と ports・パッケージで入れた Unbound でサービス名が違います。同梱版は service local_unbound restart、パッケージ版は service unbound restart です。どちらを使っているかは /etc/rc.conf の有効化の行で分かります。
unbound-control を使うための準備
unbound-control は、設定で remote-control が有効になっていないと「接続できない」というエラーになります。ディストリビューションによっては最初から有効ですが、無効なら次のように設定し、証明書を作ってから Unbound を再起動します。
remote-control:
control-enable: yes
control-interface: 127.0.0.1# unbound-control 用の鍵と証明書を作る（初回のみ）
sudo unbound-control-setup
sudo systemctl restart unbound
sudo unbound-control statuscontrol-interface は外部に公開しないよう、ループバックアドレスか UNIX ソケットにします。
再起動後に確認すること
起動したように見えても、待ち受けや名前解決が正しく動いているとは限りません。次の順で確認します。
# 1. プロセスの状態と直近のログ
sudo systemctl status unbound --no-pager
sudo journalctl -u unbound -n 50 --no-pager
# 2. 53番ポートで待ち受けているか
sudo ss -lunp | grep ':53 '
sudo ss -ltnp | grep ':53 '
# 3. 実際に名前解決できるか（サーバー自身から）
dig @127.0.0.1 example.com A
# 4. DNSSEC 検証が働いているか（flags に ad が付くか）
dig @127.0.0.1 example.com A +dnssec3 で status: NOERROR と回答が返り、4 で flags に ad が付けば、名前解決と DNSSEC 検証の両方が動いています。別の端末からも dig @サーバーのIP example.com を試し、REFUSED が返る場合は access-control: でその端末のネットワークが許可されているかを確認します。
再起動直後はキャッシュが空のため、最初の問い合わせは普段より遅くなります。数分たっても遅いままなら、上流への通信（ファイアウォールの UDP・TCP 53番、forward-zone の転送先）を疑います。
再起動しても起動しないときの原因と確認
起動に失敗したときは、まず journalctl -u unbound -n 50 のエラー行を読みます。よくある原因を、起きやすい順に並べます。
1. 設定ファイルの誤り
error: ... syntax error や unknown keyword が出ていれば設定の誤りです。unbound-checkconf で行番号を確認し、直すか、控えておいたファイルに戻します。インデントの崩れや、server: などの節の外に設定を書いてしまったことが原因になりやすい箇所です。
2. 53番ポートがほかのプロセスに使われている
could not open port 53 や Address already in use が出る場合は、ほかのプロセスが53番を使っています。Ubuntu などでは systemd-resolved が 127.0.0.53 で待ち受けているため、Unbound を interface: 0.0.0.0 で動かすとぶつかることがあります。
sudo ss -lunp | grep ':53 'で使用中のプロセスを確認し、Unbound の interface: を特定のアドレスにするか、systemd-resolved の設定で DNSStubListener=no にして待ち受けを止めます。後者はサーバー自身の名前解決の向き先も変わるので、/etc/resolv.conf の内容も合わせて見直します。dnsmasq など別の DNS ソフトが残っている場合も同じ症状になります。
3. 待ち受けるアドレスがまだ存在しない
OS の起動直後に Unbound が先に起動し、interface: に書いたアドレスがまだ付いていないと can't bind socket で失敗します。手動で再起動すると成功するのが特徴です。server: に ip-freebind: yes を加えると、アドレスが付く前でも待ち受けを始められます。
4. トラストアンカーや鍵ファイルの権限
auto-trust-anchor-file: で指定したファイル（例：root.key）を Unbound の実行ユーザーが読み書きできないと、起動に失敗したり DNSSEC 検証で SERVFAIL が続いたりします。ファイルの所有者と権限を確認し、必要なら unbound-anchor でファイルを作り直します。remote-control 用の鍵ファイルの権限も同様です。
5. chroot の中にファイルがない
chroot: を使っている構成では、設定で指定したファイルが chroot の中にないと読めません。ログファイルやゾーンファイルを chroot の外に置いていないかを確認します。
利用者への影響を抑える再起動のしかた
社内やサーバー群の名前解決を1台の Unbound で担っている場合、再起動の数秒間でもアプリケーションのエラーにつながることがあります。可能なら Unbound を2台用意し、クライアントの /etc/resolv.conf に両方を書いておき、1台ずつ再起動します。1台目を再起動して確認が済んでから2台目に進めば、名前解決が途切れません。
作業は利用の少ない時間帯に行い、本番の前に検証環境で同じ設定変更と再起動を試しておくと、起動しない事態を事前に見つけられます。
まとめ
- 再起動は
systemctl restart unbound、設定を読み直すだけならunbound-control reloadが使えます。どちらもキャッシュは消えるため、キャッシュを残したいときは版によって使えるreload_keep_cacheを確認します。 - 名前解決の不具合が理由なら、再起動より
flushやflush_zoneでのキャッシュ削除のほうが影響を小さくできます。 - 再起動の前に
unbound-checkconfで設定を検査し、元の設定ファイルを控えておきます。 - 再起動後は
systemctl status・ss・digで待ち受けと名前解決、DNSSEC 検証を確認します。 - 起動しないときは、設定の誤り、53番ポートの競合、アドレス未設定、ファイルの権限、chroot の順に確認します。