DNSの設定のチェック方法について

2026-05-22

DNSの設定チェックとは、ドメインに設定されているDNSレコードが正しく機能しているかを確認する作業です。

Webサイトが表示されない、メールが届かない、サーバー移転後に旧サイトが表示される、外部サービスのドメイン認証が完了しないといった場合、DNS設定に原因があることがあります。

DNSの確認では、単に「サイトが表示されるか」だけを見るのでは不十分です。

重要なのは、以下のような点を順番に確認することです。

ドメインが正しいネームサーバーを参照しているか
AレコードやAAAAレコードが正しいIPアドレスを向いているか
CNAMEレコードが正しく設定されているか
MXレコードが正しく、メール配送先が合っているか
TXTレコード、SPF、DKIM、DMARCが正しく設定されているか
TTLやDNSキャッシュの影響を理解できているか
権威DNSサーバーとキャッシュDNSサーバーで結果に違いがないか
DNSSECやCAAレコードがトラブルの原因になっていないか

DNSは目に見えにくい仕組みのため、「設定したのに反映されない」「一部の環境だけ古い情報が返る」といった状況が起こりやすいです。

そのため、DNSを確認するときは、どのDNSサーバーに問い合わせて、どのレコードが返っているのかを意識することが大切です。

DNS設定チェックで最初に確認すべきこと

まずネームサーバーを確認する

DNS設定を確認するときは、最初にネームサーバーを確認します。

ネームサーバーとは、そのドメインのDNS情報を管理しているサーバーのことです。

たとえば、ドメインを取得した会社が「お名前.com」で、Webサーバーが「Xserver」、DNS管理が「Cloudflare」という構成の場合、実際にDNSレコードを編集すべき場所はCloudflareです。

この状態でXserver側のDNS設定を変更しても、ドメインのネームサーバーがCloudflareを向いていれば、Xserver側のDNSレコードは基本的に参照されません。

つまり、DNS設定をチェックする際は、まず次の点を確認します。

現在どのネームサーバーが使われているか
自分が編集しているDNS管理画面と一致しているか
古いサーバー会社や旧DNSサービスのネームサーバーが残っていないか
レジストラ側の設定と実際のDNS応答にズレがないか

確認には、次のようなコマンドを使います。

dig example.com NS +short

結果例は以下のようになります。

ns1.example-dns.com.
ns2.example-dns.com.

この結果が、現在そのドメインで使われているネームサーバーです。

ここが想定と違っている場合、AレコードやMXレコードを正しく設定していても、実際には参照されていない可能性があります。

DNSレコードを変更する場所を間違えない

DNSトラブルでよくあるのが、「正しい内容を設定しているのに、設定場所が間違っている」というケースです。

たとえば、以下のような構成を考えてみます。

ドメイン管理会社：お名前.com
Webサーバー：Xserver
DNS管理：Cloudflare

この場合、お名前.comはドメインの契約管理、XserverはWebサイトの置き場所、CloudflareはDNSの管理場所という役割になります。

ドメインのネームサーバーがCloudflareを向いているなら、DNSレコードの編集はCloudflareで行います。

Xserver側でAレコードを変更しても、Cloudflareが権威DNSとして使われていれば、その変更は実際の名前解決には反映されません。

そのため、DNS設定チェックでは、いきなりAレコードやMXレコードを見るのではなく、まずNSレコードを確認することが重要です。

DNS設定チェックで確認する主なレコード

Aレコード

Aレコードは、ドメイン名をIPv4アドレスに紐づけるDNSレコードです。

たとえば、以下のような設定です。

example.com. 300 IN A 192.0.2.10

この場合、example.com にアクセスすると、192.0.2.10 というIPv4アドレスのサーバーへ接続しようとします。

Webサイトが表示されない場合、まず確認すべき代表的なレコードです。

Aレコードでは、次の点を確認します。

正しいIPアドレスを向いているか
旧サーバーのIPアドレスが残っていないか
www あり・なしの両方が正しく設定されているか
CDNやWAFを使っている場合、指定された値になっているか
複数のAレコードが意図通りに設定されているか

確認コマンドは以下です。

dig example.com A +short

www ありのドメインも確認する場合は、次のようにします。

dig www.example.com A +short

example.com と www.example.com は別のホスト名です。

そのため、片方だけ正しく設定されていても、もう片方が未設定であればアクセスできない場合があります。

特にWordPressサイトや企業サイトでは、www あり・なしのどちらかに統一することが多いため、DNSだけでなくWebサーバー側のリダイレクト設定もあわせて確認するとよいでしょう。

AAAAレコード

AAAAレコードは、ドメイン名をIPv6アドレスに紐づけるDNSレコードです。

