nslookupとは

Webサイトを公開したとき、サーバーを移転したとき、メール設定を変更したとき、外部サービスと独自ドメインを連携したときなどに、「DNSが正しく設定されているか」を確認したい場面があります。

そのようなときに役立つのが、nslookup です。

nslookupは、DNSサーバーに問い合わせを行い、ドメイン名やIPアドレスに関する情報を確認するためのツールです。

Webサイト運用、サーバー管理、メール設定、SaaS連携など、さまざまな場面で使われます。

特に、ドメインが正しいサーバーを向いているか、メールサーバーの設定が正しいか、TXTレコードが反映されているか、ネームサーバーが想定どおりになっているかを確認したいときに便利です。

nslookupとは

nslookupとは、DNSに登録されている情報を確認するためのコマンドです。

DNSは、ドメイン名とIPアドレスを対応させる仕組みです。

私たちは普段、Webサイトにアクセスするときにドメイン名を使います。

しかし、コンピューター同士の通信では、ドメイン名ではなくIPアドレスが使われます。

たとえば、人間にとってはドメイン名のほうが覚えやすいですが、サーバー同士が通信するときにはIPアドレスが必要です。

DNSは、そのドメイン名をIPアドレスに変換する役割を担っています。

nslookupは、このDNSの情報を手動で確認するためのツールです。

つまり、nslookupを使うことで、次のようなことを確認できます。

確認したい内容	関係するDNS情報
Webサイトがどのサーバーを向いているか	Aレコード、AAAAレコード
メールがどのサーバーに配送されるか	MXレコード
DNSをどのサービスが管理しているか	NSレコード
メール認証やサービス認証が設定されているか	TXTレコード
サブドメインがどこに向いているか	CNAMEレコード
IPアドレスからホスト名を確認できるか	PTRレコード
DNSゾーンの管理情報	SOAレコード

Web担当者やマーケターにとっては、サーバー移転後の確認、Google Search Consoleの認証確認、メール配信ツールの設定確認、LPツールやCMSとのドメイン連携確認などで役立ちます。

nslookupで確認できる主なDNSレコード

nslookupでは、DNSに登録されているさまざまなレコードを確認できます。

ここでは、実務でよく使われる代表的なレコードを紹介します。

Aレコード

Aレコードは、ドメイン名をIPv4アドレスに対応させるレコードです。

Webサイトがどのサーバーを向いているかを確認するときによく使われます。

たとえば、サーバー移転を行ったあとに、ドメインが新しいサーバーのIPアドレスを向いているか確認したい場合、Aレコードを調べます。

Aレコードの確認は、以下のような場面で使われます。

• Webサイトが表示されない
• サーバー移転後に新しいサーバーへ向いているか確認したい
• 古いサーバーのIPアドレスが残っていないか確認したい
• ルートドメインの向き先を確認したい
• CDN導入後の向き先を確認したい

Webサイト運用では、最も基本的な確認対象のひとつです。

AAAAレコード

AAAAレコードは、ドメイン名をIPv6アドレスに対応させるレコードです。

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

IPv6に対応しているWebサイトでは、AAAAレコードが設定されていることがあります。

最近ではIPv6環境も増えているため、Webサイトの接続トラブルを調べるときに確認することがあります。

たとえば、IPv4では問題なく表示されるのに、特定の環境だけ表示がおかしい場合、AAAAレコードやIPv6側の設定が関係している可能性があります。

MXレコード

MXレコードは、そのドメイン宛のメールをどのメールサーバーに配送するかを指定するレコードです。

独自ドメインのメールを使う場合、MXレコードの設定は非常に重要です。

たとえば、Google WorkspaceやMicrosoft 365を使って独自ドメインメールを運用する場合、指定されたMXレコードをDNSに設定する必要があります。

MXレコードは、以下のような場面で確認します。

• 独自ドメインメールが届かない
• Google Workspaceにメールを移行した
• Microsoft 365にメールを移行した
• メールサーバーを変更した
• メール配信先が意図したサーバーになっているか確認したい

MXレコードには優先度があります。

一般的に、数値が小さいものほど優先度が高くなります。

複数のMXレコードが設定されている場合、まず優先度の高いメールサーバーが使われ、利用できない場合に次のメールサーバーが使われます。

NSレコード

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

DNSトラブルの調査では、NSレコードの確認が非常に重要です。

