このツールの仕組み
あなたのブラウザが、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形式だからです。
使い方
example.comやmail.example.comのようなドメイン名を入力します。https://やパスは付けません。- レコード型をA、AAAA、MX、TXT、NS、CNAME、CAA、SOAから選びます。「すべて」を選ぶと、この8種類を順に問い合わせます。
- リゾルバーとしてCloudflareかGoogle Public DNSを選びます。
- 検索を実行し、レコードを読む前に応答コードを確認します。
- 結果を残したり共有したりするには、ページのアドレスをコピーします。名前、レコード型、リゾルバーは
#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.1digの詳しい出力では、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の答えは、レコードの編集やキャッシュの期限切れによって変わります。表示されるのは、問い合わせた時点で選んだリゾルバーが返した内容であり、すべてのリゾルバーが同じ内容を返すとは限りません。