AレコードがIPv4用であるのに対して、AAAAレコードはIPv6用です。

例は以下の通りです。

example.com. 300 IN AAAA 2001:db8::1

AAAAレコードが設定されていると、IPv6に対応した環境ではIPv6経由で接続される場合があります。

そのため、AAAAレコードの向き先でWebサーバーやSSL証明書が正しく設定されていないと、一部の端末や回線だけでサイトが表示されないことがあります。

AAAAレコードでは、次の点を確認します。

IPv6アドレスが正しいか
サーバー側がIPv6に対応しているか
不要なAAAAレコードが残っていないか
AレコードとAAAAレコードの向き先に矛盾がないか
IPv6接続時にもSSL証明書やWebサーバー設定が正しく機能するか

確認コマンドは以下です。

dig example.com AAAA +short

www ありも確認する場合は、次のようにします。

dig www.example.com AAAA +short

一部の環境だけでサイトが表示されない場合、Aレコードは正しくてもAAAAレコードが原因になっていることがあります。

CNAMEレコード

CNAMEレコードは、あるホスト名を別のホスト名の別名として扱うためのレコードです。

たとえば、以下のような設定があります。

www.example.com. CNAME example.com.

この場合、www.example.com は example.com の別名として扱われます。

また、外部サービスを利用する際に、サブドメインをサービス提供元のホスト名へ向けるためにも使われます。

blog.example.com. CNAME example.hatenablog.com.

CNAMEレコードでは、次の点を確認します。

CNAMEの向き先が正しいか
サービス提供元が指定したホスト名と一致しているか
同じホスト名にAレコードやTXTレコードなどを併用していないか
CNAMEの連鎖が複雑になりすぎていないか
ルートドメインに通常のCNAMEを設定していないか

確認コマンドは以下です。

dig www.example.com CNAME +short

CNAMEを設定した名前には、原則としてAレコード、AAAAレコード、MXレコード、TXTレコードなどを同時に置きません。

たとえば、以下のような設定は避けるべきです。

www.example.com. CNAME example.com.
www.example.com. A 192.0.2.10

同じホスト名にCNAMEとAレコードが混在すると、DNSの仕様上問題になる場合があります。

ルートドメインのCNAMEには注意する

example.com のようなルートドメイン、つまりゾーンの頂点には、通常のCNAMEレコードは設定できません。

理由は、ルートドメインにはNSレコードやSOAレコードなど、そのゾーンを管理するために必要なレコードが存在するためです。

CNAMEを設定した名前には、原則として他のレコードを置けないため、ルートドメインに通常のCNAMEを設定すると矛盾が生じます。

ただし、DNSサービスによっては、以下のようなCNAMEに近い動作を実現する独自機能が用意されている場合があります。

CNAME flattening
ALIAS
ANAME

Cloudflareや一部のDNSサービスでは、ルートドメインでもCNAMEのように外部ホスト名へ向けられる仕組みがあります。

そのため、ルートドメインを外部サービスに向けたい場合は、通常のCNAMEではなく、利用中のDNSサービスが提供する機能を確認することが大切です。

MXレコード

MXレコードは、メールの配送先サーバーを指定するDNSレコードです。

たとえば、以下のような設定です。

example.com. 300 IN MX 10 mail.example.com.

この場合、example.com 宛てのメールは、優先度10の mail.example.com に配送されます。

Google Workspace、Microsoft 365、レンタルサーバーのメール機能などを使う場合は、各サービスが指定するMXレコードを正しく設定する必要があります。

MXレコードでは、次の点を確認します。

メールサービス提供元が指定するMXレコードになっているか
優先度の数値が正しいか
古いメールサービスのMXレコードが残っていないか
MXの向き先が名前解決できるか
メール移行後に不要なMXレコードが残っていないか

確認コマンドは以下です。

dig example.com MX +short

結果例は以下です。

10 mail.example.com.

MXレコードの向き先は、最終的にAレコードまたはAAAAレコードで名前解決できる必要があります。

確認する場合は、次のようにします。

dig mail.example.com A +short

メールが届かない場合は、MXレコードだけでなく、SPF、DKIM、DMARCなどのメール認証用レコードもあわせて確認しましょう。

TXTレコード

TXTレコードは、DNS上にテキスト情報を登録するためのレコードです。

用途は幅広く、主に以下のような場面で使われます。

ドメイン所有権の確認
Google Search Consoleの認証
Google WorkspaceやMicrosoft 365の認証
SPFの設定
DKIMの設定
DMARCの設定
外部SaaSやマーケティングツールとの連携

確認コマンドは以下です。

dig example.com TXT +short

TXTレコードでは、次の点を確認します。

