nslookup で DNS レコードを調べるときは、nslookup -type=種別 名前 問い合わせ先 の形で、確認したいレコードを1種別ずつ問い合わせます。サイト移転なら A・AAAA・CNAME、メール設定なら MX と TXT（SPF・DKIM・DMARC）、証明書の発行なら CAA と、作業ごとに見るべきレコードは決まっています。この記事では、作業の場面ごとに問い合わせるレコードとコマンドの書き方、表示の読み方、権威サーバーに直接聞いて「登録した値」を確かめる手順を説明します。
nslookup の基本操作やエラー表示の意味は別の記事で扱っているため、ここでは「どのレコードを、どの名前で、どこに聞くか」に重点を置きます。
問い合わせの基本形
Windows の nslookup も、Linux・macOS の nslookup（BIND に付属するもの）も、次の形で使えます。
# 種別を省くと A（環境によっては AAAA も）を問い合わせる
nslookup www.example.com
# 種別と問い合わせ先を指定する
nslookup -type=MX example.com 8.8.8.8-type= は -q= や -querytype= とも書けます。最後の引数が問い合わせ先の DNS サーバーで、省くと端末に設定された DNS サーバーを使います。名前と問い合わせ先の順番を逆にすると意図しない問い合わせになるので、「名前、問い合わせ先」の順を守ります。
表示に出る「権限のない回答」（英語版では Non-authoritative answer）は、キャッシュサーバーが答えたという意味で、エラーではありません。
サイト移転で確認するレコード
サーバーを移転するときは、Web サイトの名前が新しいサーバーを指しているかを確かめます。
# ルートドメインと www の IPv4 アドレス
nslookup -type=A example.com 8.8.8.8
nslookup -type=A www.example.com 8.8.8.8
# IPv6 アドレス（使っている場合）
nslookup -type=AAAA example.com 8.8.8.8
# www が別名（CNAME）になっているか
nslookup -type=CNAME www.example.com 8.8.8.8読むときの注意点です。
- ルートドメインと
wwwは別のレコードです。片方だけ変更して、もう片方が旧サーバーのまま、という漏れがよく起こります。 wwwが CNAME の場合、A で問い合わせると「Aliases」の行に元の名前が、「Name」と「Address」の行に置き換え先の名前と IP アドレスが表示されます。IP アドレスは置き換え先の事業者が決めているので、自分の設定は CNAME の種別で確かめます。- 旧サーバーで IPv6 を使っていて、新サーバーでは使わない場合、古い AAAA を消し忘れると IPv6 で接続する利用者だけが旧サーバーにつながります。
メール設定で確認するレコード
WordPress のお問い合わせフォームの通知メールが届かない、迷惑メールに入る、といった問題では、MX と TXT を確かめます。
# メールの受け取り先と優先度
nslookup -type=MX example.com 8.8.8.8
# SPF や各種サービスの所有確認
nslookup -type=TXT example.com 8.8.8.8
# DMARC（決まった名前の下にある）
nslookup -type=TXT _dmarc.example.com 8.8.8.8
# DKIM（selector1 はセレクター名の例。メールサービスの案内で確認する）
nslookup -type=TXT selector1._domainkey.example.com 8.8.8.8MX は、Windows 版では MX preference = 10, mail exchanger = mail.example.com のように、優先度とサーバー名が並びます。数値が小さいほど優先されます。MX に書かれた名前の A レコードも引けることを確かめておきます。
TXT は、1つの名前に複数並ぶのが普通です。v=spf1 で始まるものが2つ以上あれば SPF の設定の誤りで、受信側の評価がエラーになります。WordPress から送るメールの送信元（使っている SMTP サービスやサーバー）が SPF に含まれているかも、この表示で確かめます。DKIM の公開鍵のような長い値は、引用符で区切られた複数の文字列に分かれて表示されることがありますが、受け取る側では連結して扱うので異常ではありません。
証明書の発行で確認するレコード
Let's Encrypt などで証明書の発行や更新に失敗するときは、名前が今のサーバーを指しているかに加えて、CAA を確かめます。CAA は、そのドメインの証明書を発行してよい認証局を指定するレコードです。
# BIND 版の nslookup（Linux・macOS）
nslookup -type=CAA example.com 8.8.8.8CAA が無ければ制限は無く、どの認証局でも発行できます。CAA があり、使う認証局が含まれていなければ発行は拒否されます。Windows の nslookup は CAA のような比較的新しい種別を名前で受け付けない、または中身を読める形で表示しない場合があります。そのときはサーバー上の BIND 版の nslookup や dig を使います。
ネームサーバーとゾーンの情報を確認する
DNS 事業者を変えたときや、どこで DNS を管理しているか分からないときは、NS と SOA を問い合わせます。
# このドメインの権威サーバーの一覧
nslookup -type=NS example.com 8.8.8.8
# ゾーンの管理情報
nslookup -type=SOA example.com 8.8.8.8SOA の表示では、primary name server（主となるネームサーバー）、serial（シリアル番号）、default TTL などが並びます。シリアル番号はゾーンを変更するたびに増える番号で、権威サーバーごとに比べると同期の遅れが分かります。ただし、DNS 事業者によってはシリアル番号の付け方が独自で、変更しても増えないように見える場合があります。
権威サーバーに直接聞いて、登録した値を確かめる
ここまでの例は、公開 DNS のキャッシュサーバーに聞いているため、変更直後は古い値が返ることがあります。「管理画面で登録した値が正しく保存されているか」を確かめるには、NS で調べた権威サーバーを問い合わせ先に指定します。
# 権威サーバー（名前は例）に直接聞く
nslookup -type=A www.example.com ns1.example.net権威サーバーが答えた場合は「権限のない回答」の表示が出ません。この答えが新しい値なら、登録は済んでおり、残りはキャッシュの入れ替わりを待つだけです。古い値なら、変更が保存されていないか、別の事業者のゾーンを編集しています。権威サーバーが複数あるときは、1台ずつ問い合わせて値がそろっているかも確かめます。
つまずきやすい点
- **
-type=ANYは使わない**：多くのサーバーは ANY の問い合わせに全レコードを返さず、最小限の答えしか返しません（RFC 8482）。確認したい種別を1つずつ問い合わせます。 - hosts ファイルは使われない：nslookup は DNS サーバーに直接問い合わせるため、hosts ファイルや OS の DNS キャッシュを参照しません。移転前の確認で hosts を書き換えている場合、ブラウザと nslookup の結果は違って当然です。
- 末尾のピリオド：社内ネットワークでは、端末の DNS サフィックスが付いた名前が先に問い合わせられることがあります。
www.example.com.のように末尾にピリオドを付けると避けられます。 - 画面の表記は環境で違う：Windows の表示言語や版、BIND 版かどうかで、項目名や並びが変わります（2026年10月現在）。例と見た目が違っても、項目の意味で読みます。
まとめ
nslookup -type=種別 名前 問い合わせ先の形で、確認したいレコードを1種別ずつ問い合わせます。- サイト移転では A・AAAA・CNAME を、ルートドメインと
wwwの両方で確かめます。 - メール設定では MX と TXT を確かめ、DMARC は
_dmarc、DKIM はセレクター._domainkeyの名前で問い合わせます。SPF が2つあれば誤りです。 - 証明書の発行の失敗では CAA を確かめます。Windows 版で扱えない場合は BIND 版や dig を使います。
- 登録した値の確認は、NS で調べた権威サーバーを問い合わせ先に指定して行います。