DNS Lookupツール

概要

DNS は他のすべての手前にある段です。サイトに到達できないとき、メールが跳ね返る とき、デプロイは済んだのに誰にも見えないとき、最初の問いはほぼ常に「その名前は 今何に解決するのか」で、次の問いは「それを誰が言っているのか」です。

このツールは、最も必要とされる 6 種別を公開の DNS-over-HTTPS リゾルバに尋ね、 TTL 付きで表示します。ブラウザは DNS のソケットを開けないため、問い合わせは ローカルに留まらず当サイトの API を経由します。このサイトで端末の外に出る 必要があるのはここだけで、その扱いはプライバシーポリシーに 書いてあります。

使い方

1. ドメインを入力します。https://example.com/path ではなく example.com です。
2. レコードを読みます。各行に種別・名前・値・TTL が出ます。
3. 種別ボタンは既に画面にあるものを絞り込みます。新しい問い合わせは送りません。

各レコード種別が答える問い

MX 列は優先度をホストと分けて表示します。この数値は順位ではなく「選好」で、 小さい方が優先され、同値なら送信側はどちらを選んでもよいという意味です。 MX レコードを 1 つも持たないドメインでも、暗黙 MX の規則により A レコード宛に メールを受け取れます。これは仕様上正当ですが、ほぼ常に意図しない状態です。

TTL の読み方

TTL は、リゾルバがこの答えを何秒保持するつもりかを秒で示したものです。 カウントダウン中の値なので、見えている数値はキャッシュエントリの残り寿命で、 ゾーンに設定した値ではありません。1 分ほど空けて 2 回照会すれば、通常は 減っているのが分かります。

移行作業で最も役に立つ数値がこれです。TTL 86400 のレコードは、変更した後も 最大 1 日はキャッシュから配信され続けます。DNS 事業者が編集をどれだけ速く 適用しようと関係ありません。対処は変更の前に行う必要があります。TTL を 300 に 下げ、元の TTL が切れるのを待ち、それから変更し、終わってから TTL を戻します。

ツールによって答えが違う理由

2 つのリゾルバが正当に食い違うことがあり、その理由を知っていると混乱を避けられます。

• キャッシュの状態 — このツールは Cloudflare のリゾルバを読みます。ISP の リゾルバは独自のキャッシュと独自のカウントダウンを持ちます。
• 地理的なルーティング — 大規模サイトの多くはリゾルバに最も近いアドレスを 返すので、Cloudflare のデータセンターから得た答えは、手元のノート PC が 得る答えとは違います。
• スプリットホライズン DNS — 社内ネットワークでは、公開では別の値に解決する 名前に対して内部アドレスを返せます。公開リゾルバから内部の見え方は決して 見えません。

「権威サーバーが今この瞬間、キャッシュ抜きで何と言っているか」を知りたい場合は、 このツールが列挙する NS のホストに対して dig @<nameserver> <name> <type> を 実行してください。それが真の値で、それ以外はすべてキャッシュです。

レコードの実体は「ゾーン」にある

DNS で混乱しやすいのは、1 つの名前に対する答えが階層的に委任された結果である 点です。www.example.co.jp を引くと、ルートが jp の権威を、jp が example.co.jp の権威を、そのゾーンが最終的な答えを返します。

ここから実務上の帰結が 2 つ出ます。

1 つは、レジストラの管理画面で編集しているものが必ずしも配信されているゾーン とは限らないことです。ネームサーバーを別の事業者（Cloudflare など）に向けた 時点で、権威はそちらに移ります。レジストラ側のゾーン編集画面は残っていても 誰も見ていません。NS を照会して、編集している場所と一致しているか確かめる のがこの問題の唯一の確実な診断です。

もう 1 つは、apex（example.com そのもの）に CNAME を置けないという制約です。 apex には SOA と NS が必須で、CNAME は他のレコードと共存できないためです。 多くの DNS 事業者が「ALIAS」「ANAME」「CNAME フラット化」という独自機能で これを回避しており、その場合このツールには CNAME ではなく解決後の A が 見えます。事業者側で別名として設定したのに A が返るのは、そのフラット化が 働いている印です。

使用例

• メールが跳ね返る — まず MX、次に TXT の SPF レコードを見ます。1 つの ドメインに SPF レコードが 2 つあるのは仕様上のハードエラーで、古い行を消さずに 新しい送信元を足した結果としてよく起きます。
• デプロイ後にサブドメインが 404 — 名前が変わったプラットフォームのホスト名を 指す CNAME になっていないか確認します。
• ドメイン移管後に何かが古い — NS をレジストラの表示と比べます。食い違って いれば、編集しているゾーンは配信されているゾーンではありません。
• サービスの所有確認 — 所有確認トークンは TXT に置きます。最も多い失敗は、 apex ではなく www にレコードを足してしまうことです。

注意事項

問い合わせの前にドメインをホスト名のパターンで検証するので、URL・IP アドレス・ Unicode 形式の国際化ドメイン名は素通しせず拒否します。国際化ドメインの場合は、 先に IDN 変換 で Punycode に直してください。

レコードは要求した種別ではなく、リゾルバが返した種別でラベル付けします。別名の ホストではこれが重要です。CNAME である名前に A を要求すると別名と解決後の アドレスが返るので、別名をアドレスレコードとして表示するのは積極的に誤解を 招きます。

空の結果は失敗ではなく正当な答えです。AAAA レコードを持たないドメインは 単に IPv6 アドレスを持たないだけで、TXT レコードが無いドメインは何も設定して いないだけです。どちらもエラーとして報告すべきものではありません。

解決したサーバーが HTTP で実際に何を返すかは、続けて HTTP ヘッダチェッカー で確認できます。