サービス提供元が指定した値と一致しているか
ホスト名の設定場所を間違えていないか
SPFレコードが複数存在していないか
DKIMのセレクタ名が正しいか
DMARCが _dmarc に設定されているか
不要になった認証用TXTレコードが残っていないか

DNS管理画面によっては、ホスト名欄に example.com と入力すべき場合もあれば、空欄や @ を指定する場合もあります。

また、サブドメイン用のTXTレコードでは、入力方法を間違えると意図しない名前に登録されることがあります。

たとえば、google._domainkey.example.com に設定すべきTXTレコードを、誤って google._domainkey.example.com.example.com のように登録してしまうケースがあります。

設定後は、必ず dig などで実際の戻り値を確認しましょう。

SPFレコード

SPFは、メールの送信元サーバーをDNSで指定する仕組みです。

SPFレコードはTXTレコードとして設定します。

例は以下です。

example.com. TXT "v=spf1 include:_spf.google.com ~all"

SPFでは、v=spf1 で始まるTXTレコードを確認します。

dig example.com TXT +short

SPFでよくあるミスは、同じドメインに複数のSPFレコードを設定してしまうことです。

悪い例は以下です。

example.com. TXT "v=spf1 include:_spf.google.com ~all"
example.com. TXT "v=spf1 include:spf.protection.outlook.com ~all"

このように、v=spf1 で始まるTXTレコードが複数存在すると、SPF評価でエラーになる可能性があります。

複数のメールサービスを使う場合は、SPFレコードを1つにまとめます。

example.com. TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all"

ただし、SPFを1つにまとめる際は、include を増やしすぎないよう注意が必要です。

SPFにはDNSルックアップ回数の上限があるため、メール配信サービス、MAツール、CRM、問い合わせフォーム送信サービスなどを多数利用している場合は、SPFチェックツールで検証しておくと安心です。

DKIMレコード

DKIMは、メールが正しい送信元から送られ、途中で改ざんされていないことを確認するための仕組みです。

DKIMもTXTレコードとしてDNSに設定されます。

DKIMでは、通常のドメイン直下ではなく、セレクタ名を含んだホスト名を確認します。

dig selector1._domainkey.example.com TXT +short

selector1 の部分は、利用しているメールサービスによって異なります。

DKIMでは、次の点を確認します。

セレクタ名が正しいか
TXTレコードの値が途中で欠けていないか
DNS管理画面で改行や引用符の扱いを間違えていないか
メールサービス側でDKIMが有効化されているか
古いDKIMレコードと新しいDKIMレコードを混同していないか

DKIMは値が長くなることが多いため、コピー時の抜け漏れに注意が必要です。

DMARCレコード

DMARCは、SPFやDKIMの認証結果をもとに、認証に失敗したメールをどのように扱うかを指定する仕組みです。

DMARCもTXTレコードとして設定します。

確認するホスト名は以下です。

dig _dmarc.example.com TXT +short

DMARCレコードの例は以下です。

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

DMARCでは、次の点を確認します。

ホスト名が _dmarc になっているか
v=DMARC1 で始まっているか
ポリシーが意図した設定になっているか
レポート送信先メールアドレスが正しいか
SPFやDKIMとあわせて正常に機能しているか

メール到達率を改善したい場合や、なりすましメール対策を強化したい場合は、SPF、DKIM、DMARCをセットで確認することが重要です。

SOAレコード

SOAレコードは、そのDNSゾーンの管理情報を示すレコードです。

SOAには、主に次のような情報が含まれます。

プライマリネームサーバー
管理者情報
シリアル番号
更新間隔
再試行間隔
有効期限
ネガティブキャッシュTTL

確認コマンドは以下です。

dig example.com SOA

通常、Web担当者がSOAレコードを直接編集する機会は多くありません。

ただし、複数の権威DNSサーバーでSOAのシリアル番号が異なる場合、DNSゾーンの同期に問題がある可能性があります。

特に自前でDNSサーバーを運用している場合や、セカンダリDNSを使っている場合は、SOAレコードの確認が役立つことがあります。

CAAレコード

CAAレコードは、そのドメインでSSL証明書を発行できる認証局を制限するためのレコードです。

確認コマンドは以下です。

dig example.com CAA

CAAレコードが未設定の場合、通常は特定の認証局に制限していない状態です。

一方で、CAAレコードが設定されている場合は、利用したい認証局が許可されているか確認する必要があります。

たとえば、Let’s EncryptでSSL証明書を発行したいのに、CAAレコードで別の認証局だけを許可している場合、証明書の発行に失敗することがあります。

SSL証明書の発行エラーが出る場合は、AレコードやCNAMEだけでなく、CAAレコードも確認しましょう。

