メインのドメインは表示されるのに、shop.example.com や blog.example.com のようなサブドメインだけが急に開けなくなった場合、原因はそのサブドメインに固有の設定にあります。まず dig の応答コード（NXDOMAIN・SERVFAIL・NOERROR）を見て「DNSで引けていないのか、引けているのにサーバー側で失敗しているのか」を分け、次に CNAME の向き先、DNS移行時の登録漏れ、委任先のネームサーバー、DNSSEC の順に確認します。この記事は、以前は動いていたサブドメインが止まったときの切り分けを扱います。新しく作ったサブドメインが反映されない場合とは、疑う順番が異なります。
最初に症状の種類を見分ける
ブラウザのエラー表示は、DNS の問題か、その先の問題かを見分ける手がかりになります。
- 「サーバーの IP アドレスが見つかりませんでした」（Chrome の
DNS_PROBE_FINISHED_NXDOMAINなど）: 名前解決の段階で失敗しています。この記事の手順で調べます。 - 「接続が拒否されました」「タイムアウト」: 名前は引けていて、その IP アドレスのサーバーが応答していない可能性があります。
- 証明書のエラー、502・503 などの HTTP エラー: DNS は正常で、サーバーや証明書の問題です。
DNS の問題かどうかは、次のコマンドの status: で判定します。
dig shop.example.com A| status | 意味 | 主な原因 |
|---|---|---|
| NXDOMAIN | その名前は存在しない | レコード削除、CNAME の向き先が消えた |
| SERVFAIL | リゾルバーが答えを得られなかった | 委任先のネームサーバー停止、DNSSEC の検証失敗 |
| NOERROR で ANSWER 0 | 名前はあるが A レコードがない | 別の種類のレコードだけが残っている |
| NOERROR で IP が返る | DNS は答えている | IP が古い、またはサーバー側の問題 |
比較のため、メインのドメインも同じように引いておきます。メインが正常でサブドメインだけ異常なら、ゾーン全体ではなくサブドメインの設定に絞って調べられます。
原因1: CNAMEの向き先が消えた・変わった
サブドメインが外部サービス（ECサイトのサービス、CDN、クラウドのロードバランサーなど）を CNAME で指している場合、相手側で設定が削除されたり、ホスト名が変わったりすると、サブドメインも引けなくなります。最も多い原因の一つです。
# サブドメインの CNAME を確認
dig shop.example.com CNAME +short
# 向き先そのものが引けるか
dig shops.example-saas.net A向き先が NXDOMAIN なら、外部サービス側の契約や設定を確認します。サービスを解約したのであれば、CNAME レコードも削除してください。消えた向き先を指したままの CNAME は、第三者がその名前を外部サービス上で取得すると、あなたのサブドメインで別のコンテンツを表示される「サブドメイン乗っ取り」の原因になります。
原因2: DNSの移行でサブドメインのレコードが漏れた
ネームサーバーを別の事業者へ移したあと、しばらくしてサブドメインだけ止まった、という例はよくあります。移行先でメインのドメインと www だけを登録し、ほかのサブドメインを登録し忘れていても、旧事業者側のキャッシュが残っている間は動いてしまうためです。
# 今のネームサーバー
dig example.com NS +short
# そのネームサーバーに直接、サブドメインを聞く
dig shop.example.com A @ns1.new-dns.example.net今のネームサーバーが NXDOMAIN を返すなら、登録漏れです。旧事業者のゾーン設定を控えている場合は、それと突き合わせて足りないレコードを追加します。ゾーンの自動取り込み機能を使った場合も、すべてのサブドメインが取り込まれるとは限らないので、一覧で確かめます。
原因3: 委任先のネームサーバーが止まった
サブドメインだけを別のDNSに任せる「委任」をしている場合（例: dev.example.com だけ別のクラウドDNSで管理）、委任先が停止・解約されると、そのサブドメインは SERVFAIL になります。
# 親ゾーンにサブドメインの NS があるか
dig dev.example.com NS @ns1.example-dns.net
# 上から順にたどり、どこで止まるかを見る
dig dev.example.com A +trace+trace の最後で、委任先のネームサーバーから応答がない、または「そのゾーンを知らない」応答が返る状態は「レイムデリゲーション」と呼ばれます。委任先でゾーンを作り直すか、親ゾーンの NS レコードを消して、親ゾーンに A レコードを直接登録します。
原因4: DNSSECの検証に失敗している
委任したサブドメインに DNSSEC を設定している場合、委任先で鍵を更新したのに親ゾーンの DS レコードを更新していないと、検証を行うリゾルバーだけが SERVFAIL を返します。「ある回線では見えて、別の回線では見えない」という症状になりやすいのが特徴です。
# 通常の問い合わせ（SERVFAIL になる）
dig dev.example.com A @1.1.1.1
# 検証を無効にした問い合わせ（答えが返るなら DNSSEC が原因）
dig dev.example.com A @1.1.1.1 +cd+cd を付けたときだけ答えが返るなら、DNSSEC の不整合です。DNSViz などの診断ツールで、どの段階の署名が合っていないかを確認し、DS レコードを正しい値に直します。
原因5: レコードは残っているが中身が古い
DNS が IP アドレスを返している場合でも、その値が古いことがあります。サーバーを移転したとき、メインのドメインだけ新しい IP に変えて、サブドメインの A レコードを旧サーバーのままにしていた、という例です。旧サーバーが停止した時点で、サブドメインだけが落ちます。
IPv6 の AAAA レコードにも注意します。A は新しくしたのに AAAA が古いままだと、IPv6 で接続できる利用者だけ表示できない、という分かりにくい症状になります。
dig shop.example.com A +short
dig shop.example.com AAAA +short返った IP アドレスが今のサーバーのものかを、サーバーの管理画面で照合してください。
ワイルドカードに頼っていた場合
*.example.com のワイルドカードで受けていたサブドメインに、あとから TXT など別の種類のレコードを1件でも追加すると、その名前はワイルドカードの対象から外れます。その結果、A レコードがない状態（NOERROR で ANSWER 0）になります。_acme-challenge.shop.example.com のように、その下の階層にレコードを作った場合も、shop.example.com という名前が存在する扱いになり、同じことが起きます。ドメイン認証のために TXT を足した直後に止まった場合は、この仕組みを疑い、その名前にも A または CNAME を明示的に登録します。
直したあとの確認と、再発を防ぐ工夫
修正後は、権威DNSに直接聞いて正しい値が返ることを確かめてから、公開DNSでも確認します。リゾルバーには「存在しない」という答えもキャッシュされるため、権威DNSが正しくてもしばらく古い結果が見えることがあります。待つ時間の目安は、ゾーンの SOA レコードの最後の値と、SOA レコード自体の TTL のうち小さいほうです。
再発を防ぐには、次の運用が役立ちます。
- サブドメインの一覧と用途、向き先を表にして管理する。
- DNS の移行やサーバー移転の前に、ゾーン全体を書き出して控える。
- 外部サービスを解約するときは、対応する CNAME も同時に削除する。
- 主要なサブドメインを外部の監視サービスで定期的に確認する。
DNS 事業者の管理画面の表記や、ゾーンの書き出し・取り込み機能の有無は事業者ごとに異なり、変わることもあります（2026年10月現在）。作業前に利用中の事業者のヘルプを確認してください。
まとめ
- まず
digの status で、DNS の問題か、サーバー側の問題かを分けます。 - NXDOMAIN なら、CNAME の向き先とDNS移行時の登録漏れを最初に疑います。
- SERVFAIL なら、委任先のネームサーバーと DNSSEC の DS レコードを確認します。
+cdで答えが返るなら DNSSEC が原因です。 - IP が返るのに開かない場合は、A・AAAA の値が今のサーバーのものかを照合します。
- 不要になった CNAME は放置せず削除し、サブドメイン乗っ取りを防ぎます。