新しく追加したAレコードが引けないときは、まずドメインの権威DNSに直接問い合わせ、「権威DNSに載っていない」のか「権威DNSには載っているが手元のキャッシュが古い」のかを分けます。既存のレコードを書き換えた場合と違い、追加の場合は「まだ存在しない」という答えのキャッシュ（ネガティブキャッシュ）や、ホスト名の入力ミス、追加先のDNSの取り違えが原因になることが多くあります。この記事では、追加したAレコードが反映されないときの原因を、起こりやすい順に確かめ方と直し方つきで説明します。
最初に：権威DNSと公開DNSの答えを並べる
例として blog.example.com にAレコードを追加したとします。次の2つの問い合わせ結果を比べます。
# ドメインが使っているネームサーバーを調べる
dig example.com NS +short
# 権威DNSに直接問い合わせる
dig @ns1.example-dns.net blog.example.com A +norecurse +noall +answer +comments
# 公開DNSに問い合わせる
dig @8.8.8.8 blog.example.com A +noall +answer +authority +comments見るのは status: の値と答えの行です。
- 権威DNSでIPが返り、公開DNSが NXDOMAIN: 追加は正しくできています。公開DNSに「存在しない」という答えが残っています（原因1）
- 権威DNSでも NXDOMAIN や答えなし: 権威DNSに載っていません。入力ミスか、追加先の取り違えです（原因2〜4）
- 権威DNSがSERVFAILやタイムアウト: 問い合わせ先がそのゾーンを持っていないか、DNSサービスに問題があります
この切り分けを先にすると、待てば直るのか、設定を直す必要があるのかが分かります。
原因1：「存在しない」という答えがキャッシュされている
追加する前に、その名前を一度でも問い合わせていると、キャッシュDNSは「その名前は存在しない（NXDOMAIN）」という答えを一定時間保持します。これをネガティブキャッシュと呼びます（RFC 2308）。追加前にブラウザで開いて確かめた、設定画面の動作確認でアクセスした、といった操作でも起こります。
保持時間は、追加したAレコードのTTLではなく、ゾーンのSOAレコードで決まります。具体的には、SOAレコード自体のTTLとSOAの最後の項目（MINIMUM）のうち小さいほうです。公開DNSに問い合わせたとき、AUTHORITY SECTION にSOAの行が表示され、その2列目が残り秒数です。
;; AUTHORITY SECTION:
example.com. 2541 IN SOA ns1.example-dns.net. hostmaster.example.com. 2026101801 7200 3600 1209600 3600この例では、あと2541秒ほどで公開DNSが権威DNSに聞き直します。対処は次のとおりです。
- 待つ: 残り秒数が0になれば新しい答えに入れ替わります
- 公開DNSのキャッシュ消去を依頼する: Google Public DNS や Cloudflare の 1.1.1.1 には、特定の名前のキャッシュ消去を依頼できるWebページがあります。提供状況や手順は変わることがあるため、各サービスの案内で確かめてください（2026年10月現在）
- 手元のキャッシュを消す: OSやブラウザも否定の答えを持つことがあります。Windows なら
ipconfig /flushdns、Chrome ならchrome://net-internals/#dnsの「Clear host cache」で消せます
今後のために、新しい名前は「追加してから確かめる」順にすると、この待ち時間を避けられます。
原因2：ホスト名の入力欄の書き方を間違えている
権威DNSにも載っていない場合、最も多いのは名前の入力ミスです。多くの管理画面は、入力欄にドメイン名を自動で付け足します。そこに blog.example.com と全部入れると、実際には blog.example.com.example.com という名前で登録されることがあります。
# 二重になった名前で登録されていないか確かめる
dig @ns1.example-dns.net blog.example.com.example.com A +norecurse +noall +answerこちらで答えが返れば、入力欄に blog だけを入れて登録し直し、誤った行は消します。BINDのゾーンファイルでも、名前の末尾にドット（.）を付けない書き方はゾーン名が付け足されるので同じことが起こります。blog.example.com. のように完全な名前で書くか、blog とだけ書くかのどちらかにそろえます。
ほかに、ルートドメイン（example.com そのもの）に追加したいのに名前の欄を空欄や @ 以外にしている、全角文字が混ざっている、といった誤りもあります。
原因3：ドメインが使っていないDNSに追加している
レジストラ、レンタルサーバー、CDNなど、DNSの編集画面が複数の場所にあることは珍しくありません。ドメインのネームサーバーとして登録されていない場所に追加しても、誰からも参照されません。
dig example.com NS +short で表示されたネームサーバーの名前が、レコードを追加したサービスのものかを確かめます。違う場合は、表示されたネームサーバーを管理しているサービスでAレコードを追加します。ネームサーバーを切り替えた直後なら、レジストラ側の登録と dig example.com NS +trace の最後に表示される答えが一致しているかも見ておきます。
原因4：サブドメインが別のDNSに委任されている
blog.example.com に追加したのに引けず、example.com 側の他のレコードは正常な場合、そのサブドメインがNSレコードで別のDNSに委任されていないかを確かめます。
dig @ns1.example-dns.net blog.example.com NS +norecurse +noall +answer +authorityblog.example.com のNSレコードが返る場合、そのサブドメインのレコードは委任先のDNSで管理されています。Aレコードは委任先に追加します。以前のサービスで設定した委任が残っているだけなら、不要なNSレコードを削除するのも選択肢ですが、そのサブドメインで動いているものが無いかを先に確かめます。
原因5：同じ名前に別のレコードがある、またはワイルドカードが答えている
追加しようとした名前にすでにCNAMEがあると、規格上ほかのレコードは同居できないため、管理画面では登録エラーになります。エラーを見落として保存できていないこともあるので、一覧に追加した行が実際にあるかを見ます。
また、*.example.com のワイルドカードレコードがあるゾーンでは、追加前から blog.example.com に何らかの答えが返っていたはずです。その答えがワイルドカードのTTLでキャッシュされているため、追加後もしばらくはワイルドカードの値が返ります。この場合はネガティブキャッシュではなく、ワイルドカードの行のTTLだけ待つことになります。
原因6：自分で運用する権威DNSで、セカンダリに伝わっていない
BINDなどで権威DNSを運用している場合、ゾーンファイルにAレコードを追加してもSOAのシリアル番号を上げていないと、セカンダリDNSは変更を取り込みません。ネームサーバーごとに答えが違う状態になり、利用者によって引けたり引けなかったりします。
for ns in $(dig example.com NS +short); do
echo "$ns: $(dig @"$ns" example.com SOA +short)"
doneシリアル番号が食い違うサーバーがあれば、プライマリでシリアルを上げて rndc reload example.com を実行し、転送の状態をログで確かめます。DNSSECで署名しているゾーンでは、署名の更新に失敗すると公開DNSが SERVFAIL を返します。dig +cd（検証を無効にした問い合わせ）でだけ答えが返る場合は、署名の問題を疑います。
DNSは正しいのにサイトが表示されないとき
権威DNSにも公開DNSにも新しいIPが出ているのにページが開かない場合は、DNS以外の原因です。Webサーバーに blog.example.com 用の設定（バーチャルホスト）があるか、そのサーバーのファイアウォールで80番と443番が開いているか、SSL証明書にその名前が含まれているかを確かめます。WordPressを新しいサブドメインで公開する場合は、「設定」→「一般」のサイトアドレスもその名前に合っているかを見ます。
まとめ
- 最初に権威DNSと公開DNSの答えを比べ、待てば直るのか、設定を直すのかを分ける
- 追加前に問い合わせた名前は「存在しない」とキャッシュされ、SOAで決まる時間だけ残る
- 入力欄にドメインまで入れると名前が二重になる。ゾーンファイルでは末尾のドットに注意する
- ドメインが使っているネームサーバー、サブドメインの委任先に追加しているかを確かめる
- 自前の権威DNSではシリアル番号を上げ、すべてのネームサーバーで同じ答えになるかを見る