DNSレコードの反映を確認する方法について

DNSレコードを変更したあと、「設定が正しく入っているか」「すでに外部から新しい情報として見えているか」を確認したい場面はよくあります。

ただし、DNSは設定を保存した瞬間に、すべての環境で一斉に切り替わるわけではありません。

DNSの反映確認では、次の2つを分けて考えることが重要です。

• 権威DNSに正しいレコードが登録されているか
• 各DNSキャッシュサーバーや端末側に新しい情報が広がっているか

この2段階で確認すると、「設定ミスなのか」「キャッシュが残っているだけなのか」を判断しやすくなります。

DNSレコードの反映とは何か

DNSレコードを変更しても、すぐにすべての利用者が新しい情報を見るとは限りません。

その理由は、DNSが権威DNSとキャッシュDNSの仕組みで動いているためです。

大まかには、次のように考えると分かりやすいです。

• まず、変更内容が権威DNSに登録される
• その後、各地の再帰リゾルバや端末側のキャッシュが順次更新される
• TTLの範囲内では、古い情報を保持しているDNSサーバーもある

そのため、DNSの確認では「正式な情報源ではどう見えるか」と「実際の利用環境ではどう見えるか」を分けて調べる必要があります。

反映確認の前に見直したいポイント

DNSの反映を疑う前に、まず設定内容そのものを確認しておくのが大切です。

実務では、反映遅延よりも設定ミスが原因になっていることも少なくありません。

確認しておきたいポイントは次のとおりです。

• レコード種別が正しいか
  A / AAAA / CNAME / MX / TXT / NS など
• ホスト名が正しいか
  @、www、mail、_dmarc、selector1._domainkey など
• 値が正しいか
  IPアドレス、ホスト名、TXT文字列など
• 変更したDNSが、現在そのドメインで使われている権威DNSか
• TTLが不必要に長く設定されていないか

特に多いのは、別のDNSサービスを編集していたというケースです。

ドメイン管理会社とDNS管理会社が異なる場合は、現在どのネームサーバーが使われているかを最初に確認したほうが安全です。

DNSレコードの反映確認で使う主な方法

dig で確認する

DNS確認で最も実務的なのが dig コマンドです。

dig を使うと、どのDNSサーバーに問い合わせて、どのレコードが返ってきたのかを直接確認できます。

Aレコードを確認する

dig example.com A

AAAAレコードを確認する

dig example.com AAAA

CNAMEを確認する

dig www.example.com CNAME

MXレコードを確認する

dig example.com MX

TXTレコードを確認する

dig example.com TXT

NSレコードを確認する

dig example.com NS

dig の結果では、主に次の点を見ます。

• ANSWER SECTION
  実際に返ってきたレコード
• TTL
  その応答に含まれるTTL
• SERVER
  問い合わせ先のDNSサーバー

ここで注意したいのは、TTLが示すのはその応答で返ってきたTTLであり、世界中のDNSキャッシュが同じ残り時間を持っていることを意味するわけではない、という点です。

ただし、反映までの目安としては十分参考になります。

権威DNSに直接問い合わせる

反映確認で特に重要なのが、権威DNSに直接問い合わせる方法です。

これにより、キャッシュの影響を受けず、設定そのものが正しいかを確認できます。

まずはNSを確認します。

dig example.com NS

ここで表示されたネームサーバーに対して、直接問い合わせます。

dig @ns1.example-dns.com example.com A

より厳密に確認したい場合は、SOAも見ておくと安心です。

dig @ns1.example-dns.com example.com SOA

もし権威DNSに対する問い合わせで新しい値が返ってくるなら、少なくともDNS設定自体は反映済みと判断しやすくなります。

一方で、ここで古い値が返る場合は、まだ設定が反映していないか、設定先が間違っている可能性があります。

公開DNSで確認する

権威DNSで正しい値が見えても、利用者側のDNSではまだ古い値が残っていることがあります。

そのため、公開DNSでも確認すると状況を把握しやすくなります。

Google Public DNS

dig @8.8.8.8 example.com A

Cloudflare DNS

dig @1.1.1.1 example.com A

Quad9

dig @9.9.9.9 example.com A

たとえば、

• 権威DNSでは新しい値
• 8.8.8.8では新しい値
• 1.1.1.1では古い値

というように結果が分かれることがあります。

この場合は、設定ミスよりもDNSキャッシュの差が原因である可能性が高いです。

自分の端末で見えている結果を確認する

最後に、自分のPCやサーバーが通常利用しているDNS経由でも確認します。

dig example.com A

ここだけ結果が違う場合は、ローカル環境や社内ネットワークのキャッシュが影響している可能性があります。

nslookup を使う方法

dig が使えない環境では、nslookup でも確認できます。

Windows環境ではこちらのほうが馴染みがある場合も多いです。

基本的な確認

nslookup example.com

DNSサーバーを指定して確認

nslookup example.com 8.8.8.8

MXレコードの確認

nslookup -type=mx example.com

TXTレコードの確認

nslookup -type=txt example.com

詳細な分析には dig のほうが向いていますが、簡単な確認であれば nslookup でも十分役立ちます。

レコード種類ごとの確認ポイント

Aレコード / AAAAレコード

AレコードとAAAAレコードは、ドメインがどのIPアドレスを向いているかを示します。

dig example.com A
dig example.com AAAA
dig www.example.com A

