2026年6月11日

dnsmasq を監視する手順｜プロセス・応答・キャッシュ統計・上流サーバー・DHCP リースを見張る

DNS・名前解決

dnsmasq の監視は「プロセスが動いているか」だけでは足りません。プロセスは生きていても、上流のDNSサーバーに届かずに名前解決が失敗している、同時問い合わせの上限に達して応答が遅れている、DHCP の割り当て範囲が尽きている、といった止まり方があるためです。この記事では、dnsmasq を監視するときに見るべき項目と、それぞれをコマンドで確認する方法、監視ツールへの組み込み方を説明します。

dnsmasq の統計の出し方やログの文言は版によって細部が異なります（2026年10月現在）。以下の出力例は目安として読み、手元の版の man ページ（man dnsmasq）と照らし合わせてください。

監視する項目を決める

dnsmasq の障害は、おおむね次の5つの層に分けられます。上から順に、止まったときの影響が大きいものです。

プロセス：dnsmasq が起動しているか。
応答：実際にDNSの問い合わせに正しく答えるか。ローカルに定義した名前と、外部の名前の両方を見ます。
上流サーバー：転送先のDNSサーバーへの問い合わせが失敗していないか。
キャッシュと同時問い合わせ数：キャッシュが小さすぎて追い出しが多発していないか、同時に処理できる問い合わせ数の上限に達していないか。
DHCP（使っている場合）：割り当て範囲に空きがあるか。

監視の基本は 2 の「応答」です。プロセス監視だけだと、設定ミスで全く答えていない状態を見逃します。逆に応答監視だけでも原因の切り分けに時間がかかるため、複数の層を組み合わせます。

プロセスを監視する

systemd で動かしている場合は、サービスの状態を確認します。

systemctl is-active dnsmasq
systemctl status dnsmasq --no-pager
journalctl -u dnsmasq --since "1 hour ago" --no-pager

ここで注意したいのが、pgrep dnsmasq や ps でのプロセス数の監視です。NetworkManager や libvirt は、それぞれ独自の dnsmasq を起動することがあります。プロセス名だけで監視すると、本来見たい dnsmasq が止まっていても、ほかの dnsmasq が動いているせいで「正常」と判断してしまいます。systemd のユニット名か、PID ファイルで対象を特定します。

落ちたときに自動で起動し直したい場合は、ユニットを直接書き換えず、systemctl edit dnsmasq でドロップインを作ります。

[Service]
Restart=on-failure
RestartSec=5s

ただし、自動で再起動すると障害が目立たなくなります。再起動の回数（systemctl show dnsmasq -p NRestarts）も監視の対象にして、頻繁に落ちていることに気づけるようにします。

応答を監視する

応答の監視には dig を使います。ローカルに定義した名前（/etc/hosts や address= で返している名前）と、外部の名前を1つずつ問い合わせると、「dnsmasq 自体の故障」と「上流への転送の故障」を区別できます。

#!/bin/sh
# dnsmasq の応答確認。0=正常、2=異常（Nagios 形式の終了コード）
SERVER=127.0.0.1
LOCAL_NAME=nas.home.arpa
EXTERNAL_NAME=example.com

for NAME in "$LOCAL_NAME" "$EXTERNAL_NAME"; do
  OUT=$(dig @"$SERVER" "$NAME" A +time=2 +tries=1 2>&1)
  if ! echo "$OUT" | grep -q 'status: NOERROR'; then
    echo "CRITICAL: $NAME の問い合わせに失敗"
    exit 2
  fi
  if [ -z "$(dig @"$SERVER" "$NAME" A +short +time=2 +tries=1)" ]; then
    echo "CRITICAL: $NAME の応答が空"
    exit 2
  fi
done
echo "OK: dnsmasq は応答している"
exit 0

+time=2 +tries=1 で待ち時間を短くしているのは、監視スクリプト自体が長く止まらないようにするためです。外部の名前だけが失敗する場合は、上流サーバーやネットワークの問題を疑います。ローカルの名前まで失敗する場合は、dnsmasq 自体か、待ち受けの設定（listen-address や interface）の問題です。

監視サーバーから別のマシンの dnsmasq を見る場合は、SERVER をそのアドレスにし、監視サーバーからの問い合わせが許可されているかも確認します。

キャッシュと上流サーバーの統計を見る

dnsmasq は、統計を2つの方法で出せます。

CHAOS クラスの TXT 問い合わせ

dnsmasq は、bind ドメインに対する CHAOS クラスの TXT 問い合わせに統計で答えます。

dig @127.0.0.1 cachesize.bind chaos txt +short
dig @127.0.0.1 insertions.bind chaos txt +short
dig @127.0.0.1 evictions.bind chaos txt +short
dig @127.0.0.1 hits.bind chaos txt +short
dig @127.0.0.1 misses.bind chaos txt +short
dig @127.0.0.1 servers.bind chaos txt +short