DNS設定をコマンドで確認する方法

digコマンドで確認する

DNS設定の確認では、dig コマンドがよく使われます。

MacやLinuxでは利用できることが多く、WindowsでもWSLなどを使えば実行できます。

Aレコードを確認する場合は、以下のようにします。

dig example.com A +short

MXレコードを確認する場合は、以下です。

dig example.com MX +short

TXTレコードを確認する場合は、以下です。

dig example.com TXT +short

+short を付けると、結果が簡潔に表示されます。

一方で、TTLやレコード種別も確認したい場合は、次のようにすると見やすくなります。

dig example.com A +noall +answer

出力例は以下です。

example.com. 300 IN A 192.0.2.10

この場合、300 がTTL、A がレコード種別、192.0.2.10 が返されたIPアドレスです。

nslookupで確認する

Windows環境では、nslookup を使ってDNSを確認することもできます。

Aレコードを確認する場合は、以下です。

nslookup example.com

MXレコードを確認する場合は、以下です。

nslookup -type=mx example.com

TXTレコードを確認する場合は、以下です。

nslookup -type=txt example.com

NSレコードを確認する場合は、以下です。

nslookup -type=ns example.com

DNSサーバーを指定して確認することもできます。

nslookup example.com 8.8.8.8

ただし、より詳細な調査を行う場合は、dig の方が確認しやすい場面が多いです。

Windowsでdigを使う方法

Windowsで dig を使いたい場合は、WSLを利用する方法があります。

Ubuntuを使う場合は、以下のようにインストールできます。

sudo apt update
sudo apt install dnsutils

インストール後は、次のようにDNSレコードを確認できます。

dig example.com A +short

コマンド操作に慣れていない場合は、オンラインのDNSチェックツールを使う方法もあります。

権威DNSとキャッシュDNSを分けて確認する

権威DNSとは

権威DNSとは、そのドメインのDNS情報を正式に管理しているDNSサーバーのことです。

DNS設定を変更した場合、まず権威DNSが新しい値を返しているか確認することが重要です。

権威DNSを確認するには、まずネームサーバーを調べます。

dig example.com NS +short

結果が以下だったとします。

ns1.example-dns.com.
ns2.example-dns.com.

この場合、それぞれの権威DNSサーバーに直接問い合わせます。

dig @ns1.example-dns.com example.com A +short
dig @ns2.example-dns.com example.com A +short

複数の権威DNSサーバーで異なる値が返る場合、DNSゾーンの同期に問題がある可能性があります。

キャッシュDNSとは

キャッシュDNSとは、利用者の代わりにDNS問い合わせを行い、その結果を一定期間保存するDNSサーバーです。

たとえば、以下のようなパブリックDNSがよく使われます。

dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short
dig @9.9.9.9 example.com A +short

Google Public DNS、Cloudflare DNS、Quad9などに問い合わせることで、主要なDNSリゾルバから見た現在の回答を確認できます。

ただし、これらは権威DNSの直接の回答ではありません。

各リゾルバのキャッシュ状況に影響されるため、DNS変更直後には古い値が返る場合があります。

権威DNSとキャッシュDNSの結果を比較する

DNS変更後に「反映されていない」と感じる場合は、権威DNSとキャッシュDNSの結果を比較します。

たとえば、権威DNSでは新しいIPアドレスが返っているのに、Google Public DNSでは古いIPアドレスが返っている場合、設定自体は正しく、キャッシュDNSに古い情報が残っている可能性があります。

一方で、権威DNSに直接問い合わせても古い値が返る場合は、DNS管理画面での設定が反映されていない、または編集しているDNSサービスが違う可能性があります。

この切り分けを行うことで、原因がDNS設定そのものにあるのか、キャッシュにあるのかを判断しやすくなります。

TTLとDNSキャッシュの確認

TTLとは

TTLとは、DNSレコードのキャッシュ有効期間を示す値です。

たとえば、以下のような結果が返ったとします。

example.com. 3600 IN A 192.0.2.10

この 3600 がTTLです。

単位は秒なので、3600秒は1時間を意味します。

TTLが3600秒であれば、キャッシュDNSはその情報を最大1時間程度保持する可能性があります。

DNS変更直後に古い値が返る場合、TTLによって古いレコードがキャッシュされている可能性があります。

サーバー移転前はTTLを短くする

サーバー移転やDNS切り替えを予定している場合は、事前にTTLを短くしておくと切り替え時の影響を抑えやすくなります。

たとえば、TTLを以下のように短くします。

300秒

ただし、TTLを短くするのは切り替え直前では遅い場合があります。

