DNSレコード確認
ドメインまたはホスト名を入力すると、DNSがそれについて公開している内容を、レコードの種類ごとにすべて読めます。各ブロックにはその種類の役割を書き添え、互いに矛盾する数少ないレコードも指摘します。
一つの名前に、何種類もの答え
DNSはよく「インターネットの電話帳」と呼ばれます。このたとえが成り立つのは、一つの名前に何行も載っている電話帳を想像した場合です。住所の行、郵便受けの行、書類を預かる公証人の行、という具合です。ブラウザが尋ねるのは住所だけです。メールサーバーが尋ねるのは郵便受けだけです。行の種類の一つひとつがレコードタイプで、DNSへの問い合わせでは必ずドメインと欲しい種類の両方を指定します。
だからこそ、ブラウザではドメインが問題なく表示されるのに、メールは戻ってくる、ということが起こります。両者は別々のレコードに頼っていて、それぞれ別に、しばしば別の人が編集しています。
このツールが読むレコードタイプ
| タイプ | 中身 | 読む側 |
|---|---|---|
A、AAAA | サーバーのIPv4アドレスとIPv6アドレス | ブラウザ、その他その名前に接続するすべて |
CNAME | この名前の代わりに使う別の名前 | リゾルバー（転送先で最初からやり直します） |
MX | メールを受け付けるサーバーと、それぞれの優先度 | 送信側のメールサーバー |
NS | ゾーンを保持するネームサーバー | 正しい情報源を探すリゾルバー |
SOA | ゾーンのプライマリサーバー、連絡先、シリアル番号、各種タイマー | セカンダリネームサーバー |
TXT | 自由なテキスト：SPF、DKIMの鍵、所有確認コード | メールの受信側と、登録したサービス |
CAA | そのドメインの証明書発行を許可された認証局 | 発行前の認証局 |
DS、DNSKEY | ゾーンに署名する鍵と、親ゾーンが持つその指紋 | DNSSECを検証するリゾルバー |
これらはすべて公開リゾルバーに同時に問い合わせ、途中で失われた問い合わせには予備のリゾルバーを使います。DMARCポリシーも調べます。DMARCはTXTレコードですが、_dmarc.example.comという専用の名前に置かれるため、ドメインに対する普通のTXT検索では決して表示されません。
TXTの値は既知の形式と照合します。v=spf1で始まる値はSPF、google-site-verification=やMS=はGoogleやMicrosoft 365の所有確認、という具合に数十のサービスを識別します。メールサーバーやネームサーバーのホストも同じように照合するので、aspmx.l.google.comはGoogle Workspace / Gmailと表示されます。
TTL列からわかること
どのレコードにも秒単位の有効期間（TTL）があります。リゾルバーが再問い合わせまで答えを保持してよい時間で、レコードを変更したあと訪問者が古い値を受け取り続けうる最長の時間でもあります。TTLが3600なら最大1時間、300なら5分の待ちです。
すでにレコードを保持しているリゾルバーは、設定した値ではなく残り時間を返します。そのため2回尋ねると3600のあと2954と出ることがあります。この混乱を避けるため、このツールは可能な限りゾーン自身のネームサーバーにTTLを尋ね、結果の下の注記にどちらの情報源を使ったかを書きます。
参考として触れる状況が二つあります。60秒未満のTTLと、NSレコード以外で1日を超えるTTLです。どちらもエラーではありません。とても短い値は、DNSでデータセンター間の通信を振り分けるプロバイダーでは普通のことです。とても長い値が困るのは、引っ越しが必要になったその日だけです。
指摘する矛盾
- SPFレコードが複数ある
- ドメインが公開できる
v=spf1で始まるTXTレコードは一つだけです。二つあると受信側は恒久的エラーを返し、すべてのメッセージでSPFが失敗します。v=spf1 include:_spf.google.com include:sendgrid.net ~allのように一つにまとめてください。 - CNAMEがほかのレコードと並んでいる
- エイリアスは名前全体を置き換えるので、MXやTXTなど他のレコードと名前を共有できません。これはたいていドメインの頂点で起こります。そこにはNSとSOAのレコードが必ず存在するからです。頂点ではAとAAAAのレコードを使うか、DNSホストの「ALIAS」「ANAME」「CNAMEフラットニング」機能を使ってください。
- アドレスレコードがない
- AもAAAAもなければ、その名前には何も接続できません。メールや所有確認のレコードだけを載せる名前なら想定どおりです。ウェブサイトなら問題です。
- ネームサーバーが一つだけ、またはDSレコードのないDNSSEC鍵
- ネームサーバーが一つだと、サイトもメールも1台のマシンが動き続けることに頼ることになります。レジストラーにDSレコードがないまま鍵があるということは、ゾーンは署名されているのに誰も署名を確認していないということです。
- SPFのないメールサーバー、または間違った名前に置かれたDMARCレコード
- どちらもドメインのなりすましを容易にします。メール認証チェックでSPF、DKIM、DMARCを詳しく確認できます。
結果は、ある公開リゾルバーが今この瞬間に見ている内容です。最近変更したばかりなら、ほかのリゾルバーはまだ以前の値を保持しているかもしれません。DNS浸透チェックで比較できます。selector._domainkeyの下のDKIM鍵やSRVレコードなど、入力していない名前のレコードは一覧に出ません。DNSには、ドメインにすべての名前を尋ねる方法がないからです。
よくある質問
ドメインのDNSレコードをすべて見るには？
レコードの種類ごとに順に問い合わせます。このページが主な種類について行っているのがそれです。「全部ください」という問い合わせで確実に動くものはありません。現在ほとんどのサーバーはANYタイプを拒否するか一部しか答えず、サブドメインのレコードはそのサブドメインを名前で調べたときにしか出てきません。
AレコードとCNAMEの違いは？
AレコードはIPアドレスを直接示します。CNAMEは別の名前を示し、リゾルバーは代わりにその名前を調べに行きます。プロバイダーから自社のホスト名を指すよう言われたときはCNAMEを使います。そうすれば相手はあなたの手を煩わせずにアドレスを変えられます。CNAMEを持つ名前には、ほかのレコードを置けません。
DNSの変更が反映されるまでどのくらいかかりますか？
最長で、編集する前にレコードが持っていたTTLに、DNSホストが公開するまでの数秒を足した時間です。以前のTTLが1時間なら、一部の訪問者は最大1時間古い値を使い続けます。レジストラーでネームサーバーを変更した場合は親ゾーンのTTLに従い、1〜2日かかることがよくあります。
ドメインにTXTレコードがこんなに多いのはなぜですか？
メール配信サービスからアクセス解析、電子署名まで、つないだオンラインサービスはどれも、ドメインの所有を証明するためにTXTのコードを追加するよう求めます。それが積み重なります。ほとんどは、サービスが確認を終えたあとや利用をやめたあとに削除できます。SPFレコードは残してください。また、再確認される可能性のあるコードは、削除する前にサービスのドキュメントを確認してください。
「MXレコードなし」はメールにとって何を意味しますか？
そのドメイン宛てのメールを受け取るサーバーが指定されていない、ということです。送信側はAレコードのアドレスを試しますが、それはたいていメールを受け付けないウェブサーバーなので、メッセージは戻ってきます。ドメインがメールを受け取ることが決してないなら、「null MX」（0 .）を公開してください。送信側がすぐにあきらめます。
サブドメインも調べられますか？
はい。shop.example.comのようにホスト名を完全に入力してください。サブドメインは通常、独自のNSやSOAレコードを持ちません。上位ゾーンのネームサーバーが代わりに答え、結果にはそのゾーン名が表示されます。