evictions.bind：有効期限が切れる前に追い出されたキャッシュの数です。継続して増えるなら、cache-size が小さすぎます。
hits.bind と misses.bind：キャッシュで答えた数と、答えられなかった数です。比率の変化を見ます。
servers.bind：上流サーバーごとの、送った問い合わせ数と失敗数です。特定のサーバーだけ失敗が多い場合は、そのサーバーを外すか、別のサーバーに替えます。

no-ident を設定していると、これらの問い合わせには答えません。また、外部から統計を読まれたくない場合は、dnsmasq の待ち受けを内部のネットワークに限定しておきます。

SIGUSR1 でログに書き出す

dnsmasq に SIGUSR1 を送ると、統計をログに書き出します。

sudo kill -USR1 "$(systemctl show -p MainPID --value dnsmasq)"
journalctl -u dnsmasq -n 20 --no-pager

キャッシュの大きさ、追い出された件数、転送した問い合わせ数、上流サーバーごとの送信数と失敗数などが出ます。文言は版によって異なるので、一度出力を見てから、監視で拾う行を決めます。

ログで拾うべきメッセージ

すべての問い合わせを記録する log-queries は、負荷とログの量が大きくなるため、常時有効にするより、調査のときだけ有効にするのが現実的です。常時の監視では、次のような警告を拾います。

同時問い合わせ数の上限に達した旨のメッセージ（Maximum number of concurrent DNS queries reached など）：dns-forward-max の上限に達し、新しい問い合わせを処理できていません。上流サーバーの応答が遅いことが原因なら、上限を上げる前に上流側を調べます。
resolv.conf に関するメッセージ：上流サーバーの一覧を読めない、またはサーバーが1つも見つからないという内容です。resolv-file の指定や、ほかのソフトによる resolv.conf の書き換えを確認します。
DHCP の割り当て範囲が尽きた旨のメッセージ：新しい端末にアドレスを配れていません。

ログをファイルに書き出す log-facility=/var/log/dnsmasq.log を使う場合は、logrotate の設定も合わせて用意しないと、ディスクを使い切る原因になります。

DHCP のリースを監視する

DHCP を使っている場合は、リースファイルの行数と割り当て範囲の大きさを比べます。リースファイルの場所はディストリビューションによって異なり、Debian 系では /var/lib/misc/dnsmasq.leases、RHEL 系では /var/lib/dnsmasq/dnsmasq.leases が一般的です。設定で dhcp-leasefile を指定していればそちらです。

# 現在のリース数
wc -l < /var/lib/misc/dnsmasq.leases

dhcp-range=192.168.1.100,192.168.1.199,12h なら範囲は100件です。リース数が範囲の8割を超えたら通知する、のように、余裕を持った閾値にします。リース時間が長いと、もう使われていない端末の分も残り続ける点に注意します。

監視ツールに組み込む

自作のスクリプトを cron で回すより、既存の監視基盤に乗せたほうが、通知や履歴の管理が楽になります。

Zabbix：エージェントの net.dns アイテムで、指定した名前が解決できるかを監視できます。上のスクリプトを UserParameter として登録する方法もあります。
Uptime Kuma：監視の種類に DNS があり、名前・レコード種別・問い合わせ先のサーバーを指定して応答を確認できます。
Prometheus：dnsmasq の統計を取り出すエクスポーター（dnsmasq_exporter など）があり、上記の CHAOS 問い合わせの値を指標として集められます。エクスポーターは第三者の公開物なので、保守状況を確認してから使います。

通知の条件は「1回失敗したら通知」ではなく、「2〜3回続けて失敗したら通知」にすると、一時的なネットワークの揺れによる誤報を減らせます。

設定変更のときの確認

監視で異常を見つけて設定を直すときは、反映の前に構文を確認します。

sudo dnsmasq --test
sudo systemctl restart dnsmasq

dnsmasq --test は設定ファイルの構文を確認するだけで、待ち受けアドレスの重複などの実行時の問題までは分かりません。再起動後に、上の応答確認スクリプトを手動で一度実行し、正常に戻ったことを確かめてから監視の通知を再開します。

まとめ

dnsmasq の監視は、プロセス・応答・上流サーバー・キャッシュ・DHCP の5つの層で考え、中心は dig による応答の確認に置きます。ローカルの名前と外部の名前を分けて問い合わせると、原因の層が分かります。
プロセス名での監視は、NetworkManager や libvirt の dnsmasq と混同しやすいので、systemd のユニットで対象を特定します。
キャッシュと上流サーバーの状態は、CHAOS クラスの TXT 問い合わせか SIGUSR1 で確認します。追い出しの増加や上流の失敗数の偏りが見るべきポイントです。
監視ツールでは連続した失敗で通知し、設定変更の後は dnsmasq --test と応答確認で戻ったことを確かめます。