DNS確認・DNS検索
ドメイン、ホスト、IPアドレスのDNSレコードを無料で確認できるDNSツールです。ドメイン自身のネームサーバーが返すすべてのDNSレコードを、GoogleとCloudflareのキャッシュと並べて表示するので、変更がすべての人に届いたかどうかがわかります。
ドメイン、ホスト、URL、メールアドレス、IPアドレスを入力できます。検索のたびにサーバーへ問い合わせ直し、当サイトのキャッシュは使いません。
調べ方 4ステップ · 約1秒
- ルート13台のルートサーバー
- TLDレジストリのサーバー
- ネームサーバードメイン自身のサーバー
- 応答全レコードタイプ
- Google8.8.8.8
- Cloudflare1.1.1.1
検索のたびに経路をたどります。ルートサーバーからTLDのレジストリ、そしてドメイン自身のネームサーバーへ進んで現在のレコードを取得し、さらにGoogleとCloudflareがキャッシュしている内容も問い合わせます。
DNS検索でわかること
DNSルックアップ（DNS lookup）とは、ドメインネームシステム（DNS）に名前の情報を問い合わせることです。WebサイトのIPアドレス（AとAAAA）、メールサーバー（MX）、ネームサーバー（NS）、テキストレコード（TXT）などがわかります。このDNSチェックは3か所に同時に問い合わせます。現在の正しい情報を持つドメイン自身の権威DNSサーバーと、世界有数の利用者を抱え、何百万人もの人にキャッシュのコピーを返している2つのパブリックリゾルバー、Google Public DNSとCloudflare 1.1.1.1です。
両者の結果が食い違っていれば、DNSの変更が「反映されない」よくある原因が見つかったことになります。リゾルバーがまだ古い応答を持っていて、レコードのTTLが切れるまでそれを保持しているのです。結果には、どのリゾルバーが、何をまだ返していて、更新まであとどれくらいかが表示されます。
経路ルートサーバーからドメインのTLD、そしてドメイン自身のネームサーバーまで、各サーバーの応答内容と応答時間を示します。最新とキャッシュドメインのネームサーバーから取得した各レコードタイプを、GoogleとCloudflareのコピーおよびその残り時間と並べて表示します。各レコードの解説値の意味を言葉で説明します：メールの優先度、SOAのタイマー、CAAのルール、TXTトークンの背後にあるサービス。DNSSECとメール応答が署名・検証されているかどうかと、ドメインのMX、SPF、DMARCの設定を示します。DNSレコードの種類と意味
ドメインのゾーンにはさまざまなタイプのレコードがあり、それぞれが名前、TTL、値を持ちます。DNSレコードの確認で表示されるのは次のタイプです：
| タイプ | 内容 | 値の例 |
|---|---|---|
| A | 名前に対応するIPv4アドレス。ブラウザーの接続先です。 | 203.0.113.20 |
| AAAA | 名前に対応するIPv6アドレス。 | 2001:db8::20 |
| CNAME | 別名。この名前は別の名前と同じなので、そちらを検索するよう示します。ほかのレコードと共存できないため、ドメインの頂点（apex）には置けません。 | www.example.com → example.com |
| MX | ドメインのメールサーバーと優先度。数値が最も小さいものから試行されます。優先度0で「.」を指すMXが1つだけの場合、そのドメインはメールを受け付けません。 | 10 mail.example.com |
| NS | ドメインのレコードを保持しているネームサーバー。 | ns1.example.net |
| TXT | 自由形式のテキスト。メール用のSPF、DMARC、DKIMや、Google、Microsoftなどにドメインの所有を証明するトークンに使われます。 | v=spf1 include:_spf.example.net -all |
| SOA | ゾーンの権威の開始（Start of Authority）。プライマリサーバー、連絡先、シリアル番号と、リフレッシュ、リトライ、有効期限、ネガティブキャッシュの各タイマーです。 | ns1.example.com hostmaster.example.com 2026102001 7200 3600 1209600 300 |
| CAA | ドメインの証明書を発行できる認証局（CA）。 | 0 issue "letsencrypt.org" |
| HTTPS | 最初のリクエストの前に接続方法を伝えます：HTTP/3への対応、ポート、アドレスヒント。Chrome、Firefox、Appleのシステムが問い合わせます。 | 1 . alpn=h3,h2 |
| SRV | _sip._tcpのような名前の下で、サービスが動いている場所（優先度、重み、ポート、ホスト）を示します。 | 10 5 5060 sip.example.com |
| PTR | IPアドレスに対応する名前。逆引きDNSです。 | 20.113.0.203.in-addr.arpa → host.example.com |
| DSDNSKEY | DNSSEC：ゾーンの公開鍵（DNSKEY）と、親ゾーンにあるそのフィンガープリント（DS）。これにより署名がルートまで連鎖します。 | 2371 13 2 3299… |
DNSの名前解決はどのように行われますか？
お使いのデバイスがインターネット全体を探すわけではありません。1台のリゾルバー（通常はISPのものか、GoogleやCloudflareのようなパブリックDNS）に問い合わせ、リゾルバーが名前に沿って委任をたどり、答えを持つサーバーが応答するまで進みます：
- 1
ルートサーバーに問い合わせる
キャッシュが空の場合、リゾルバーは13のルートサーバー（aからm、12の組織が運用）のいずれかから始めます。ルートはexample.comを知りませんが、.comを誰が運用しているかは知っています。利用の多いリゾルバーはこれをすでに知っているため、この手順を省略します。
- 2
TLDへの委任をたどる
.comのサーバーもexample.comのレコードは持っていません。リゾルバーを、NSレコードに記載されたドメイン自身のネームサーバーへと案内します。
- 3
権威ある応答を得る
ドメインのネームサーバーは、AA（authoritative answer、権威ある応答）フラグを立てて応答します。これが、所有者が公開したとおりのレコードです。
- 4
TTLの間キャッシュする
リゾルバーはTTLが示す期間だけ応答を保持し、期限が切れるまで、問い合わせてきたすべての人に、TTLがカウントダウンしていく同じコピーを返します。
このツールは、Cloudflareのネットワークからこの経路を自ら順にたどるため、各ステップを確認できます。そのうえで、GoogleとCloudflareにキャッシュの内容を問い合わせます。
ルートからの経路
- ルートa.root-servers.net16 ms · 委任先：.comの13台のサーバー
- .COMa.gtld-servers.netVerisign · 150 ms · 委任先：ns1–ns2.example.com
- ネームサーバーns1.example.comexample.com · 203.0.113.53 · 20 ms権威ある応答（AA） · 1本のTCP接続で11種類
- 応答レコード8件・7種類NOERROR（31 ms） · 4種類は空（CNAME, HTTPS, DNSKEY, DS）
- Google Public DNS8.8.8.8同じレコード · 最も古いコピーの更新まで 2:58
- Cloudflare DNS1.1.1.1同じレコード · 最も古いコピーの更新まで 4:04
DNSの変更が反映されず、古いレコードが表示されるのはなぜですか？
リゾルバーがキャッシュしているからです。すべてのレコードには秒単位のTTL（time to live、生存時間）があり、レコードを取得したリゾルバーはその時間が切れるまで自分のコピーを返し続け、切れてから改めて問い合わせます。DNSホスティングでレコードを変更すると、権威ある応答はすぐに変わりますが、古い応答をすでに持っているリゾルバーは、期限が切れるまでそれを保持します。
つまり、変更にかかる時間は固定の24〜48時間ではなく古いレコードのTTLで決まり、多くの場合それより短くなります。TTLは上限であり、Google Public DNSがレコードを保持するのは最長でも約6時間です。レコードがないこともキャッシュされます。「その名前は存在しない」「そのタイプのレコードはない」という結果は、SOAレコードのTTLとその最後のフィールドであるMINIMUMのうち、小さいほうの期間保持されます。失敗でさえ、最長5分間キャッシュされます。
できること
- ここで権威ある応答を確認する。ドメイン自身のネームサーバーが新しい値を返していれば、変更は完了しています。遅れているのはキャッシュだけです。
- 予定している変更の前にTTLを下げる。少なくとも古いTTL1回分前に下げておけば、キャッシュがすぐに古い値を手放します。変更後は元に戻してください。
- GoogleとCloudflareにコピーの破棄を依頼する。どちらも、キャッシュ内の名前を更新できる公開ページを用意しています（Google、Cloudflare）。
- ご自身のコンピューターのキャッシュを消去する。Windowsでは
ipconfig /flushdnsを実行します。
- 権威DNSns1.example.com · AAフラグ
ドメイン自身のネームサーバー。ここが返すものが現在のレコードです。ここで変更すれば、ほかもあとに続きます。
- キャッシュ8.8.8.8 · TTLがカウントダウン中
リゾルバーのコピーで、TTLが切れるまで返され続けます。世界の大半の人が見ているのはこれであり、変更が「反映されない」ように見える原因です。
- ご自身のキャッシュお使いのコンピューター · ルーター
コンピューターとルーターもコピーを保持しています。コンピューターのものはフラッシュで消去でき、ルーターのものは自然に期限切れになります。
nslookupとdigでDNSを確認するコマンド
同じ検索はターミナルからも実行できます。nslookupはWindows、macOS、Linuxに、digはmacOSとほとんどのLinuxに、Resolve-DnsNameはWindowsのPowerShellに付属しています。上の結果には、実行した検索とまったく同じコマンドが表示されます。
| 調べる内容 | nslookupコマンド | digコマンド |
|---|---|---|
| Aレコードを確認 | nslookup example.com | dig example.com |
| メールサーバー | nslookup -type=MX example.com | dig example.com MX |
| テキストレコード | nslookup -type=TXT example.com | dig example.com TXT |
| 特定のリゾルバーに問い合わせる | nslookup example.com 8.8.8.8 | dig @8.8.8.8 example.com |
| 逆引きDNS | nslookup 8.8.8.8 | dig -x 8.8.8.8 |
| 値だけを表示 | — | dig +short example.com |
| ルートからの経路 | — | dig +trace example.com |
nslookupの出力にある「Non-authoritative answer」（日本語版Windowsでは「権限のない回答」）は、応答がドメイン自身のネームサーバーではなく、リゾルバーから返されたことを意味します。権威ある応答を得るには、ドメインのネームサーバーの1つをサーバーとして指定します：nslookup example.com ns1.example.net
ANYはすべてのレコードという意味ではありません。サーバーは1つのタイプだけを返すことも、「RFC8482」とだけ書かれたプレースホルダーを返すこともあり、1.1.1.1は拒否します。このツールはタイプごとに個別に問い合わせます。macOSに付属のdigはHTTPSレコードを知らないため、代わりにTYPE65を指定してください。
DNSエラー：NXDOMAIN、SERVFAIL、REFUSEDの意味
DNSの応答にはすべてレスポンスコードが付いています。空の結果が必ずしもエラーとは限らず、コードを見れば確認すべき場所がわかります：
| 応答 | 意味 | 確認すること |
|---|---|---|
| NOERROR | 名前が存在し、そのタイプのレコードが返されました。 | 特になし。値を比較してください。 |
| NODATA | 名前は存在しますが、このタイプのレコードはありません。独自のコードではなく、空の応答を伴うNOERRORです。 | 存在すべきレコードなら、DNSホスティングで追加してください。 |
| NXDOMAIN | その名前はまったく存在せず、その下の名前も存在しません。 | つづり、ドメインが登録済みで期限切れでないこと、サブドメインなら作成済みであること。 |
| SERVFAIL | リゾルバーが有効な応答を得られませんでした。ネームサーバーが失敗したか、DNSSECの検証に失敗しています。 | DNSSECの判定と、ドメインのネームサーバーが応答するかどうか。 |
| REFUSED | サーバーがこの問い合わせに答えません。そのドメインの権威サーバーではなく、あなたのために再帰問い合わせもしません。 | NSレコードが、ゾーンをホストしているサーバーを指していること。 |
| Timeout | まったく応答がありません。 | ネームサーバーがダウンしていないか、ブロックされていないか、アドレスが間違っていないか。 |
DNSSEC：安全、未署名、破損の違い
DNSSECはゾーンのレコードに署名し、リゾルバーがレコードが偽造されていないことを証明できるようにします。親ゾーンはドメインの鍵のフィンガープリントであるDSレコードを公開し、ドメインはDNSKEYレコードで鍵を公開するため、署名はルートまで連鎖します。Google Public DNSとCloudflare 1.1.1.1は、どちらもDNSSECを検証します。
- DNSSEC：安全
安全
署名されており、Googleの検証リゾルバーが署名を確認しました。その応答には、検証に成功したことを示すAD（authenticated data）ビットが付いていました。
- DNSSEC：未署名
未署名
親ゾーンにDSレコードがなく、ゾーンは署名されていません。通常どおり名前解決されますが、応答が本物であることは証明できません。
- DNSSEC：破損
破損
検証に失敗するため、検証するリゾルバーはSERVFAILを返し、その利用者からはドメインに到達できません。ただし、検証を無効にして問い合わせると、データは返ってきます。典型的な原因は、新しいDNSホスティングへの移行後に、親ゾーンのDSがゾーンのどの鍵とも一致しなくなることです。
DNS検索で確認できるメールのレコード
ドメイン宛てのメールはMXサーバーに届き、受信側はメールを信頼する前にTXTレコードを確認します。SPFはドメインとして送信を許可されたサーバーを1つのレコードに列挙し、そのレコードが発生させるDNSルックアップは最大10回までです。DMARCは_dmarcに置かれ、認証に失敗したメールの扱いを指定します。サブドメインにDMARCがない場合は、名前を上にたどって探します（RFC 9989、2026年5月以降）。MTA-STSは_mta-stsに置かれ、送信者にTLSでの配信を求めます。結果ではこれらすべてを読み取り、MXホストの背後にあるメールプロバイダーも表示します。
1つのレコードをさらに詳しく確認するには、MX検索、SPFチェッカー、DMARCチェッカーを使ってください。
DNS検索API
CORSに対応した無料のエンドポイントが2つあり、ブラウザーからも使えます。/api/dns-queryは1つのリゾルバーに1つのタイプを問い合わせ、以前のAPIのフィールドを維持しています。/api/dns-lookupは、このページの完全な検索結果をJSON Linesでストリーミングします。
$ curl -X POST https://dnsrobot.net/api/dns-query \
-H "Content-Type: application/json" \
-d '{"domain": "google.com", "recordType": "MX", "dnsServer": "8.8.8.8"}'
{
"status": "success", "responseTime": 4,
"resolvedIPs": ["10 smtp.google.com"],
"dnsServer": "8.8.8.8", "recordType": "MX", "domain": "google.com", …
}$ curl "https://dnsrobot.net/api/dns-lookup?domain=google.com"
{"t":"start","name":"google.com","kind":"name","types":["A","AAAA","CNAME","MX",…]}
{"t":"hop","hop":{"zone":".","server":"a.root-servers.net","ms":16,"outcome":"referral",…}}
{"t":"answers","source":"google","server":"dns.google","sets":[{"type":"A",…}]}
{"t":"answers","source":"auth","server":"ns1.google.com","sets":[…]}
{"t":"dnssec","verdict":"unsigned",…}
{"t":"done","ms":57}