なぜなら、DNSレコードをどこで編集すべきかは、現在設定されているネームサーバーによって決まるためです。

たとえば、ドメインを取得した会社と、実際にDNSを管理しているサービスが異なることがあります。

よくある例として、ドメインはドメイン管理会社で取得し、ネームサーバーはCloudflareやAWS Route 53などに変更しているケースがあります。

この場合、ドメイン管理会社側のDNS画面でレコードを編集しても、実際には反映されません。

DNS設定を変更したのに反映されない場合は、まずNSレコードを確認し、現在どのネームサーバーが使われているかを確認することが重要です。

TXTレコード

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

もともとは任意のテキスト情報を登録するためのものですが、現在ではメール認証や各種サービス認証でよく使われます。

代表的な用途は以下です。

用途	内容
SPF	メール送信元の正当性を確認する
DKIM	メールに電子署名を付け、改ざんを検知する
DMARC	SPFやDKIMの認証結果に基づく処理方針を指定する
Google Search Console認証	ドメイン所有権を確認する
Microsoft 365認証	独自ドメインの所有確認を行う
SaaS連携	HubSpot、SendGrid、Mailchimpなどの認証に使う

特にメール配信ツールやMAツールを使う場合、TXTレコードの確認は重要です。

SPF、DKIM、DMARCが正しく設定されていないと、メールが迷惑メールに入りやすくなったり、送信ドメイン認証に失敗したりする可能性があります。

CNAMEレコード

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

たとえば、サブドメインを外部サービスに向ける場合によく使われます。

CNAMEは、以下のような場面で利用されます。

• wwwありのドメインを別のホスト名に向ける
• LP作成ツールに独自サブドメインを接続する
• 外部CMSにブログ用サブドメインを接続する
• ECプラットフォームにショップ用サブドメインを接続する
• メール配信ツールのトラッキング用ドメインを設定する
• SaaSのドメイン認証を行う

たとえば、LP作成ツールやメール配信ツールを使う場合、サービス側から「このサブドメインにCNAMEを設定してください」と案内されることがあります。

その設定が正しく反映されているかを確認するときに、nslookupが役立ちます。

CNAMEの注意点

CNAMEには重要な制約があります。

CNAMEは、基本的に他のレコードと共存できません。

そのため、ドメインの頂点、つまりルートドメインには、通常のCNAMEを置くことができません。

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

CNAMEは他のレコードと共存できないため、ルートドメインに通常のCNAMEを設定するとDNSの仕様上問題になります。

一方で、サブドメインにCNAMEを設定することは一般的です。

たとえば、www付きのドメイン、LP用のサブドメイン、ブログ用のサブドメイン、ショップ用のサブドメインなどには、CNAMEがよく使われます。

ルートドメインを外部サービスに向けたい場合は、DNSサービスによって以下のような代替機能を使うことがあります。

代替機能	概要
ALIASレコード	ルートドメインでも外部ホスト名に近い指定ができる機能
ANAMEレコード	ALIASに近い仕組みを提供するDNSサービス独自機能
CNAME Flattening	CNAMEのように指定しつつ、実際にはAレコードのように応答する仕組み
Aliasレコード	AWS Route 53などで使われる独自機能

外部サービスと独自ドメインを連携する場合は、ルートドメインに設定するのか、サブドメインに設定するのかを必ず確認しましょう。

PTRレコード

PTRレコードは、IPアドレスからホスト名を確認するためのレコードです。

通常のDNSは、ドメイン名からIPアドレスを調べます。

一方、PTRレコードを使った逆引きDNSでは、IPアドレスからホスト名を調べます。

PTRレコードは、以下のような場面で使われます。

• メールサーバーの信頼性確認
• 送信元IPの確認
• アクセスログ調査
• サーバー管理
• 迷惑メール対策

特にメール配信では、送信元IPの逆引きDNSが不自然だと、迷惑メール判定に影響することがあります。

ただし、PTRレコードは通常、ドメインのDNS管理画面ではなく、IPアドレスを管理している事業者側で設定します。

たとえば、レンタルサーバー、クラウド事業者、メール配信サービスなどを使っている場合、PTRレコードはサービス提供元が管理していることが多いです。

SOAレコード

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

SOAレコードには、主に以下のような情報が含まれます。

