DNSの名前解決の確認方法について

DNSの名前解決を確認するとは、ドメイン名が正しくIPアドレスや各種DNSレコードに解決されるかを調べることです。

たとえば、Webサイトにアクセスするときは、example.com のようなドメイン名をDNSで引いて、対応するIPアドレスを取得してから接続します。

そのため、サイトが開かない、メールが届かない、切り替え後に一部だけ古いサーバーへ向いている、といった問題では、まずDNSの確認が重要になります。

DNS確認では、単に「IPが返るか」だけでは不十分です。

実務では主に次の点を見ます。

• 名前が解決できるか
• 正しいIPアドレスやホスト名が返るか
• レコード種別が正しいか
• どのDNSサーバーが返しているか
• キャッシュや反映遅延の影響がないか
• 権威DNSでは現在どうなっているか

DNSの名前解決とは何か

DNSは、ドメイン名とネットワーク上の情報を対応づける仕組みです。

代表的なのは、次のような変換です。

• example.com → 93.184.216.34

これを一般には「名前解決」と呼びます。

ただし、DNSはIPアドレスだけを返すものではありません。

用途に応じて、メール配送先、別名、認証用テキスト、ネームサーバー情報なども返します。

そのため、DNS確認では用途に応じたレコードを見る必要があります。

まず確認したい主なレコード

DNSの確認でよく使うレコードは次の通りです。

Aレコード

ホスト名をIPv4アドレスに対応づけます。

AAAAレコード

ホスト名をIPv6アドレスに対応づけます。

CNAMEレコード

あるホスト名を別のホスト名の別名として設定します。

MXレコード

メールの配送先サーバーを示します。

TXTレコード

SPF、DKIM、DMARC、ドメイン所有確認などで使われます。

NSレコード

そのドメインを管理する権威ネームサーバーを示します。

SOAレコード

ゾーン管理情報を持つレコードで、シリアル番号などが確認できます。

DNS確認でよく使うコマンド

代表的なのは次の4つです。

• nslookup
• dig
• host
• ping

この中で、詳しく調べるなら dig が最も便利です。

一方、Windows環境では nslookup が標準で使いやすく、基本確認によく使われます。

nslookupで確認する方法

nslookup は手軽に名前解決を確認できるコマンドです。

基本の確認

nslookup example.com

このコマンドでは、通常は現在のPCが利用しているDNSサーバーに問い合わせます。

出力では、主に次を見ます。

• どのDNSサーバーへ問い合わせたか
• どのIPアドレスが返ったか
• 権威応答かどうか

たとえば、次のような結果になります。

Server:  192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name:    example.com
Address: 93.184.216.34

この場合、Server は問い合わせ先DNSサーバー、Address は名前解決結果です。

Non-authoritative answer は、権威DNSから直接返されたという意味ではなく、通常は再帰リゾルバやキャッシュDNS経由の回答であることを示します。

特定のDNSサーバーを指定する

nslookup example.com 8.8.8.8

これはGoogle Public DNSに直接問い合わせる例です。

このように問い合わせ先を変えることで、自PCや社内DNS、プロバイダDNSの影響を切り分けやすくなります。

レコード種別を指定する

MXレコード確認

nslookup -type=mx example.com

NSレコード確認

nslookup -type=ns example.com

TXTレコード確認

nslookup -type=txt example.com

digで確認する方法

dig はDNS調査で非常に強力です。

LinuxやmacOS、WSLなどで特によく使われます。

基本の確認

dig example.com

通常は次のような情報が表示されます。

• ヘッダ情報
• QUESTION SECTION
• ANSWER SECTION
• AUTHORITY SECTION
• ADDITIONAL SECTION

普段の確認では ANSWER SECTION がまず重要です。

ただし、委任や権威の確認、トラブルシュートでは AUTHORITY SECTION やヘッダの status、flags も重要になります。

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

特定のDNSサーバーへ問い合わせる

dig @8.8.8.8 example.com

このように @DNSサーバー名またはIP を付けると、問い合わせ先を指定できます。

比較用としては次のような使い方が便利です。

dig @8.8.8.8 example.com
dig @1.1.1.1 example.com
dig @8.8.4.4 example.com

結果が一致しない場合は、キャッシュ差や反映途中の可能性があります。

結果だけを短く見る

dig +short example.com

返答だけを簡潔に確認したいときに便利です。

pingで確認する方法

ping example.com

ping はDNS専用のコマンドではありませんが、名前解決できるかどうかの簡易確認には使えます。

たとえば出力に

Pinging example.com [93.184.216.34] with 32 bytes of data:

