host コマンドでは、問い合わせ先のサーバーを最後の引数に書くだけで切り替えられるため、同じレコードを複数のサーバーに聞いて並べる「比較確認」が短いコマンドでできます。まず host -C で権威サーバー同士の SOA のシリアルをそろっているか確かめ、次に権威サーバーと公開キャッシュサーバーの答えを並べ、違いがあれば TTL を見て原因を判断する、という順で進めます。この記事では、その手順と比較用のスクリプト、食い違いのパターンごとの原因と対処を説明します。
host の基本と比較に使う書式
host は BIND に付属する問い合わせツールで、Debian・Ubuntu では bind9-host や bind9-dnsutils、RHEL 系では bind-utils に含まれます（2026年10月現在）。出力が1行の文章の形で短く、比較に向いています。
# 種別を指定して問い合わせる（問い合わせ先は手元の設定）
host -t MX example.com
# 問い合わせ先を最後の引数で指定する
host -t MX example.com 8.8.8.8
# 権威サーバーを指定する
host -t A www.example.com ns1.example.net
# TTL も見たいときは詳しい表示にする
host -v -t A www.example.com 8.8.8.8問い合わせ先を指定すると、出力の先頭に Using domain server: から始まる数行が付きます。比較するときはこの部分を取り除き、答えの行だけを並べます。通常の表示には TTL が出ないため、TTL が必要なときは -v を付け、dig と同じ形式の ANSWER SECTION の2列目を読みます。
比べる相手を決める
比較は「何と何を比べるか」で読み方が変わります。この記事では次の2種類を扱います。
- 権威サーバー同士：ゾーンを持っているサーバーがすべて同じ内容を返しているか。ここが食い違っていると、どのサーバーに当たるかで利用者の見え方が変わります。
- 権威サーバーとキャッシュサーバー：設定した値が、利用者が使うキャッシュサーバーにどこまで届いているか。違っていても、TTL の範囲内なら待てば解消します。
権威サーバーの答えを基準にし、それと他を比べる、という順番を守ると判断に迷いません。
手順1：権威サーバー同士の SOA を比べる
最初に -C を使います。対象ゾーンの NS をすべて調べ、それぞれに SOA を問い合わせて並べてくれます。
host -C example.comNameserver 192.0.2.53:
example.com has SOA record ns1.example.net. hostmaster.example.com. 2026101801 7200 3600 1209600 300
Nameserver 198.51.100.53:
example.com has SOA record ns1.example.net. hostmaster.example.com. 2026101801 7200 3600 1209600 300見るのは SOA の3番目の値、シリアルです。すべてのサーバーで同じなら、ゾーンの内容はそろっていると考えられます。一部だけ古い場合は、そのサーバーへのゾーン転送が止まっているか、遅れています。応答が返らないサーバーがある場合は、委任に書かれているのに動いていないか、そのゾーンを持っていない可能性があります。
なお、DNS 事業者によっては変更のたびにシリアルを更新しない、または独自の方式で管理していることがあります。シリアルがそろっていても念のため、次の手順で個別のレコードも比べます。
手順2：レコードを全サーバーに聞いて並べる
次のスクリプトは、対象ゾーンの権威サーバーと、指定した公開キャッシュサーバーに同じ問い合わせを送り、答えを1行ずつ並べます。答えの並び順はサーバーや問い合わせのたびに変わることがあるため、並べ替えてから表示しています。
#!/bin/sh
# 使い方: sh host-compare.sh ゾーン名 [調べる名前]
# 例: sh host-compare.sh example.com www.example.com
zone="$1"
name="${2:-$1}"
types="A AAAA CNAME MX TXT"
auth=$(host -t NS "$zone" | awk '/name server/ {print $NF}')
servers="$auth 1.1.1.1 8.8.8.8 9.9.9.9"
for t in $types; do
echo "== $name $t"
for s in $servers; do
printf '%-24s ' "$s"
host -W 3 -t "$t" "$name" "$s" 2>&1 \
| grep -v -e '^Using domain server' -e '^Name:' -e '^Address:' -e '^Aliases:' -e '^$' \
| sort | tr '\n' ' '
echo
done
done権威サーバーの行どうしが一致しているか、キャッシュサーバーの行が権威サーバーの行と一致しているかを、上から順に見ていきます。変更の前後で比べたいときは、出力をファイルに保存して diff を使うと、変わった行だけを確認できます。
食い違いのパターンと対処
起こりやすい順に並べます。
キャッシュサーバーだけが古い値を返す
権威サーバーはすべて新しい値なのに、公開キャッシュサーバーの一部が古い値を返す場合です。多くはキャッシュの残り時間によるもので、異常ではありません。host -v -t A 名前 8.8.8.8 で TTL を確かめ、その秒数が過ぎれば新しい値に変わります。次回の変更に備えて、作業の前に TTL を短くしておくと待ち時間を減らせます。
追加したレコードがキャッシュサーバーで「存在しない」になる
追加する前に誰かが問い合わせていると、「存在しない」という答えがキャッシュされます。この時間は、SOA の最後の値と SOA レコードの TTL のうち短いほうで決まります。手順1の出力の最後の値を見て、その時間が過ぎるのを待ちます。
権威サーバーの間で答えが違う
手順1でシリアルが食い違っていれば、ゾーン転送を確認します。自前でプライマリとセカンダリを運用している場合は、転送の許可や通知の設定、セカンダリのログを見ます。DNS 事業者を使っている場合は、変更の反映が数分遅れることもあるため、しばらくおいて再度比べ、解消しなければ事業者に問い合わせます。シリアルが同じなのに内容が違う場合は、手作業で別々に設定したサーバーが混ざっていないかを確認します。
一部の公開キャッシュサーバーだけが失敗する
特定のキャッシュサーバーでだけ SERVFAIL になる場合、DNSSEC の署名の問題が疑われます。検証を行うキャッシュサーバーでのみ失敗するためです。DS の登録状況や署名の状態を、DNSSEC の検証ができるツールで確かめます。
権威サーバーが応答しない、または拒否する
タイムアウトや REFUSED が返るサーバーは、そのゾーンを持っていないか、止まっている可能性があります。レジストラに登録した NS に、移転前の古いサーバーが残っていないかを確認します。
社内と社外で答えが違う
社内のネットワークから手元の設定で問い合わせると、社内向けの DNS サーバーが別の答えを返すことがあります。意図した構成なら問題ありませんが、比較のときは社外のキャッシュサーバーと権威サーバーを明示して問い合わせ、社内の答えと分けて扱います。
比較するときの注意
- ネットワークによっては、外部の DNS サーバーへの直接の問い合わせが止められています。権威サーバーの行がすべてタイムアウトになる場合は、通信の制限を疑います。
-Wの秒数を短くしすぎると、遠いサーバーの応答を失敗と見誤ります。結果が不安定なときは秒数を延ばして再度確かめます。- 公開キャッシュサーバーは、同じアドレスでも場所によって別の拠点が答えるため、時間をおいて問い合わせると結果が変わることがあります。
まとめ
- host は問い合わせ先を最後の引数で切り替えられるため、同じレコードを複数のサーバーで比べるのに向いています。
- まず
host -Cで権威サーバー同士の SOA のシリアルを比べ、ゾーンの内容がそろっているかを確かめます。 - 次に権威サーバーと公開キャッシュサーバーの答えを並べ、違いがあれば
-vで TTL を見て、待てば解消するものかを判断します。 - 権威サーバー同士の食い違いや応答しないサーバーは、待っても解消しないため、転送の設定や委任を直します。