項目	内容
プライマリネームサーバー	主要な権威DNSサーバー
管理者情報	DNSゾーン管理者に関する情報
シリアル番号	DNSゾーン情報のバージョン番号
更新間隔	セカンダリDNSが確認する間隔
再試行間隔	更新確認に失敗したときの再試行間隔
有効期限	ゾーン情報を保持する期限
最小TTL	ネガティブキャッシュなどに関係する値

一般的なWebサイト運用では、Aレコード、CNAME、MX、TXT、NSほど頻繁には確認しません。

ただし、DNS設定の不整合や権威DNSの状態を調べるときには役立つことがあります。

nslookupの結果に出る「Non-authoritative answer」とは

nslookupを使うと、「Non-authoritative answer」と表示されることがあります。

これは「非権威回答」という意味です。

簡単に言うと、問い合わせたDNSサーバーが、そのドメインを直接管理している権威DNSサーバーではない状態で返した回答です。

通常、私たちがDNSに問い合わせるときは、プロバイダのDNSサーバー、社内DNS、Google Public DNS、Cloudflare DNSなどのキャッシュDNSを利用します。

これらのDNSサーバーは、過去に取得したDNS情報を一定期間キャッシュしていることがあります。

そのキャッシュをもとに回答している場合、「Non-authoritative answer」と表示されることがあります。

これはエラーではありません。

通常のDNS確認ではよく表示されるものです。

ただし、DNS設定そのものが正しく登録されているかを確認したい場合は、対象ドメインの権威DNSサーバーに直接問い合わせることで、より元の設定に近い情報を確認できます。

権威DNSサーバーとは

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

たとえば、あるドメインのネームサーバーが特定のDNSサービスに設定されている場合、そのDNSサービスのサーバーが、そのドメインに対する権威DNSサーバーになります。

DNSトラブルを調べるときは、通常のキャッシュDNSだけでなく、権威DNSサーバー側の情報も確認すると原因を切り分けやすくなります。

たとえば、キャッシュDNSでは古い情報が返ってくるが、権威DNSサーバーでは新しい情報が返ってくる場合、DNS設定自体は更新されているものの、キャッシュが残っている可能性があります。

一方、権威DNSサーバーでも古い情報が返ってくる場合は、DNS管理画面での設定変更が正しく反映されていない、または編集しているDNS管理画面が間違っている可能性があります。

また、ネームサーバーが複数ある場合は、複数の権威DNSサーバーで同じ結果が返るか確認することも重要です。

一部のネームサーバーだけ古い情報を返している場合、DNSゾーンの同期不良や設定不整合が考えられます。

DNS変更後に反映が遅れる理由

DNSを変更しても、すぐに全世界で同じ結果になるとは限りません。

その理由のひとつが、DNSキャッシュです。

DNSサーバーやOS、ブラウザなどは、DNS情報を毎回ゼロから問い合わせるのではなく、一定時間キャッシュすることがあります。

これにより、表示速度や通信効率が向上します。

しかし、DNS変更直後にはこのキャッシュが影響し、古い情報が残ることがあります。

たとえば、サーバー移転でAレコードを新しいIPアドレスに変更した場合でも、あるDNSサーバーでは新しいIPアドレスが返り、別のDNSサーバーでは古いIPアドレスが返ることがあります。

これは、DNSサーバーごとにキャッシュの状態が異なるためです。

TTLとは

DNS変更の反映タイミングを理解するうえで重要なのが、TTLです。

TTLは、Time To Liveの略で、DNS情報をキャッシュしてよい時間を表します。

たとえば、TTLが1時間に設定されている場合、キャッシュDNSは通常、その情報を最大1時間程度保持できます。

ただし、実際の反映タイミングは必ずTTL通りになるとは限りません。

以下のような要素によって、見え方が変わることがあります。

• 問い合わせ先DNSサーバーのキャッシュ状況
• OSのDNSキャッシュ
• ブラウザのDNSキャッシュ
• CDNのキャッシュ
• 社内ネットワークやVPNのDNS設定
• プロキシ環境
• DNSSECの状態
• ネガティブキャッシュ

そのため、DNS変更後に「管理画面では変更したのに、まだ古いサイトが表示される」ということがあります。

このような場合は、複数のDNSサーバーで結果を比較したり、権威DNSサーバーの情報を確認したりすることで、どこに古い情報が残っているのかを切り分けやすくなります。