のようにIPアドレスが表示されれば、少なくとも名前解決自体は行われています。

ただし、ping はDNS詳細確認には向いていません。

理由は次の通りです。

• ICMPが遮断されていることがある
• レコード種別が確認できない
• 権威情報やTTL、NSなどが分からない

そのため、ping はあくまで簡易確認であり、本格的なDNS調査では nslookup や dig を使います。

hostコマンドで確認する方法

host はシンプルに結果を見たいときに便利です。

host example.com

MX確認

host -t mx example.com

NS確認

host -t ns example.com

深い調査は dig の方が向いていますが、簡単な確認には十分使えます。

実務でよくある確認パターン

Webサイトが開かない場合

まず次の順番で確認すると効率的です。

nslookup example.com
dig example.com
dig www.example.com
dig example.com A
dig example.com AAAA
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com
dig www.example.com CNAME

ここで確認したいのは次の点です。

• ドメイン名が解決できるか
• www あり／なしで差がないか
• IPv4だけでなくIPv6も誤設定されていないか
• CNAMEの向き先が正しいか
• DNSサーバーごとに返答が一致しているか

よくある原因は次の通りです。

• Aレコード未設定
• www 側だけ未設定
• CNAMEの向き先ミス
• AAAAレコードだけ誤っている
• DNS反映待ち
• 古いキャッシュが残っている

メールが届かない場合

メール系ではAレコードだけでなく、MXやTXTの確認が重要です。

nslookup -type=mx example.com
dig example.com MX
dig mail.example.com A
dig example.com TXT
dig selector._domainkey.example.com TXT
dig _dmarc.example.com TXT

確認したいポイントは次の通りです。

• MXレコードが存在するか
• MXの向き先ホスト名がさらにA/AAAAで解決できるか
• SPFが正しいか
• DKIMセレクタ名が正しいか
• DMARCが正しく公開されているか

DNS切り替え後の反映確認

サーバー移転やメール切り替え時は、反映状況の確認が重要です。

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

必要に応じて、さらに権威DNSも確認します。

このとき見るべき点は次の通りです。

• 返ってくるIPが新旧どちらか
• DNSサーバーによって結果が一致するか
• TTLがまだ長く残っていないか
• ローカルキャッシュの影響がないか

権威DNSに直接確認する方法

これは非常に重要です。

通常のDNS問い合わせでは、途中の再帰リゾルバやキャッシュDNSが返答するため、必ずしも現在の権威情報そのものを見ているとは限りません。

まずNSを確認する

dig example.com NS

たとえば、次のように権威ネームサーバーが分かります。

example.com.  172800 IN NS ns1.example-dns.net.
example.com.  172800 IN NS ns2.example-dns.net.

権威DNSへ問い合わせる

dig @ns1.example-dns.net example.com A +norecurse

ここで +norecurse を付けるのがポイントです。

これにより、再帰問い合わせを期待せず、そのサーバーが持っている情報をより直接的に確認しやすくなります。

さらに、委任の流れ全体を追いたい場合は次も有効です。

dig example.com +trace

+trace はルートから順に辿っていくため、委任ミスや途中の問題確認にも役立ちます。

TTLの見方

dig の結果にはTTLが表示されます。

たとえば次のような形です。

example.com.   300   IN   A   203.0.113.10

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

基本的には、この値がキャッシュ保持時間の目安になります。

つまり、この例ではキャッシュDNSはしばらくこの情報を保持する可能性があります。

ただし、実装によってはTTLの扱いに差が出ることもあり、古い情報を一定時間返す仕組みが有効な場合もあります。

そのため、TTLは「おおむねこのくらいの時間、古い情報が残り得る目安」と理解すると実務的です。

キャッシュの影響を確認する

DNSの問題は、設定ミスではなくキャッシュが原因で起きることも非常に多いです。

キャッシュが残る可能性がある場所は次の通りです。

• OS
• ブラウザ
• ルーター
• 社内DNS
• プロバイダDNS
• 公開DNSリゾルバ

WindowsでDNSキャッシュを削除する

ipconfig /displaydns
ipconfig /flushdns

/displaydns でキャッシュ内容の表示、/flushdns で削除ができます。

macOSでのキャッシュ削除

macOSではバージョン差があるため、コマンドは環境依存です。

代表例としては次がよく使われます。

sudo killall -HUP mDNSResponder

環境によっては追加の操作が必要なこともあるため、macOSでは「バージョンによって異なる」と理解しておくのが安全です。

Linuxでのキャッシュ削除

Linuxも環境依存です。

