DNS の不具合を host で調べるときは、「アプリと同じ問い合わせ先で再現する」「キャッシュサーバーと権威サーバーの答えを比べる」「応答コードとフラグで段階を絞る」の順に進めると、原因がどこにあるかを短い時間で切り分けられます。host は1行で結果を返す手軽なコマンドですが、-v・-C・-T・-r を組み合わせると、権威サーバーの設定ミス、セカンダリーの更新漏れ、TCP の遮断まで見分けられます。この記事では、WordPress サーバーで「外部に接続できない」「移転後に表示されない」といった症状が出たときを例に、host を使った調べ方を手順として説明します。
準備と基本の形
host は BIND に付属するコマンドで、Debian・Ubuntu では bind9-dnsutils（古い版では dnsutils）、RHEL 系では bind-utils に入っています。macOS には最初から入っています。
host www.example.com # 手元の設定（/etc/resolv.conf）の問い合わせ先に聞く
host -t mx example.com # 種別を指定する
host www.example.com 1.1.1.1 # 問い合わせ先を指定する最後の引数に問い合わせ先を書くと、出力の先頭に Using domain server: と、聞いた相手の名前とアドレスが表示されます。デバッグ中は、どのサーバーの答えを見ているのかを毎回ここで確かめます。
手順1：症状を「DNS の問題」として切り出す
WordPress のサーバーで、プラグインの更新や外部 API の呼び出しが cURL error 6: Could not resolve host で失敗する場合、サーバー自身の名前解決が失敗しています。一方、ブラウザでサイトが開かない場合は、訪問者側の名前解決、サーバーの停止、証明書の問題などが混ざっているため、まず名前解決だけを取り出して確かめます。
ここで押さえておきたいのは、host は DNS だけを問い合わせ、/etc/hosts を見ないという点です。PHP や curl は OS の名前解決の仕組みを使うため、/etc/hosts の記述が優先されることがあります。両方を並べて比べます。
getent hosts api.wordpress.org # OS の仕組み（/etc/hosts を含む）での結果
host api.wordpress.org # DNS だけに聞いた結果getent だけが失敗する、または2つの結果が違う場合は、DNS ではなく /etc/hosts や OS 側の設定に原因があります。両方とも失敗するなら、以降の手順で DNS を調べます。PHP から見た結果を確かめたい場合は、WP-CLI が使える環境なら wp eval 'var_dump( gethostbyname( "api.wordpress.org" ) );' で確認できます。gethostbyname() は解決に失敗すると渡した名前をそのまま返すため、IP ではなく名前が表示されたら失敗です。
手順2：問い合わせ先を3段階で比べる
次に、同じ名前を「手元の問い合わせ先」「公開のキャッシュサーバー」「権威サーバー」の3か所に聞きます。
host www.example.com # 1. 手元の問い合わせ先
host www.example.com 1.1.1.1 # 2. 公開のキャッシュサーバー
host -t ns example.com # 権威サーバーの名前を調べる
host www.example.com ns1.example-dns.net # 3. 権威サーバー結果の組み合わせから、問題の場所を次のように読みます。
- 3（権威）が間違っている：DNS の管理画面の設定が誤っているか、編集したのとは別の DNS 事業者に委任されています。NS の答えと、実際に編集している事業者が一致しているかを確かめます。
- 3 は正しく、2 が古い：キャッシュが残っている状態です。TTL が切れるまで待つと新しい値に変わります。残り時間は手順4の
-vで確認できます。 - 2 は正しく、1 だけが失敗・古い：手元の問い合わせ先（社内 DNS、サーバー事業者の DNS、systemd-resolved など）に原因があります。
/etc/resolv.confの内容と、上流のサーバーが応答しているかを確かめます。 - 1〜3 のすべてが失敗する：ドメインの委任そのもの（レジストラに登録した NS）や、権威サーバーの停止を疑います。手順5へ進みます。
手順3：応答コードで段階を絞る
失敗したときの表示に含まれる応答コードは、問題が起きた段階を表します。
- **
not found: 3(NXDOMAIN)**：その名前は存在しないという、権威サーバーからの確かな答えです。綴り、レコードの作り忘れ、サブドメインを別の場所に委任していないかを確かめます。 - **
not found: 2(SERVFAIL)**：キャッシュサーバーが答えを作れなかった状態です。権威サーバーに届かない、権威サーバーの応答がおかしい、DNSSEC の検証に失敗した、が主な原因です。権威サーバーに直接聞いて答えが返るなら、DNSSEC の署名や DS の登録を疑います。 - **
not found: 5(REFUSED)**：問い合わせを断られています。権威サーバーに、そのサーバーが担当していないドメインを聞いた場合や、キャッシュサーバーが外部からの問い合わせを受け付けない設定の場合に出ます。 - **
connection timed out; no servers could be reached**：応答が返っていません。問い合わせ先のアドレスの誤り、サーバーの停止、ファイアウォールによる UDP 53 番の遮断を疑います。
種別を指定したときに has no MX record のように表示されるのは、名前はあるがその種別が無いという意味で、失敗ではありません。
手順4：-v でフラグと TTL を確かめる
1行の表示では分からない情報は -v で表示します。出力は dig に近い形になり、ヘッダーの応答コード、フラグ、各セクションのレコードと TTL が見えます。
host -v www.example.com 1.1.1.1
host -v -r www.example.com ns1.example-dns.net # -r は再帰を求めない問い合わせ読むべき箇所は flags: の行です。権威サーバーに聞いたのに aa（権威ある答え）が付いていない場合、そのサーバーはそのドメインの権威を持っていません。DNS 事業者を移したあと、旧事業者側でゾーンを削除した、または新事業者側でゾーンの作成が終わっていないときによく見られます。キャッシュサーバーに聞いた場合は、ANSWER SECTION の TTL が残り時間です。値の変更を待っているときは、この数字が0に近づけば次の問い合わせで新しい値に入れ替わると考えられます。
-r は「再帰検索をしないで答えて」という指定です。権威サーバーに聞くときに付けると、そのサーバーが自分のゾーンから答えたのか、たまたまキャッシュを持っていたのかを区別しやすくなります。
手順5：-C で全権威サーバーの SOA を比べる
権威サーバーが複数ある場合、一部のサーバーだけ古い内容を返していると、問い合わせるたびに結果が変わる不安定な症状になります。-C を付けると、NS に登録されたすべての権威サーバーに SOA を聞いて並べて表示します。
host -C example.com各サーバーの行に並ぶ数字のうち、最初の数字がシリアル番号です。番号がそろっていなければ、ゾーンの転送（プライマリーからセカンダリーへの複製）が止まっています。自前の DNS サーバーならセカンダリーの転送設定とログを、DNS 事業者ならその事業者のサポートを確かめます。どれか1台が応答しない場合も、ここで見つかります。
手順6：-T で TCP を試す
TXT レコードが長い場合や DNSSEC の署名が付く場合、応答が大きくなり、UDP では受け取れずに TCP で取り直すことがあります。途中のファイアウォールが TCP 53 番を通さない、または大きな UDP パケットを落とす環境では、小さなレコードは引けるのに特定の種別だけ失敗する、という症状になります。
host -t txt example.com 1.1.1.1 # UDP（通常）
host -T -t txt example.com 1.1.1.1 # TCP で問い合わせるUDP では失敗し TCP では成功する、またはその逆になる場合は、DNS の設定ではなく通信経路の問題です。サーバーのファイアウォールやクラウドのセキュリティグループで、UDP と TCP の両方の 53 番が外向きに許可されているかを確かめます。
手順7：遅いのか、止まっているのかを分ける
応答が遅いだけなのか、まったく返らないのかを分けたいときは、待ち時間と再試行回数を変えます。
host -W 10 -R 1 www.example.com # 10秒待ち、再試行1回
host -4 www.example.com # 問い合わせを IPv4 で送る
host -6 www.example.com # 問い合わせを IPv6 で送る待ち時間を延ばすと成功する場合は、問い合わせ先のサーバーが過負荷か、上流への経路が遅くなっています。-4 と -6 で結果が分かれる場合は、問い合わせ先のサーバーに IPv6 で届いていない可能性があります。-4・-6 はレコードの種別ではなく、問い合わせを送る通信の種類を選ぶ指定です。
調べるときの注意
- 調べた結果を記録しておく：実行したコマンド、時刻、問い合わせ先、出力をそのまま残しておくと、DNS 事業者やサーバー事業者に問い合わせるときに話が早く進みます。
- 原因が分かる前に設定を変えない：結果が不安定だからといって、レコードを消して作り直すと、キャッシュの残り方がさらに複雑になります。変更する場合は、現在の設定を書き出して控えを取り、TTL を短くしてから行います。
- コンテナ内は別の問い合わせ先を使う：Docker のコンテナ内では、ホストとは別の DNS（独自ネットワークでは
127.0.0.11など）を使います。WordPress をコンテナで動かしている場合は、コンテナ内で host を実行して確かめます。 - host の版による違い：オプションや表示の細部は BIND の版によって異なることがあります（2026年10月現在）。手元の
man hostで確かめてから使ってください。
まとめ
- 最初に
getent hostsと host を比べ、/etc/hostsや OS 側の問題を切り離します。 - 手元・公開キャッシュサーバー・権威サーバーの3か所に聞き、どこで答えが崩れているかを確かめます。
- 応答コード（NXDOMAIN・SERVFAIL・REFUSED・タイムアウト）で問題の段階を絞ります。
-vでaaフラグと TTL、-Cで全権威サーバーのシリアル番号、-Tで TCP の通り具合を確かめます。- 設定を変える前に結果を記録し、現在の設定の控えを取ります。