nslookupが役立つ実務シーン

サーバー移転後の確認

Webサイトのサーバーを移転した場合、ドメインが新しいサーバーを向いているか確認する必要があります。

nslookupを使えば、対象ドメインが現在どのIPアドレスを返しているかを確認できます。

サーバー移転後に古いサーバーのIPアドレスが返っている場合は、DNS変更がまだ反映されていない、またはDNS設定が正しく変更されていない可能性があります。

また、ルートドメインとwww付きドメインで設定が異なることもあるため、両方を確認することが重要です。

wwwあり・なしの確認

Webサイトでは、wwwありのドメインとwwwなしのドメインが別々に扱われます。

たとえば、ルートドメインは正しく表示されるのに、www付きのドメインが表示されないということがあります。

逆に、www付きは正しく表示されるのに、ルートドメインが表示されないケースもあります。

これは、それぞれのDNS設定が別々に必要になるためです。

Webサイト公開時やサーバー移転時は、wwwあり・なしの両方を確認しましょう。

メール設定の確認

独自ドメインメールを利用している場合、MXレコードやTXTレコードの確認が重要です。

特に、以下のような作業を行ったときは確認が必要です。

• Google Workspaceを導入した
• Microsoft 365を導入した
• メールサーバーを変更した
• メール配信ツールを導入した
• SPFを設定した
• DKIMを設定した
• DMARCを設定した

MXレコードが間違っていると、メールが正しいメールサーバーに届きません。

また、SPF、DKIM、DMARCが正しく設定されていないと、メールが迷惑メール扱いされたり、送信ドメイン認証に失敗したりする可能性があります。

メールマーケティングを行う場合、DNS設定は到達率にも関係するため、特に重要です。

Google Search ConsoleのDNS認証確認

Google Search Consoleでドメインプロパティを登録する場合、DNSにTXTレコードを追加して所有権を確認することがあります。

TXTレコードを追加したあと、nslookupでその値がDNSに反映されているか確認できます。

Google Search Console側で認証に失敗する場合でも、DNS上にTXTレコードが見えているか確認することで、問題がDNS反映待ちなのか、設定値のミスなのかを切り分けやすくなります。

LPツールやCMSとのドメイン連携確認

LP作成ツール、CMS、ECサービス、予約システムなどを独自ドメインで利用する場合、CNAMEレコードの設定が必要になることがあります。

たとえば、LP用のサブドメインを外部サービスに向ける場合、サービス側から指定されたCNAMEをDNSに設定します。

設定後、nslookupでCNAMEが正しく反映されているか確認できます。

もし意図したCNAMEが返ってこない場合は、DNS設定が間違っている、ネームサーバーが違う、反映待ちである、などの可能性があります。

CDN導入後の確認

Cloudflare、Akamai、Fastly、Amazon CloudFrontなどのCDNを導入すると、DNSの向き先がCDN側になります。

CDNを利用している場合、問い合わせる場所やDNSサーバーによって返るIPアドレスが異なることがあります。

これはCDNの仕組み上、正常な場合もあります。

CDNは、アクセス元に近いサーバーや最適な経路を使うため、地域やネットワークによって応答が変わることがあるためです。

そのため、CDN利用時は、IPアドレスが複数返ることや、環境によって異なる結果になることを理解しておく必要があります。

nslookupでよくあるエラーと意味

NXDOMAIN

NXDOMAINは、対象のドメイン名やホスト名が存在しないことを意味します。

主な原因は以下です。

• ドメイン名の入力ミス
• サブドメインが未設定
• DNSレコードが存在しない
• ドメインが失効している
• ネームサーバー設定に問題がある

たとえば、存在しないサブドメインを調べた場合、NXDOMAINになることがあります。

SERVFAIL

SERVFAILは、DNSサーバーが問い合わせ処理に失敗したことを意味します。

主な原因は以下です。

• 権威DNSサーバーの障害
• DNSSECの設定ミス
• ネームサーバーの応答不良
• DNSゾーン設定の不整合
• DNSサービス側の一時的な障害

NXDOMAINが「存在しない」という意味に近いのに対し、SERVFAILは「存在するかどうかを調べようとしたが、処理に失敗した」という状態です。

DNSSECの設定ミスがある場合にも、SERVFAILになることがあります。

Timeout

Timeoutは、DNSサーバーから応答が返ってこない状態です。