現在のTTLが86400秒、つまり24時間であれば、すでにキャッシュされた情報は最大24時間程度残る可能性があります。

そのため、サーバー移転の前日や数日前にTTLを短くしておくと、切り替え当日の影響を小さくできます。

DNSキャッシュは複数の場所に存在する

DNSキャッシュは、パブリックDNSだけに存在するわけではありません。

以下のような場所にもキャッシュが残る場合があります。

OSのDNSキャッシュ
ブラウザのキャッシュ
ルーターのDNSキャッシュ
社内ネットワークのDNSキャッシュ
ISPのDNSキャッシュ
CDNのキャッシュ
プロキシサーバーのキャッシュ

そのため、DNSレコードが正しく変更されていても、端末やブラウザ側のキャッシュによって古いサイトが表示されることがあります。

シークレットウィンドウ、別ブラウザ、別回線、スマートフォンのモバイル回線などで確認すると、原因を切り分けやすくなります。

WebツールでDNS設定を確認する方法

DNS Checker系ツール

DNS Checker系のツールを使うと、世界各地のDNSサーバーから現在のDNSレコードの見え方を確認できます。

主に確認できるレコードは以下です。

Aレコード
AAAAレコード
CNAMEレコード
MXレコード
TXTレコード
NSレコード
CAAレコード

サーバー移転後やDNS変更後に、地域やDNSリゾルバごとの回答差を確認するのに便利です。

ただし、地域ごとに違う結果が出ることがあります。

これは、DNS情報がインターネット全体に順番に広がっているというよりも、各DNSリゾルバに残っているキャッシュやTTLの影響によって、古い情報と新しい情報が混在している状態と考える方が正確です。

Google Admin Toolbox Dig

Google Admin Toolbox Digは、ブラウザ上でDNSレコードを確認できるツールです。

Aレコード、AAAAレコード、MXレコード、TXTレコード、CNAMEレコード、NSレコード、SOAレコードなどを確認できます。

Google Workspaceの設定確認にも使いやすく、メール関連のDNS確認にも役立ちます。

コマンド操作に慣れていない場合でも、ブラウザ上でDNSの状態を確認できるため便利です。

MXToolbox

MXToolboxは、メール関連のDNS確認に便利なツールです。

特に以下の確認に向いています。

MXレコード
SPF
DKIM
DMARC
ブラックリストチェック
SMTP診断
DNS Lookup

メールが届かない、迷惑メールに入りやすい、メール配信サービスのドメイン認証が通らないといった場合に役立ちます。

WebサイトのDNS確認だけでなく、メール到達率や送信ドメイン認証の確認にも利用できます。

whatsmydns.net

whatsmydns.netは、世界中のDNSサーバーから特定のDNSレコードの回答を確認できるツールです。

サーバー移転やDNS変更後に、各地域でどのIPアドレスが返っているかを確認するのに便利です。

ただし、表示される結果は各地点のDNSリゾルバから見た回答であり、権威DNSの直接の設定値とは限りません。

正確に設定値を確認したい場合は、権威DNSサーバーへ直接問い合わせる方法と併用しましょう。

DNSの経路を確認する方法

dig +traceで委任関係を確認する

DNSの委任関係を詳しく確認したい場合は、dig +trace を使います。

dig example.com +trace

dig +trace を使うと、ルートDNSサーバーからTLD、権威DNSサーバーへと、DNSの委任関係を順番にたどって確認できます。

通常のキャッシュDNSの回答だけでは分からない、委任先のズレや権威DNSまでの経路確認に役立ちます。

特に以下のような場合に有効です。

ネームサーバーの委任が正しいか確認したい
レジストリ側のNS情報を確認したい
権威DNSまで正しくたどれるか確認したい
DNSSECの問題を切り分けたい
サブドメインの委任状況を確認したい

ただし、出力が長くなるため、初心者の場合はまずNSレコードの確認から始めるとよいでしょう。

サブドメイン委任にも注意する

サブドメインによっては、親ドメインとは別のネームサーバーに委任されている場合があります。

たとえば、以下のような設定です。

shop.example.com. NS ns1.external-service.com.
shop.example.com. NS ns2.external-service.com.

この場合、shop.example.com 以下のDNSレコードは、親ドメインのDNS管理画面ではなく、委任先のDNSで管理されている可能性があります。

サブドメインだけ表示されない、外部サービス連携がうまくいかないという場合は、サブドメインのNS委任も確認しましょう。

DNSSECのチェック方法

DNSSECとは

DNSSECは、DNS応答が改ざんされていないことを検証するための仕組みです。

正しく設定されていればDNSの安全性を高められますが、設定ミスがあると名前解決に失敗することがあります。