ここでは、想定したIPアドレスが返っているかを確認します。

また、ルートドメインと www は別々に設定されていることが多いため、両方確認するのが安全です。

CNAMEレコード

CNAMEは、あるホスト名を別のホスト名へ向けるレコードです。

dig www.example.com CNAME

CNAME確認で大切なのは、向き先が正しいかだけではありません。

その向き先がさらに正しく解決できるかまで確認する必要があります。

dig app.hosting.example A

MXレコード

MXレコードは、メールの配送先サーバーを示します。

dig example.com MX

見るポイントは、優先度と配送先ホスト名です。

また、MX先ホストが実際に解決できるかも確認しておくと安心です。

dig mail.example.com A
dig mail.example.com AAAA

TXTレコード

TXTレコードは、認証や所有権確認などに広く使われます。

dig example.com TXT
dig _dmarc.example.com TXT
dig selector1._domainkey.example.com TXT

TXT確認でよくあるミスは、文字列の内容そのものよりも、設定するホスト名の位置を間違えることです。

たとえばDMARCは _dmarc、DKIMは selector._domainkey のように、決まった場所へ設定する必要があります。

SPF確認で注意したいこと

SPFはTXTレコードで公開されることが一般的ですが、注意点があります。

TXTレコードが複数あること自体は問題ではありません。

問題になるのは、同じホスト名に v=spf1 のSPFレコードが複数存在する場合です。

そのため、SPF確認では「TXTが何件あるか」ではなく、SPFとして解釈されるレコードが重複していないかを見ることが大切です。

NSレコード

NSレコードは、そのドメインをどのネームサーバーが管理しているかを示します。

dig example.com NS

DNSの反映確認では、このNS確認が出発点になります。

ここで想定外のネームサーバーが返るなら、編集しているDNSサービスがそもそも違う可能性があります。

+short を使うと見やすい

値だけを手早く確認したいときは +short が便利です。

dig example.com A +short
dig example.com MX +short
dig example.com TXT +short

詳細な解析には通常表示が向いていますが、作業中に値だけサッと確認したいときには非常に使いやすいです。

dig +trace で確認する方法

DNSの委任経路そのものを確認したい場合は、+trace が役立ちます。

dig +trace example.com

+trace は、ルートDNSから順にたどって名前解決の経路を追跡する方法です。

そのため、NS委任の不整合や途中の設定不備を確認したいときに有効です。

ただし、+trace は「特定のDNSサーバーへ直接問い合わせる」用途とは別物です。

役割は次のように分けて考えると分かりやすいです。

• dig @ns1.example.com example.com A
  → 特定のサーバーに直接聞く
• dig +trace example.com
  → 名前解決の経路を上からたどる

キャッシュが残っているときの対処

Windows

WindowsではDNSキャッシュの表示と削除ができます。

ipconfig /displaydns
ipconfig /flushdns

Linux

Linuxは環境によって異なりますが、systemd-resolved を使っている場合は次のコマンドが代表的です。

sudo resolvectl flush-caches

ただし、Linuxはディストリビューションや利用しているresolverによって挙動が異なるため、実環境に応じた確認が必要です。

macOS

macOSはバージョンによって扱いが異なります。

実務ではDNSキャッシュのクリアに dscacheutil や mDNSResponder を使うことがありますが、バージョン差があるため、利用中のOSに合った方法を確認してから実行するのが安全です。

TTLの見方

たとえば、dig の結果に次のような表示があったとします。

example.com.    300    IN    A    203.0.113.10

この 300 はTTLで、秒単位です。

この場合、その応答では5分のTTLが付いていることを示しています。

実務では、TTLが長いほど古い情報が残りやすくなります。

ただし、これはあくまでその問い合わせで見えたTTLであり、すべてのDNSサーバーが同じ残り時間で動いているわけではありません。

Web上のDNSチェックツールはどう使うべきか

Web上のDNSチェックサービスは、複数地域・複数DNSサーバーからの見え方をまとめて確認できるので便利です。

ただし、最終的に「設定が正しいか」を判断する際は、権威DNSへ直接問い合わせた結果を優先するのが基本です。

つまり、Webツールは便利な補助手段ではありますが、最終確認の基準は権威DNSと考えるのが安全です。

実務でおすすめの確認順

DNS変更後は、次の順番で確認すると切り分けしやすくなります。

NSを確認する

dig example.com NS

権威DNSへ直接問い合わせる

dig @ns1.example-dns.com example.com A
dig @ns1.example-dns.com example.com SOA

公開DNSで確認する

dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A

自分の端末で確認する

dig example.com A

この手順で見れば、かなりの確率で次のどれかに切り分けられます。

• 設定ミス
• 権威DNSへの未反映
• 公開DNSのキャッシュ残り
• ローカルキャッシュの影響

まとめ

DNSレコードの反映確認では、単に「まだ反映されない」と考えるのではなく、どこでは新しい値が見えていて、どこでは古い値が残っているのかを切り分けることが大切です。

特に重要なのは次の2点です。

• まず権威DNSに直接問い合わせること
• そのあと公開DNSや自分の端末の見え方を比較すること

この流れで確認すれば、設定ミスなのか、単なるキャッシュ待ちなのかをかなり正確に判断できます。

以上、DNSレコードの反映を確認する方法についてでした。

最後までお読みいただき、ありがとうございました。