主な原因は以下です。

• ネットワーク接続の問題
• 指定したDNSサーバーが停止している
• ファイアウォールでDNS通信がブロックされている
• 社内ネットワークやVPNの制限
• DNSサーバーの負荷や障害

社内ネットワークやセキュリティソフト、VPN環境では、DNS通信が制限されることがあります。

No answer / No records

No answerやNo recordsは、問い合わせ自体は成功したものの、指定した種類のレコードが存在しない場合などに表示されます。

たとえば、ドメイン自体は存在していても、MXレコードが設定されていなければ、MXレコードの問い合わせでは回答がない状態になります。

表示内容はOSやnslookupの実装によって異なるため、文言が少し違っていても、意味としては「指定したレコードが見つからない」と理解するとよいでしょう。

nslookupとdigの違い

DNSを調べるツールには、nslookupのほかにdigもあります。

nslookupは、比較的シンプルにDNS情報を確認できるツールです。

Windows環境では標準で使いやすく、Web担当者やディレクターでも扱いやすいのが特徴です。

一方、digはDNSの詳細調査に向いています。

TTLや権威セクション、追加情報などを見やすく確認できるため、DNSの詳しい切り分けではdigがよく使われます。

比較すると、以下のようになります。

項目	nslookup	dig
主な用途	基本的なDNS確認	詳細なDNS調査
出力	比較的シンプル	詳細
Windows	標準で使いやすい	追加導入で利用可能
macOS / Linux	利用可能	よく使われる
TTL確認	やや見づらい場合がある	見やすい
初心者向け	比較的わかりやすい	やや専門的

基本的な確認ならnslookupで十分です。

より詳しいDNS調査を行う場合は、digも使えるようにしておくと便利です。

nslookupを使うときの注意点

hostsファイルの結果とは一致しないことがある

PCには、hostsファイルという名前解決用の設定ファイルがあります。

ブラウザや多くのアプリケーションは、OSの名前解決の仕組みを使うため、hostsファイルの影響を受けることがあります。

一方、nslookupはDNSサーバーへ問い合わせる診断ツールとして使われるため、hostsファイルの設定結果とは一致しないことがあります。

つまり、ブラウザではhostsファイルの影響で特定のIPアドレスに接続しているのに、nslookupではDNSサーバー上の別のIPアドレスが表示されることがあります。

Webサイトの移行テストや公開前確認では、この違いに注意が必要です。

ブラウザの表示結果と一致しないことがある

nslookupでは新しいDNS情報が返っているのに、ブラウザでは古いサイトが表示されることがあります。

この場合、DNS以外の要因も考える必要があります。

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

• ブラウザキャッシュ
• OSのDNSキャッシュ
• CDNキャッシュ
• サーバー側キャッシュ
• プロキシ
• VPN
• hostsファイル
• リダイレクト設定

nslookupはDNSの状態を確認するためのツールですが、Webサイトの表示結果はDNS以外の要素にも影響されます。

そのため、nslookupの結果だけで原因を決めつけないことが大切です。

CDN利用時は結果が変わることがある

CDNを使っている場合、問い合わせる地域やDNSサーバーによって返るIPアドレスが異なることがあります。

これはCDNの仕様として正常なことがあります。

CDNは、アクセス元に近い配信拠点や、最適なネットワーク経路を使ってコンテンツを配信するためです。

そのため、CDNを導入しているサイトでは、複数のIPアドレスが返ることや、環境によって結果が違うことがあります。

DNS反映チェックツールと結果が違うことがある

Web上には、世界各地のDNS反映状況を確認できるツールがあります。

これらのツールと、自分のPCで確認したnslookupの結果が違うことがあります。

これは、それぞれのツールが異なる場所、異なるDNSサーバーから問い合わせているためです。

DNS変更直後は、地域やDNSサーバーによって反映状況に差が出ることがあります。

実務での確認手順

DNSトラブルを調べるときは、次のような順番で確認すると整理しやすくなります。

まず、対象ドメインが名前解決できるか確認します。

次に、wwwあり・なしの両方を確認します。

そのうえで、Aレコード、CNAME、MX、TXT、NSなど、目的に応じたレコードを確認します。

DNS変更後であれば、複数のDNSサーバーで結果を比較します。

さらに、NSレコードを確認し、現在どのネームサーバーが使われているかを見ます。