特に、ネームサーバーを移行したときにDNSSEC関連の設定が古いままだと、ドメイン全体が解決できなくなる場合があります。

DNSSECでよくあるトラブルは以下です。

DSレコードが古い
DNSSEC署名が壊れている
レジストラ側のDSレコードとDNS側の鍵情報が一致していない
ネームサーバー移行時にDNSSECを無効化し忘れた
DNSSEC対応の権威DNSへ正しく移行できていない

DNSSECをコマンドで確認する

DNSSEC関連の情報は、次のようなコマンドで確認できます。

dig example.com DNSKEY
dig example.com DS
dig example.com A +dnssec

ただし、DNSSECはコマンド結果だけで原因を判断するのが難しい場合があります。

そのため、DNSSECチェックツールを併用すると、どこで検証エラーが起きているかを確認しやすくなります。

DNSSECを利用していない場合は、通常この確認は不要です。

しかし、DNSSECを有効にしているドメインで突然名前解決できなくなった場合は、DNSSECの設定ミスを疑う必要があります。

OSやブラウザのDNSキャッシュを削除する方法

WindowsのDNSキャッシュ

Windowsでは、DNSキャッシュを確認・削除できます。

DNSキャッシュを表示する場合は以下です。

ipconfig /displaydns

DNSキャッシュを削除する場合は以下です。

ipconfig /flushdns

DNS変更後に自分のPCだけ古いサイトが表示される場合は、OS側のDNSキャッシュが影響している可能性があります。

macOSのDNSキャッシュ

macOSでは、バージョンによってコマンドが異なる場合がありますが、一般的には以下を使います。

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

コマンド実行後、ブラウザを再起動して再確認するとよいでしょう。

ChromeのDNSキャッシュ

Chromeでは、バージョンや環境によって、以下の内部ページからDNSキャッシュを確認・削除できる場合があります。

chrome://net-internals/#dns

ただし、Chromeの仕様はバージョンによって変わることがあります。

画面が表示されない場合や操作項目が見つからない場合は、以下の方法も試してください。

Chromeを再起動する
シークレットウィンドウで確認する
OS側のDNSキャッシュを削除する
別ブラウザで確認する
別回線で確認する

DNS変更後の確認では、ブラウザキャッシュやCDNキャッシュも影響することがあるため、DNSだけに原因を限定しないことが大切です。

サイトが表示されないときのDNSチェック手順

ネームサーバーを確認する

まず、対象ドメインがどのネームサーバーを使っているか確認します。

dig example.com NS +short

ここで想定しているDNSサービスが返ってこない場合、DNSレコードの編集場所を間違えている可能性があります。

たとえば、Cloudflareを使っているつもりなのに、旧レンタルサーバーのネームサーバーが返っている場合は、レジストラ側のネームサーバー設定を確認する必要があります。

AレコードとAAAAレコードを確認する

次に、Webサイトの向き先を確認します。

dig example.com A +short
dig www.example.com A +short

IPv6を使っている場合は、AAAAレコードも確認します。

dig example.com AAAA +short
dig www.example.com AAAA +short

正しいIPアドレスが返っているか、旧サーバーのIPアドレスが残っていないかを確認しましょう。

CNAMEを確認する

www やサブドメインを使っている場合は、CNAMEも確認します。

dig www.example.com CNAME +short
dig blog.example.com CNAME +short

外部サービスを利用している場合は、サービス提供元が指定したホスト名と一致しているか確認します。

CNAMEが返っている場合は、その向き先のAレコードやAAAAレコードも確認しましょう。

CDNやWAFの設定を確認する

Cloudflare、AWS CloudFront、Fastly、AkamaiなどのCDNを利用している場合、DNSの向き先は実サーバーではなくCDNになります。

この場合、DNSが正しくても、CDN側の設定が間違っているとサイトが表示されないことがあります。

確認すべき点は以下です。

CDNのオリジン設定が正しいか
CDN側のSSL設定が正しいか
WAFでアクセスがブロックされていないか
キャッシュに古いコンテンツが残っていないか
DNSプロキシの有効・無効が意図通りか

DNSチェックだけで解決しない場合は、CDNやWebサーバー側の設定も確認しましょう。

DNS以外の原因も確認する

DNSが正しくても、サイトが表示されないことはあります。

たとえば、以下のような原因です。

Webサーバーが停止している
サーバーに対象ドメインが追加されていない
SSL証明書が未設定または期限切れ
HTTPSリダイレクトが壊れている
WordPressのサイトURLが間違っている
.htaccess の設定に問題がある
CDNやWAFの設定に問題がある

DNSは、あくまでドメイン名を接続先へ案内する仕組みです。

接続先のサーバーやアプリケーション側に問題がある場合、DNS設定が正しくてもサイトは表示されません。

