2026年6月10日
CoreDNS は、Corefile に reload プラグインを書いておけば設定の変更を自動で読み込むため、再起動が要らない場面が多くあります。再起動が必要になるのは、reload を使っていない場合、バイナリを更新した場合、プロセスが応答しなくなった場合などです。この記事では、再起動が要るかどうかの見分け方、systemd・Docker・Kubernetes それぞれでの再起動の手順、再起動の前後に確認すること、起動しないときの原因の調べ方を説明します。
再起動が要る変更と要らない変更
CoreDNS の変更は、次の3つに分けて考えると判断しやすくなります。
- ゾーンファイルや hosts ファイルの変更：
fileプラグインのゾーンファイルは、プラグイン自身がファイルの変更を定期的に確認して読み込み直します（reloadオプションで間隔を指定でき、既定は1分程度）。hostsプラグインのファイルも同様に自動で読み込まれます。どちらも再起動は不要です。ゾーンファイルは SOA のシリアル番号を増やさないと読み込み直されないことがあるため、編集時はシリアル番号も更新します。 - Corefile の変更：
reloadプラグインがあれば、Corefile の内容が変わったことを検知して読み込み直します。確認の間隔は既定で30秒程度で、複数台が同時に読み込まないようにばらつきが加えられます。reload がない場合は、再起動するかシグナルで読み込み直す必要があります。 - バイナリの更新や、プロセスの異常：CoreDNS のバージョンを上げたとき、独自ビルドのプラグイン構成を変えたとき、プロセスが応答しなくなったときは再起動が必要です。
Corefile を手作業で変えることが多い環境では、reload を書いておくと再起動の回数を減らせます。Kubernetes の多くのディストリビューションでは、既定の Corefile に reload が含まれています。
reload で読み込み直すときの注意
reload は、新しい Corefile に誤りがあると読み込みをやめ、古い設定のまま動き続けます。エラーはログに出るだけなので、ログを見ずに「反映されたはず」と判断すると、変更が効いていないことに気づけません。
# systemd で動かしている場合
sudo journalctl -u coredns -n 50 --no-pager
# 読み込みが成功すると、新しい設定のハッシュ値がログに出る
# 例: [INFO] Reloading completeログの文言はバージョンによって異なることがあるため、手元の環境で一度、正常に読み込んだときのログを確かめておくと、失敗したときとの違いが分かりやすくなります（2026年10月現在）。
reload を使っていない場合でも、プロセスに SIGUSR1 を送ると Corefile を読み込み直します。sudo kill -USR1 $(pidof coredns) のように使えますが、systemd の管理下では systemctl reload から送れるよう、ユニットファイルに ExecReload=/bin/kill -USR1 $MAINPID を書いておくと扱いやすくなります。
再起動の前に確認すること
CoreDNS には、設定ファイルの文法だけを検査する専用のコマンドが用意されていません。本番の設定を変えて再起動する前に、次のように別のポートで新しい Corefile を試すと、起動できるかどうかを事前に確かめられます。
# 新しい Corefile をコピーし、待ち受けポートを 1053 番に変えたものを用意する
cp /etc/coredns/Corefile /tmp/Corefile.test
sed -i 's/:53 {/:1053 {/' /tmp/Corefile.test
# フォアグラウンドで起動し、エラーが出ないかを見る（Ctrl+C で止める）
coredns -conf /tmp/Corefile.test
# 別の端末から問い合わせる
dig @127.0.0.1 -p 1053 www.example.comsed の置き換えは、Corefile の書き方によっては当てはまらないことがあります。置き換えた後のファイルを目で確認してください。bind プラグインで特定のアドレスを指定している場合や、prometheus などで別のポートを使っている場合は、本番のプロセスとポートが重ならないよう、それらも変えます。
あわせて、再起動の前に次のことも確認しておきます。
- 同じ CoreDNS を使う利用者：1台だけで動かしている場合、再起動の間は名前解決ができません。端末側のキャッシュである程度は隠れますが、利用の少ない時間帯を選びます。
- 設定のバックアップ：Corefile とゾーンファイルをコピーしておき、問題が起きたらすぐ戻せるようにします。
systemd で動かしている場合
CoreDNS を単体のバイナリとして入れ、自分で作ったユニットファイルで動かしている環境の手順です。ユニット名は環境によって異なるため、systemctl list-units | grep -i coredns で確認してください。
sudo systemctl restart coredns
sudo systemctl status coredns複数台で冗長化している場合は、1台ずつ再起動し、1台目が正常に答えることを確かめてから次に進みます。端末の DNS サーバーの設定に複数台が登録されていれば、再起動中の1台に届かなかった問い合わせは、もう1台に送られます。
Docker で動かしている場合
docker restart coredns
docker logs --tail 50 corednsコンテナ名は docker ps で確認してください。Corefile をボリュームでマウントしている場合、エディターによってはファイルを置き換える形で保存するため、コンテナからは古いファイルが見え続けることがあります。ファイル単位ではなく、ディレクトリ単位でマウントしておくと、この問題を避けられます。
Kubernetes で動かしている場合
クラスター DNS の CoreDNS は、Deployment をローリング再起動します。Pod が1つずつ入れ替わるため、レプリカが2つ以上あれば、名前解決が止まらないまま再起動できます。
# Deployment の名前を確認する（多くの環境で coredns）
kubectl -n kube-system get deployment
# ローリング再起動と、完了の確認
kubectl -n kube-system rollout restart deployment coredns
kubectl -n kube-system rollout status deployment corednsConfigMap で Corefile を変えた場合、reload が含まれていれば再起動は不要です。ただし、ConfigMap の変更が Pod に届くまでに時間がかかるため、すぐに反映されないことがあります。急ぐ場合や、反映されたかどうかが分かりにくい場合は、ローリング再起動を使います。
マネージド Kubernetes では、CoreDNS がアドオンとして管理されていることがあります。設定の変え方や再起動の方法が独自に決められている場合があるため、各サービスのドキュメントを確認してください。
再起動後に確認すること
再起動の後は、次の順に確認します。
# 1. 名前解決ができるか
dig @127.0.0.1 www.example.com
# 2. health プラグインを有効にしている場合（既定は 8080番）
curl -s http://127.0.0.1:8080/health
# 3. ready プラグインを有効にしている場合（既定は 8181番。準備ができると 200 を返す）
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8181/readyKubernetes では、クラスター内の確認用 Pod から kubernetes.default.svc.cluster.local と外部の名前の両方を引き、どちらも答えが返ることを確かめます。
起動しないときの原因と確認
1. Corefile の誤り
ログに、問題のある行や未知のプラグイン名が出ます。プラグイン名の綴りや、波かっこの閉じ忘れを確認します。独自にビルドした CoreDNS では、使おうとしたプラグインが組み込まれていないこともあるため、coredns -plugins で一覧を確認します。
2. 53番ポートが使われている
address already in use のようなエラーが出る場合は、sudo ss -lunpt | grep ':53 ' で、53番を使っているプロセスを確認します。Ubuntu などでは systemd-resolved が 127.0.0.53 で待ち受けているため、CoreDNS を bind で特定のアドレスに限るか、systemd-resolved のスタブの待ち受けを止めます。
3. 53番ポートで待ち受ける権限がない
root 以外のユーザーで動かしている場合、1024番より小さいポートで待ち受けるには権限が必要です。systemd のユニットファイルに AmbientCapabilities=CAP_NET_BIND_SERVICE を書くのが一般的な方法です。
4. loop プラグインが転送の循環を検知した
loop プラグインは、転送先が自分自身に戻ってくる構成を検知すると、CoreDNS を停止させます。Kubernetes では Pod が再起動を繰り返す状態になります。ノードの /etc/resolv.conf が 127.0.0.53 などのローカルのアドレスを指し、forward . /etc/resolv.conf で自分に問い合わせが戻ってくるのがよくある原因です。kubelet に実際の上流を書いた resolv.conf を渡すか、forward の転送先を上流の DNS サーバーのアドレスに直接書き換えます。
まとめ
- ゾーンファイルや hosts ファイルの変更は自動で読み込まれ、Corefile の変更も reload があれば再起動は不要です。
- reload は誤りがあると古い設定のまま動くため、変更後は毎回ログを確認します。
- 本番の再起動の前に、別のポートで新しい Corefile を起動して試します。
- systemd・Docker・Kubernetes それぞれの方法で再起動し、名前解決と health・ready で確認します。
- 起動しないときは、Corefile の誤り、ポートの競合、権限、転送の循環の順に確認します。