必要に応じて、権威DNSサーバーに直接問い合わせ、DNS設定そのものが正しく登録されているかを確認します。

メール関連であれば、MX、SPF、DKIM、DMARCを確認します。

外部サービス連携であれば、CNAMEやTXT認証が正しく反映されているかを確認します。

よくあるDNS設定ミス

DNS管理画面を間違えている

もっともよくあるミスのひとつが、DNS管理画面を間違えているケースです。

たとえば、ドメインはA社で取得しているが、ネームサーバーはCloudflareに変更している場合、DNSレコードはCloudflare側で管理されています。

この状態でA社のDNS管理画面を編集しても、実際のDNSには反映されません。

DNS設定が反映されない場合は、まずNSレコードを確認し、現在どのネームサーバーが使われているかを確認しましょう。

wwwあり・なしの片方しか設定していない

ルートドメインとwww付きドメインは、DNS上では別の名前です。

そのため、片方だけ設定していると、片方だけ表示されないことがあります。

Webサイト公開時やサーバー移転時は、必ず両方を確認しましょう。

CNAMEとAレコードを混同している

Aレコードは、ドメイン名をIPアドレスに向けるレコードです。

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

外部サービスではCNAME指定が多い一方、サーバーのIPアドレスに直接向ける場合はAレコードを使うことが多いです。

また、ルートドメインには通常のCNAMEを置けないため、外部サービスの案内をよく確認する必要があります。

TXTレコードの値を間違えている

TXTレコードは、メール認証やサービス認証で使われるため、値が少し違うだけで認証に失敗することがあります。

よくあるミスは以下です。

• 余分なスペースが入っている
• ホスト名を二重に入力している
• 指定された値の一部が欠けている
• SPFレコードを複数作ってしまっている
• DKIMのセレクタを間違えている
• DMARCのホスト名を間違えている

特にSPFでは、同じドメインにSPFレコードを複数作るのではなく、通常は1つに統合する必要があります。

TTLを考慮していない

DNSを変更しても、すぐにすべての環境で新しい情報が見えるとは限りません。

TTLが長い場合、古い情報がしばらく残ることがあります。

サーバー移転やメール移行などを行う前には、事前にTTLを短くしておくと、切り替え時の影響を抑えやすくなります。

ただし、TTLを短くしても、OS、ブラウザ、CDN、社内DNSなどの影響で、完全に即時反映されるとは限りません。

nslookupを覚えるメリット

nslookupを使えるようになると、DNS関連のトラブルを自分で切り分けやすくなります。

特にWebサイト運用では、以下のようなメリットがあります。

• サイトが表示されない原因を調べやすくなる
• サーバー移転後の反映状況を確認できる
• DNS設定ミスに気づきやすくなる
• メールが届かない原因を切り分けやすくなる
• 外部サービスのドメイン認証を確認できる
• 制作会社やサーバー会社への問い合わせが具体的になる
• DNS管理画面を間違えていないか確認できる

Web担当者やマーケターの場合、DNSの専門家になる必要はありません。

しかし、nslookupで基本的なDNS情報を確認できるだけでも、トラブル対応のスピードは大きく変わります。

まとめ

nslookupは、DNS情報を確認するための基本的なツールです。

ドメインがどのIPアドレスを向いているか、メールサーバーがどこに設定されているか、TXTレコードが反映されているか、ネームサーバーが正しいかなどを確認できます。

特にWebサイト運用では、サーバー移転、サイト公開、メール設定、Google Search Console認証、メール配信ツール導入、外部CMSやLPツールとの連携など、さまざまな場面で役立ちます。

ただし、nslookupの結果を見るときは、DNSキャッシュ、TTL、権威DNS、OSやブラウザのキャッシュ、CDN、hostsファイルなどの影響も考える必要があります。

また、CNAMEには他のレコードと共存できないという制約があり、ルートドメインには通常のCNAMEを置けない点にも注意が必要です。

DNSトラブルを調べるときは、まず対象ドメインの名前解決を確認し、wwwあり・なし、Aレコード、CNAME、MX、TXT、NSなどを順番に確認しましょう。

必要に応じて複数のDNSサーバーで結果を比較し、権威DNSサーバーの情報も確認すると、原因をより正確に切り分けられます。

nslookupは、DNSの状態を確認するための実用的な基本ツールです。

以上、DNSのnslookupについてでした。

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