メールが届かないときのDNSチェック手順

MXレコードを確認する

メールが届かない場合は、まずMXレコードを確認します。

dig example.com MX +short

メールサービス提供元が指定するMXレコードになっているか確認しましょう。

Google WorkspaceやMicrosoft 365を使っている場合、指定されたMXレコードと一致している必要があります。

古いレンタルサーバーのMXレコードが残っていると、メール配送が不安定になる場合があります。

MXの向き先を確認する

MXレコードの向き先が名前解決できるかも確認します。

dig mail.example.com A +short

MXの向き先が存在しない場合、メールを配送できません。

メールサービスの指定値を独自に変更したり、CNAMEに置き換えたりせず、提供元の案内に従って設定しましょう。

SPFを確認する

SPFは、送信元として許可するメールサーバーを指定する設定です。

確認コマンドは以下です。

dig example.com TXT +short

v=spf1 で始まるTXTレコードを確認します。

SPFでは、以下の点に注意します。

SPFレコードが複数存在していないか
利用中のメールサービスがincludeされているか
不要になったサービスが残っていないか
DNSルックアップ上限に達していないか
~all や -all などのポリシーが意図通りか

問い合わせフォーム、メール配信ツール、MAツール、CRMなどを使っている場合、SPF設定が不足していると迷惑メール判定されやすくなります。

DKIMを確認する

DKIMは、メールの正当性を示すための署名です。

確認コマンドは以下です。

dig selector._domainkey.example.com TXT +short

selector の部分は、メールサービスによって異なります。

Google Workspace、Microsoft 365、SendGrid、Mailchimp、HubSpotなど、各サービスで指定されるセレクタ名を確認しましょう。

DMARCを確認する

DMARCは、SPFやDKIMの認証結果をもとに、メールをどう扱うかを指定する設定です。

確認コマンドは以下です。

dig _dmarc.example.com TXT +short

DMARCが未設定でもメール送信自体はできる場合があります。

しかし、なりすまし対策やメール到達率改善を考えるなら、SPF、DKIM、DMARCをセットで整備するのがおすすめです。

サーバー移転時のDNSチェック方法

移転前に現在のDNS設定を記録する

サーバー移転前には、現在のDNS設定を控えておきます。

確認しておきたい主なレコードは以下です。

NSレコード
Aレコード
AAAAレコード
CNAMEレコード
MXレコード
TXTレコード
SPF
DKIM
DMARC
CAAレコード
TTL

コマンドで確認する場合は、以下のようにします。

dig example.com NS +noall +answer
dig example.com A +noall +answer
dig example.com AAAA +noall +answer
dig example.com MX +noall +answer
dig example.com TXT +noall +answer
dig example.com CAA +noall +answer

サーバー移転では、WebサイトのAレコードだけを変更するつもりでも、メール関連のレコードや外部サービス認証用のTXTレコードを誤って削除してしまうことがあります。

事前に現在の設定を記録しておくと、トラブル時に復旧しやすくなります。

移転前にTTLを短くする

DNS切り替え前には、必要に応じてTTLを短くしておきます。

たとえば、TTLを300秒にしておくと、切り替え後のキャッシュ影響を抑えやすくなります。

ただし、現在のTTLが長い場合は、切り替え直前にTTLを短くしてもすぐには効果が出ない場合があります。

現在のTTLが86400秒であれば、少なくとも24時間以上前にTTLを短くしておくのが理想です。

切り替え後に権威DNSとパブリックDNSを確認する

切り替え後は、まず権威DNSに直接問い合わせます。

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

次に、主要なパブリックDNSでも確認します。

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

www ありのドメインも確認しましょう。

dig www.example.com A +short
dig www.example.com CNAME +short

メールを移転していない場合でも、MXレコードやTXTレコードが消えていないか確認します。

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

サーバー移転では、Web表示だけでなくメールや外部サービス認証にも影響が出ることがあるため、DNS全体を確認することが大切です。

DNS設定チェックでよくあるミス

編集しているDNS管理画面が違う

最も多いミスの一つが、DNSレコードの編集場所を間違えているケースです。

たとえば、実際にはCloudflareのネームサーバーを使っているのに、レンタルサーバー側のDNS管理画面でAレコードを変更しているような場合です。

まずは必ずNSレコードを確認しましょう。

dig example.com NS +short

この結果が、実際に参照されているDNS管理元です。

wwwあり・なしの片方だけ設定している

example.com と www.example.com は別の名前です。

そのため、片方だけ設定しても、もう片方が自動的に有効になるとは限りません。

確認コマンドは以下です。

dig example.com A +short
dig www.example.com A +short

