# DNSルックアップ CloudflareまたはGoogle Public DNSを使って、任意のドメインのA、AAAA、MX、TXT、NS、CNAME、CAA、SOAレコードを調べられます。問い合わせはHTTPSで、あなたのブラウザからリゾルバーへ直接届きます。 ## 要点 DNSの応答には応答コードが付きます。レコード付きのNOERRORは答えがあったこと、NXDOMAINはどのレコード型についてもその名前が存在しないこと、レコードなしのNOERROR（NODATA）は名前は存在するが問い合わせた型のレコードがないことを示します（RFC 2308）。どのレコードにもTTLがあり、リゾルバーがキャッシュに保持してよい秒数を表します。上限は2,147,483,647秒です（RFC 2181）。 ### 調べ方 あなたのブラウザは、選んだリゾルバーへDNS over HTTPS（RFC 8484）で直接問い合わせます。使うのはJSON形式のインターフェースで、`cloudflare-dns.com/dns-query`または`dns.google/resolve`に名前とレコード型を渡します。応答の`Status`は応答コード、`AD`はリゾルバーがDNSSECを検証したかどうかを示し、各レコードには名前、型、TTL、データが入っています。ASCII以外の文字を含む名前は、先に`xn--`形式へ変換します。 ### 例 2026年10月10日に`example.com`のMXレコードをCloudflareに問い合わせたところ、応答はNOERRORでDNSSEC検証済み、レコードは`0 .`の1件、TTLは219秒でした。優先度0で宛先が`.`のレコードはnull MX（RFC 7505）と呼ばれ、そのドメインがメールを一切受け付けないことを宣言しています。TTLがきりのいい数字でなく219だったのは、レコードがすでにキャッシュされていて、残り時間が減っていく途中だったためです。 ### 制限事項 - 表示されるのは、選んだパブリックリゾルバーが返した答えです。自分の環境のリゾルバーや社内ネットワーク、スプリットホライズンDNSでは別の答えになることがあります。 - キャッシュされた答えは、TTLが切れるまで変更に追いつきません。 - 選べるのはよく使われる8種類のレコード型で、DS、DNSKEY、SRV、PTRなどは調べられません。 - DNS over HTTPSをブロックするブラウザ拡張機能やネットワークフィルターがあると、検索できません。 ### 出典 - [RFC 1035: Domain Names, Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035)：レコードの種類とメッセージの形式。 - [RFC 2308: Negative Caching of DNS Queries](https://www.rfc-editor.org/rfc/rfc2308)：NXDOMAINとNODATA。 - [RFC 2181, section 8: TTLs](https://www.rfc-editor.org/rfc/rfc2181#section-8)：2,147,483,647秒という上限。 - [RFC 8484: DNS Queries over HTTPS](https://www.rfc-editor.org/rfc/rfc8484)：DNS over HTTPS。 - [RFC 7505: A "Null MX" No Service Resource Record](https://www.rfc-editor.org/rfc/rfc7505)：MXの「0 .」が意味するもの。 - [Cloudflare: DNS over HTTPS, JSON format](https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/make-api-requests/dns-json/)：このページが使うリゾルバーのインターフェース。 - [Google Public DNS: JSON API](https://developers.google.com/speed/public-dns/docs/doh/json)：もう一方のリゾルバーのインターフェース。 ## このツールの仕組み あなたのブラウザが、Cloudflare（1.1.1.1）またはGoogle Public DNS（8.8.8.8）に対し、リゾルバーが提供するJSON形式のDNS over HTTPSインターフェースを使って、ドメイン名に登録されたレコードを問い合わせます。このページは、返ってきた応答を見やすく並べます。 レコードごとに名前、型、TTL、データを表示します。TTLは秒数と読みやすい時間の両方で示すので、300なら5分とも表示されます。ほかに、応答コード（NOERROR、NXDOMAIN、SERVFAIL、REFUSED）、リゾルバーがADフラグ（DNSSEC検証済み）を立てたかどうか、ブラウザ側で問い合わせにかかった時間もわかります。TXTの文字列は省略せずに全文を表示するので、SPFやDMARC、長い所有確認用トークンを見るときに役立ちます。 国際化ドメイン名も扱えます。`bücher.example`は送信前に`xn--bcher-kva.example`へ変換されます。DNSに実際に登録されているのは、このASCII形式だからです。 ## 使い方 1. `example.com`や`mail.example.com`のようなドメイン名を入力します。`https://`やパスは付けません。 2. レコード型をA、AAAA、MX、TXT、NS、CNAME、CAA、SOAから選びます。「すべて」を選ぶと、この8種類を順に問い合わせます。 3. リゾルバーとしてCloudflareかGoogle Public DNSを選びます。 4. 検索を実行し、レコードを読む前に応答コードを確認します。 5. 結果を残したり共有したりするには、ページのアドレスをコピーします。名前、レコード型、リゾルバーは`#example.com/MX/google`のように`#`の後ろに入るので、同じ検索をブックマークしたり同僚に送ったりできます。 問い合わせはiseeu.ccのサーバーを通りません。ブラウザが選んだリゾルバーと直接やり取りするため、そのリゾルバーにはあなたのIPアドレスと調べた名前が見え、その扱いはリゾルバーの運営元が定めるプライバシーポリシー次第です。Googleのリゾルバーは、近くの答えを選べるように、一部の権威サーバーへあなたのIPアドレスの一部を渡すことがあります（EDNS Client Subnet）。Cloudflareのリゾルバーは渡さないと説明しています。`#`より後ろの部分はどのサーバーにも送信されません。また、iseeu.ccはIPアドレスや調べた内容のログも訪問者のデータベースも持たず、Cookieも広告も使いません。 ## こんなときに - **変更直後の確認。**新しいAレコードを両方のリゾルバーで調べます。片方がまだ古いアドレスを返すなら、そのTTLから、キャッシュがあとどれくらい残るかの目安がわかります。 - **メールが届かないとき。**MX、ドメインに設定した`v=spf1`のTXT、`_dmarc.example.com`のTXTを確認します。SPFレコードを別々に2つ置いてしまうのはよくある間違いで、受信側はエラーとして扱います。 - **TLS証明書を申請する前に。**公的な認証局は、発行前にCAAを確認しなければなりません。以前使っていた認証局だけを指定したCAAレコードが残っていると、申請は通りません。 - **ドメインの所有確認。**外部のサービスからTXTのトークンを求められたら、TXTを調べて文字列を1文字ずつ照らし合わせます。 - **DNSサービスの引っ越し。**NSを見れば、ドメインがどこに委任されているかがわかります。SOAのシリアル番号は通常、編集のたびに変わるので、配信されているゾーンが自分の編集したものかを確かめる手がかりになります。 - **フィルタリングや古いキャッシュの発見。**CloudflareとGoogleの答えが一致するのに、普段使っているリゾルバーに向けた`dig`ではNXDOMAINや別のアドレスが返る場合、違いの原因はゾーンではなく手元のリゾルバーにあります。 ## 応答の読み方 **レコードのないNOERROR**はよくNODATAと呼ばれ、名前は存在するのに要求した型のレコードがない状態です。IPv4しか持たないホストへのAAAAがその例です。下の階層に何かがあるおかげで存在している名前もこれに含まれます。`a.b.example.com`だけが定義されているときの`b.example.com`がそうです。**NXDOMAIN**はさらに強い意味で、その名前はどの型についても存在しません。否定応答もゾーンのSOAレコードで決まる期間だけキャッシュされるので、作成前に一度問い合わせた名前は、しばらく存在しないものとして表示され続けることがあります。 **SERVFAIL**は、リゾルバーが答えを作れなかったことを意味します。どちらのリゾルバーもDNSSECを検証するため、よくある原因は信頼の連鎖が切れていることです。たとえば、鍵の異なるDNSサービスへ移ったのに、レジストラにDSレコードが残ったままになっているケースです。権威サーバーに到達できないときにも起こります。**REFUSED**はサーバーが応答を拒んだことを示しますが、この2つのリゾルバーではめったにありません。ADフラグには署名済みのドメインが必要です。ほとんどのドメインは署名されていないので、ADフラグがないのは普通のことです。 名前がCNAMEの場合、応答にはまず別名が、続いて参照先のレコードが並びます。ゾーンの頂点（Apex）にはCNAMEを置けません。Apexで同じような機能を提供するDNSサービスは通常のAレコードとAAAAレコードを公開するので、ここでもそれが表示されます。MXのデータは`10 mail.example.com.`のように優先度とホストの組で、数値の小さいほうが先に使われます。`0 .`だけの場合はnull MXで、そのドメインはメールを受け付けません。 ## TTLとキャッシュ、いわゆる「浸透」 DNSの変更は、DNS事業者から外へ向かって染み出していくものではありません。各リゾルバーはTTLが許す間だけコピーを保持し、期限が来たら問い合わせ直します。表示されるTTLは公開時の値から減っていく残り時間で、3,600で公開され20分前にキャッシュされたレコードなら、約2,400と表示されます。編集後、最大でTTL1回分の間は、新しい値を持つリゾルバーと古い値を持つリゾルバーが混在します。変更をすばやく行き渡らせたいなら、先にTTLを下げ、元のTTL以上の時間を待ってから編集します。ネームサーバーの変更にはさらに時間がかかります。親ゾーンのNSレコードには1〜2日のTTLが付いていることが多いためです。2つのリゾルバーの答えが違っても、必ずしも異常ではありません。地域に応じたDNSや負荷分散は、問い合わせがどこから来たように見えるかに合わせて答えを変えます。 ### 同じ問い合わせをターミナルで ``` dig +short example.com MX @1.1.1.1 dig _dmarc.example.com TXT @8.8.8.8 dig +dnssec example.com A @1.1.1.1 nslookup -type=SOA example.com 8.8.8.8 Resolve-DnsName example.com -Type MX -Server 1.1.1.1 ``` `dig`の詳しい出力では、flagsの行にある`ad`が、ここで表示しているのと同じDNSSECの印です。ただし重要な違いが1つあります。`dig`はポート53の通常のDNSを使い、ネットワークによってはそれを横取りして自分で応答します。このページはHTTPSを使うため、同じリゾルバーに対して`dig`とこのページの結果が食い違うなら、ネットワーク上の何かが代わりに応答している可能性が高いと考えられます。 ## よくいただく質問 **同じドメインなのに、CloudflareとGoogleで返ってくるIPアドレスが違うのはなぜですか？** 大規模なサイトの多くは、地域に応じたDNSや負荷分散を使い、問い合わせがどこから来たように見えるかで答えを変えています。GoogleのリゾルバーはEDNS Client Subnetを使ってあなたのIPアドレスの一部を権威サーバーに渡すことがあり、その場合の答えはあなたのネットワーク向けに調整されます。一方、Cloudflareの答えはCloudflare自身のサーバーの場所で決まります。異なる2つのアドレスがどちらも正しいことは珍しくありません。気にする必要があるのは、片方がドメインの所有者がすでに使わなくなったホストのアドレスだった場合だけです。 **1時間前にレコードを変更したのに、古い値のままなのはなぜですか？** 古いレコードをキャッシュしたリゾルバーは、TTLが切れるまでそのコピーを返し続けます。ここに表示されるTTLは、そのコピーの残り時間です。古いレコードのTTLが86,400秒なら、キャッシュは最長で1日残ります。もう一方のリゾルバーでも問い合わせてみてください。そちらで新しい値が出れば、ゾーンの設定は正しく、キャッシュの期限切れを待っているだけです。 **NXDOMAINと、レコードが1件も返らない場合は何が違うのですか？** NXDOMAINは、その名前がどのレコード型についても存在しないという意味です。一方、レコードのないNOERRORは、名前は存在するものの、問い合わせた型のレコードがないことを示します。IPv4アドレスしか持たないホストにAAAAを問い合わせた場合がその例です。作ったばかりの名前がNXDOMAINになるときは、名前ができる前にキャッシュされた否定応答を、リゾルバーがまだ持ち続けているのかもしれません。 **調べたドメイン名がiseeu.ccに知られることはありますか？** ありません。問い合わせはあなたのブラウザからCloudflareまたはGoogleへHTTPSで直接送られ、iseeu.ccのサーバーは通りません。ただし、選んだリゾルバーにはあなたのIPアドレスと調べた名前が見え、その扱いはリゾルバーの運営元が定めるプライバシーポリシー次第です。ページのアドレスの#より後ろに残る検索内容は、どのサーバーにも送信されません。iseeu.ccはIPアドレスや調べた内容のログも訪問者のデータベースも持たず、Cookieも広告も使いません。 **サブドメインのないドメイン（Zone Apex）にCNAMEを設定できないのはなぜですか？** ゾーンの頂点にはSOAレコードとNSレコードが必要ですが、CNAMEは同じ名前でほかのレコードと共存できない決まりだからです。DNSサービスによっては、会社ごとにALIAS、ANAME、フラットニング（flattening）などと呼び名は違いますが、Apex用のエイリアス機能を用意しています。これは参照先を代わりに引き、通常のAレコードとAAAAレコードとして公開する仕組みです。このページで調べると、CNAMEではなくそのアドレスが表示されます。 **DNSSECで検証済みの印が付いていません。設定に問題があるのでしょうか？** たいていは問題ありません。リゾルバーがADフラグを立てるのは、ドメインが署名されていて、ルートから順に署名を検証できた場合だけです。ほとんどのドメインは署名されていないため、ADフラグなしで返ってきます。気にすべきなのは、署名済みのドメインが検証に失敗するケースです。そのとき、検証を行うリゾルバーは答えの代わりにSERVFAILを返します。原因としてよくあるのは、レジストラに登録したDSレコードがゾーンの鍵と合わなくなっていることです。 **このツールで、ドメインのメール設定（SPFやDMARC）はどう確かめますか？** まずドメインのMXを調べ、どのホストがメールを受け取るかを確認します。次に同じ名前のTXTを調べ、v=spf1で始まる文字列がちょうど1つだけあるかを見ます。続いて、ドメインの前に_dmarcを付けた名前（例：_dmarc.example.com）のTXTを調べると、DMARCのポリシーが読めます。DKIMの鍵は_domainkeyの下のセレクター名に置かれているので、送信に使っているサービスからセレクター名を確認する必要があります。 DNSの答えは、レコードの編集やキャッシュの期限切れによって変わります。表示されるのは、問い合わせた時点で選んだリゾルバーが返した内容であり、すべてのリゾルバーが同じ内容を返すとは限りません。 ## iseeu.ccのほかのツール - [Whois検索](https://iseeu.cc/ja/whois/): ドメイン名、IPアドレス、AS番号の登録情報を調べます。 - [Punycode変換](https://iseeu.cc/ja/punycode/): 日本語ドメインなどの国際化ドメイン名とxn--形式を相互に変換します。 - [メールヘッダー解析](https://iseeu.cc/ja/email-header/): Receivedの経路をたどり、SPF・DKIM・DMARCの判定結果を読み取ります。 - [セキュリティヘッダーチェック](https://iseeu.cc/ja/security-headers/): URLのレスポンスヘッダーを取得し、HSTSやCSPなどを採点します。 - [IPアドレス確認](https://iseeu.cc/ja/): グローバルIP、おおよその地域、プロバイダ、ヘッダー、TLS、リークテストを1ページで確認できます。 [すべてのツールを見る](https://iseeu.cc/ja/tools/) 最終更新：2026-10-11 元のページ：https://iseeu.cc/ja/dns-lookup/