systemd-resolved を使っている環境では、たとえば次が使えます。

sudo resolvectl flush-caches

または環境によっては

sudo systemd-resolve --flush-caches

が使われます。

ただし、Linux全体の共通コマンドではありません。

nscd、dnsmasq、あるいはキャッシュデーモンを使っていない環境では対処方法が異なります。

正引きと逆引き

DNSには正引きと逆引きがあります。

正引き

ドメイン名からIPアドレスを調べることです。

dig example.com A

逆引き

IPアドレスから名前を調べることです。

dig -x 8.8.8.8

逆引きはメールサーバーの運用や一部の認証・監査で重視されることがあります。

SOAで確認できること

SOAレコードはゾーン管理情報を持っています。

dig example.com SOA

主に次の情報が見られます。

• プライマリネームサーバー
• 管理者情報
• シリアル番号
• ゾーン管理用の各種タイマー値

特にシリアル番号は、DNS変更が権威DNS側で更新されているかを見る手掛かりになります。

名前解決できないときの切り分け手順

名前解決に失敗したときは、次の順番で切り分けると分かりやすいです。

まず自PCから確認する

nslookup example.com
dig example.com

他のDNSサーバーでも確認する

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

レコード種別ごとに確認する

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

権威DNSを確認する

dig example.com NS
dig @ns1.example-dns.net example.com A +norecurse

キャッシュの影響を疑う

• OSキャッシュを削除する
• ブラウザを再起動する
• 別回線で試す
• 別の公開DNSで確認する

実務で使いやすい確認コマンド例

基本確認

nslookup example.com
dig example.com
dig +short example.com

Google Public DNSで確認

nslookup example.com 8.8.8.8
dig @8.8.8.8 example.com

Cloudflare DNSで確認

dig @1.1.1.1 example.com

wwwあり・なし比較

dig example.com
dig www.example.com

IPv4 / IPv6比較

dig example.com A
dig example.com AAAA

CNAME確認

dig www.example.com CNAME

メール設定確認

dig example.com MX
dig example.com TXT
dig _dmarc.example.com TXT

逆引き確認

dig -x 203.0.113.10

権威DNS確認

dig example.com NS
dig @ns1.example-dns.net example.com A +norecurse
dig example.com +trace

正常かどうかの判断基準

DNS確認では、コマンド結果を見るだけでなく、「何をもって正常とするか」が大切です。

Webサイト用途なら

• AまたはAAAAレコードが存在する
• 返るIPが意図したサーバーのもの
• www ありなしが想定通り
• DNSサーバーを変えても大きな差がない
• 権威DNSでも正しい値になっている

メール用途なら

• MXレコードが存在する
• MXの向き先がさらに名前解決できる
• SPF、DKIM、DMARCが正しい
• 必要に応じて逆引きも整っている

よくある誤解

pingが通らない = DNS失敗

これは誤りです。

ICMPが拒否されているだけで、DNS解決自体は成功していることがあります。

自分のPCで見えた値 = どこでも同じ

これも誤りです。

DNSはキャッシュやリゾルバ差の影響で、環境ごとに見え方が変わることがあります。

設定変更したら即時反映される

必ずしもそうではありません。

TTLやキャッシュの影響で、反映に時間差が出ます。

Aレコードだけ見れば十分

実際には用途次第です。

Web、メール、CDN、認証用途で見るべきレコードは変わります。

実務でおすすめの確認順

迷ったときは、まず次の順で見ると効率的です。

1. nslookup example.com
2. dig example.com
3. dig @8.8.8.8 example.com
4. dig @1.1.1.1 example.com
5. dig example.com NS
6. dig @権威DNS example.com A +norecurse
7. dig example.com +trace
8. TTLとキャッシュを確認

この流れで、多くのDNSトラブルはかなり切り分けやすくなります。

まとめ

DNSの名前解決確認では、単に「IPアドレスが返るか」を見るだけではなく、

• 正しいレコードが返るか
• どのDNSサーバーが返しているか
• 権威DNSではどうなっているか
• キャッシュやTTLの影響はないか

まで確認することが重要です。

まずは次のコマンドを押さえておくと実務で役立ちます。

nslookup example.com
dig example.com
dig @8.8.8.8 example.com
dig example.com NS
dig @ns1.example-dns.net example.com A +norecurse
dig example.com +trace

これに加えて、必要に応じて A、AAAA、CNAME、MX、TXT、SOA を確認していけば、DNS関連の多くの問題に対応しやすくなります。

以上、DNSの名前解決の確認方法についてでした。

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