必要に応じて、Webサーバー側でリダイレクト設定も行います。

CNAMEと他のレコードが競合している

CNAMEを設定した名前には、原則として他のレコードを同時に設定しません。

悪い例は以下です。

www.example.com. CNAME example.com.
www.example.com. A 192.0.2.10

このような設定はトラブルの原因になります。

CNAMEを使う場合は、そのホスト名にAレコードやTXTレコードなどが重複していないか確認しましょう。

SPFレコードが複数ある

SPFレコードは、同じドメインに複数設定しないようにします。

悪い例は以下です。

example.com. TXT "v=spf1 include:_spf.google.com ~all"
example.com. TXT "v=spf1 include:spf.example-mail.com ~all"

複数のメールサービスを使う場合は、1つのSPFレコードにまとめます。

example.com. TXT "v=spf1 include:_spf.google.com include:spf.example-mail.com ~all"

ただし、includeを増やしすぎるとSPFのDNSルックアップ上限に達する場合があります。

複数の配信ツールを使っている場合は、SPFの検証も行いましょう。

古いMXレコードが残っている

メールサービスを移行した後に、古いMXレコードが残っているとメール配送に問題が出る場合があります。

たとえば、Google Workspaceへ移行したのに、旧レンタルサーバーのMXレコードが残っているケースです。

確認コマンドは以下です。

dig example.com MX +short

メール関連の移行では、MXだけでなくSPF、DKIM、DMARCもあわせて確認することが重要です。

ホスト名を二重に入力している

DNS管理画面によって、ホスト名の入力方法は異なります。

たとえば、www.example.com を登録したい場合、ホスト名欄に www と入力する形式の管理画面もあれば、www.example.com と入力する形式の管理画面もあります。

入力方法を間違えると、以下のような意図しない名前で登録されることがあります。

www.example.com.example.com

設定後は、必ず dig などで実際のDNS応答を確認しましょう。

末尾のドットを誤解している

DNSの結果では、ホスト名の末尾にドットが付いて表示されることがあります。

mail.example.com.

この末尾のドットは、完全修飾ドメイン名を表すもので、異常ではありません。

ただし、DNS管理画面への入力時は、サービスごとの指定に従う必要があります。

管理画面によっては末尾のドットを付ける場合もあれば、付けない場合もあります。

DNS設定チェック用のコマンド一覧

Webサイト関連の確認

dig example.com NS +short
dig example.com A +short
dig example.com AAAA +short
dig www.example.com A +short
dig www.example.com AAAA +short
dig www.example.com CNAME +short

メール関連の確認

dig example.com MX +short
dig example.com TXT +short
dig selector._domainkey.example.com TXT +short
dig _dmarc.example.com TXT +short

TTLや詳細情報の確認

dig example.com A +noall +answer
dig example.com MX +noall +answer
dig example.com TXT +noall +answer

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

dig @ns1.example-dns.com example.com A +short
dig @ns2.example-dns.com example.com A +short

パブリックDNSへの問い合わせ

dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short
dig @9.9.9.9 example.com A +short

DNSの委任関係の確認

dig example.com +trace

DNSSECの確認

dig example.com DNSKEY
dig example.com DS
dig example.com A +dnssec

CAAレコードの確認

dig example.com CAA

DNS設定チェックの実務チェックリスト

Webサイト表示に関するチェック

項目	確認内容
NS	想定しているネームサーバーになっているか
A	正しいIPv4アドレスを向いているか
AAAA	IPv6設定が正しいか
www	wwwあり・なしの両方が設定されているか
CNAME	向き先が正しく、他レコードと競合していないか
TTL	キャッシュ時間を把握しているか
CDN	CDNやWAF側の設定に問題がないか
SSL	SSL証明書が正しく発行されているか
CAA	利用したい認証局が制限されていないか

メールに関するチェック

項目	確認内容
MX	メールサービス指定の値になっているか
SPF	SPFレコードが1つにまとまっているか
DKIM	セレクタ名とTXT値が正しいか
DMARC	`_dmarc` に正しく設定されているか
TXT	認証用TXTが正しい場所に設定されているか
旧設定	古いMXやSPFが残っていないか
ルックアップ上限	SPFのDNSルックアップ上限に達していないか

DNS管理に関するチェック

項目	確認内容
権威DNS	直接問い合わせた結果が正しいか
キャッシュDNS	Google Public DNSやCloudflare DNSでの結果を確認したか
SOA	複数の権威DNSでゾーン情報にズレがないか
DNSSEC	DSレコードや署名に問題がないか
サブドメイン委任	サブドメインが別NSに委任されていないか
入力形式	ホスト名や末尾ドットの扱いを間違えていないか