サブドメインのレコードを追加したのに名前解決できないとき、原因の多くは「待ち時間」ではなく、使われていないDNSサービスに登録しているか、レコード名の入力ミスか、追加前に問い合わせた結果（存在しないという応答）がキャッシュされているかのどれかです。この記事では、権威DNSサーバーに直接問い合わせて「登録が正しいのか」「キャッシュが古いだけなのか」を切り分け、原因ごとに直す手順を説明します。
最初に切り分けること: 登録の問題か、キャッシュの問題か
DNSには、レコードを持っている権威DNSサーバーと、利用者の問い合わせを代わりに調べて結果を一定時間覚えておくキャッシュDNSサーバー（リゾルバ）があります。「反映されない」と感じるとき、どちらで止まっているのかを先に確かめます。
# 1. このドメインの権威DNSサーバー（NS）を確認
dig +short NS example.com
# 2. 権威DNSサーバーに直接聞く（上で出たNSのどれかを指定）
dig @ns1.example-dns.net blog.example.com A
# 3. 公開リゾルバに聞く
dig @1.1.1.1 blog.example.com A
dig @8.8.8.8 blog.example.com AWindows の PowerShell なら Resolve-DnsName blog.example.com -Server 8.8.8.8 で同じ確認ができます。
結果の読み方は次のとおりです。
- 2で答えが返らない: 登録そのものに問題があります。後述の原因1〜3を確認します。
- 2では返るが、3や手元では返らない: 登録は正しく、キャッシュに古い応答が残っています。原因4へ進みます。
- 2も3も正しいIPを返すのに、ブラウザでは開けない: DNSは反映済みで、サーバー側の設定の問題です。原因5を見てください。
dig +trace blog.example.com を使うと、ルートサーバーから順に委任をたどる様子が表示され、どの段階で答えが途切れるかが分かります。
原因1: 実際に使われていないDNSで編集している
もっとも多いのがこのケースです。ドメインを取得したレジストラの管理画面と、サーバー会社やCloudflareのDNS管理画面の両方にレコード編集画面があり、NSが向いていない方にサブドメインを追加してしまいます。たとえばNSをCloudflareに切り替えたあとで、レジストラ側のDNS画面にレコードを足しても、世界中のリゾルバはそこを見に行きません。
手順1で表示されたNSのホスト名を見れば、どのサービスが権威DNSになっているかが分かります。そのサービスの管理画面でレコードを登録し直してください。
原因2: レコード名の入力ミス
管理画面の「ホスト名」欄は、多くのサービスでゾーン名（example.com）が自動で後ろに付きます。この欄に blog.example.com と入力すると、実際には blog.example.com.example.com が作られます。サブドメイン部分の blog だけを入力する形式か、完全なホスト名を入力する形式かは画面ごとに違うため、登録後の一覧表示で確認してください。
BINDなどのゾーンファイルを直接書いている場合は、末尾のドット（.）にも注意が必要です。ドットが無い名前はゾーン名が補われます。
; 正しい例
blog IN A 203.0.113.10
shop IN CNAME shops.example-platform.com.
; 誤り: 末尾のドットが無く shops.example-platform.com.example.com になる
shop IN CNAME shops.example-platform.comゾーンファイルを書き換えたら、SOAのシリアル番号を上げてから再読み込みします。シリアルが変わらないと、セカンダリのDNSサーバーへ転送されません。
ほかに、同じ名前にCNAMEと別のレコードを並べている場合も解決が不安定になります。CNAMEは同じ名前の他のレコードと共存できないため、多くの管理画面では登録時にエラーになりますが、手書きのゾーンでは通ってしまうことがあります。
原因3: サブドメインが別のDNSに委任されている
dev.example.com のようなサブドメインに対して、親ゾーンにNSレコードを置いて別のDNSサービスへ委任している場合、app.dev.example.com のようなレコードは委任先で登録する必要があります。親ゾーン側に書いても参照されません。
dig +short NS dev.example.com で親と違うNSが返れば、委任されています。社内で誰かが以前に設定した委任が残っていることもあるので、心当たりが無くても一度確認すると原因に早くたどり着けます。
原因4: 「存在しない」という応答がキャッシュされている
権威DNSでは正しく返るのに手元で解決できない場合、追加する前に一度アクセスしたことが原因になっていることがよくあります。存在しない名前への問い合わせ結果（NXDOMAIN）もリゾルバにキャッシュされるためです。このネガティブキャッシュの保持時間は、ゾーンのSOAレコードの値（最後のフィールドとSOA自体のTTLのうち小さい方）で決まります。
dig blog.example.com A
# AUTHORITY SECTION に SOA が表示され、status: NXDOMAIN なら否定応答
# SOA 行の最後の数値が、否定応答をキャッシュする秒数の目安この場合はキャッシュが切れるのを待つか、手元のキャッシュだけでも消します。OSごとのコマンドは次のとおりです（環境により異なることがあります）。
# Windows（管理者のコマンドプロンプトまたは PowerShell）
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux（systemd-resolved を使っている場合）
resolvectl flush-cachesブラウザも独自にDNSをキャッシュします。Chromeなら chrome://net-internals/#dns からホストキャッシュを消せます。プロバイダや社内のリゾルバのキャッシュは手元から消せないため、確認のときはスマートフォンのモバイル回線や公開リゾルバを指定した dig を使うと、待たずに結果を見られます。
また、hosts ファイル（Windows は C:\Windows\System32\drivers\etc\hosts、macOS・Linux は /etc/hosts）にテスト用の古い記述が残っていると、DNSより優先されます。移行作業の後は見直してください。
原因5: DNSは正しいが、サーバー側が受け付けていない
dig で正しいIPが返るなら、DNSの作業は終わっています。それでも開けない場合はサーバー側の問題です。
- Webサーバーにサブドメインのバーチャルホストが無い: 既定のサイトやエラーページが表示されます。Nginx の
server_name、Apache のServerName/ServerAliasを確認します。レンタルサーバーでは、管理画面で「サブドメインの追加」を行わないと、DNSだけ向けても表示されないことがあります。 - SSL証明書がサブドメインを含んでいない: 証明書エラーになります。サブドメイン用に証明書を発行するか、ワイルドカード証明書を使います。証明書の自動発行は、DNSが正しく向いた後でないと検証に失敗するので順番に注意してください。
- WordPressマルチサイト（サブドメイン型）の場合: サイトを追加するたびにレコードを足す代わりに、
*.example.comのワイルドカードレコードを用意するのが一般的です。ワイルドカードは、個別に登録した名前があればそちらが優先されます。
curl -sI https://blog.example.com/ でステータスコードと応答ヘッダーを見ると、DNSより先のどこで止まっているかを確かめやすくなります。
反映までの時間の考え方
新しく追加したレコードは、権威DNSに登録された時点で、まだ誰もキャッシュしていなければすぐに引けるのが普通です。「反映に24〜72時間」という目安は、主にNSの変更（ネームサーバーの切り替え）や、既存レコードを長いTTLのまま書き換えた場合の話です。
既存のサブドメインのIPを変える予定があるなら、作業の前日などにTTLを300秒程度まで下げておき、古いTTLが切れてから値を変えると、切り替えが短時間で済みます。TTLの値や下限はDNSサービスによって異なるため（2026年10月現在）、利用中のサービスの仕様を確認してください。
まとめ
- まず権威DNSサーバーに
dig @NSで直接聞き、「登録の問題」か「キャッシュの問題」かを分けます。 - 登録の問題なら、NSが向いているサービスで編集しているか、ホスト名欄の入力形式、ゾーンファイル末尾のドット、委任の有無を確認します。
- 追加前にアクセスしていた場合は否定応答がキャッシュされているので、OS・ブラウザのキャッシュを消し、公開リゾルバで確認します。
- DNSが正しいのに開けないなら、バーチャルホストと証明書、マルチサイトならワイルドカードレコードを確認します。