DNS レコードを調べる方法

DNSはドメイン名をIPアドレスに翻訳するシステムです。何かがうまくいかないとき(ウェブサイトが読み込まれない、メールが届かない、SSL証明書が失敗するなど)、DNSレコードのチェックはほぼつねに最初のデバッグステップです。各レコードタイプが何をするか、クエリがシステムをどう流れるか、結果が一致しないときにどこを見るかを理解することで、神秘的な障害を解決可能な問題に変えられます。

DNSの簡単な歴史

DNS以前、初期のインターネット上のすべてのコンピューターは、Stanford Research Instituteで保守されるHOSTS.TXTという単一のファイルを共有していました。各サイトは他のマシンのIPアドレスを学ぶために定期的にファイルをダウンロードしました。システムはネットワークが数百ホストのときに機能しました。スケールしませんでした。

1983年、Paul Mockapetrisは階層的分散ネーミングシステムを記述したRFC 882とRFC 883を発表しました。Domain Name Systemです。仕様は1987年にRFC 1034(概念と機能)とRFC 1035(実装と仕様)に精緻化され、今日まで基礎文書のままです。1つの巨大ファイルではなく、名前空間はゾーンに分割され、各ゾーンは独自の権威サーバーによって管理され、ツリーの頂上に小さなルートサーバーのセットがあります。

DNSはそれ以来、着実に拡張されてきました。AAAAレコード(2003年のRFC 3596)はIPv6サポートを追加しました。DNSSEC(2005年のRFC 4033から4035)は、なりすましから保護する暗号署名を追加しました。DNS-over-TLS(2016年のRFC 7858)とDNS-over-HTTPS(2018年のRFC 8484)はクエリを暗号化し、盗聴者やミドルボックスがそれらを見たり改ざんしたりできなくしました。システムの各層は後方互換性を保つため、40年前のプロトコルが今でもモダンなWebを動かしています。

DNSレコードタイプ

DNSレコードタイプは数十ありますが、ほんの一握りが現実世界のルックアップの大部分をカバーします。それぞれが何をするかを知ると、トリアージが速くなります。

A、AAAA、CNAME、MXはほとんどの日常の質問に答えます。TXT、NS、SOA、CAAは設定とセキュリティ監査中に登場します。SRVとNAPTRはVoIP、XMPP、その他のサービス発見プロトコルに重要です。PTRはメールサーバーに重要です。ほとんどのスパムフィルターは、有効な逆引きDNSのない送信者を拒否するからです。

DNSレコードをルックアップする手順

1. ドメインを入力: 任意のドメイン名(例: example.com)をルックアップツールに入力します。そのラベルに特化したレコードが欲しい場合、mail.example.comのようなサブドメインも入力できます。
2. レコードタイプを選択: A、AAAA、MX、TXT、CNAME、NS、SOA、CAAから選びます。ツールは素早い概観のために、すべての一般的なタイプを一度にクエリすることもサポートします。
3. 結果をレビュー: レスポンスは、各一致するレコードを値、TTL(リゾルバーがキャッシュできる期間)、MX優先度やSOAシリアル番号などの追加フィールドとともに一覧表示します。
4. 期待値と比較: レコードを変更したばかりなら、新しい値が現れることを確認します。第三者をデバッグしているなら、見えるものと彼らが設定したと言うものを比較します。

現実世界の問題をDNSでデバッグ

ウェブサイトが読み込まれない? AとAAAAレコードをチェックします。それらが欠けていれば、ドメインは未接続です。古いIPを指していれば、トラフィックはもうサイトをホストしていないサーバーに到達しています。NSレコードがレジストラの記載するネームサーバーと一致することも確認してください。不一致はゾーン全体が古いソースから配信されていることを意味します。

メールが届かない? まずMXレコードをチェックします。欠落または不正なMXレコードは、何も配信できないことを意味します。次にSPF(v=spf1)、DKIM(default._domainkeyなど)、DMARC(_dmarc.example.com)のTXTレコードをチェックします。モダンなメールプロバイダーはこれらのチェックに失敗するメッセージを拒否または隔離するため、欠落したレコードはメッセージを黙ってスパムに送ることがあります。

SSL証明書エラー? Aレコードが証明書がインストールされたサーバーを指していることを確認します。サイトがCDNの背後にある場合、AレコードはオリジンではなくCDNエッジに解決すべきです。CAAレコードもチェックしてください。1つの認証局のみをリストするCAAは、ドメイン所有者が機能することを期待していても、他のすべてが証明書を発行することをブロックします。

ドメイン検証が失敗? Google Workspace、Microsoft 365、Cloudflare、ほとんどのSaaSプラットフォームは、ドメイン所有権を証明するためにTXTレコードを追加するよう求めます。TXTレコードをルックアップして、プラットフォームが要求した引用符や接頭辞を含む正確な文字列が存在することを確認します。

DNSの伝播が遅く感じる? レコードを変更した後、世界中のリゾルバーはTTLが期限切れになるまでキャッシュ値を提供し続けます。予定された変更の前日にTTLを300秒に下げると、切り替えがずっと速くなります。ルックアップツールは各レコードと並んで現在のTTLを表示するため、古い値がどれくらい長く残るかを予測できます。

SPF、DKIM、DMARC

3つのTXTベースのレコードは、メールをなりすましから保護します。SPFはドメインのメール送信を許可されているサーバーを列挙します。DKIMは、受信者が各メッセージの暗号署名を検証するために使う公開鍵を公開します。DMARCは、SPFまたはDKIMが失敗したときに何をすべきかを受信者に伝えます。何もしない、隔離、または拒否。3つすべてはDNSに存在し、3つすべてはすべての受信メッセージでクエリされ、いずれかのタイポは到達性を麻痺させる可能性があります。DNSルックアップツールは、設定UIが主張するものとは別に、実際に公開されているものを読む最速の方法です。

証明書プロビジョニングとCAA

TLS証明書をリクエストすると、認証局は制御を検証するためにDNSをクエリします。ほとんどはdns-01チャレンジを使います。_acme-challengeの下に特定のTXTレコードを公開するよう求め、それが現れたかをチェックします。CAAレコードは追加の層を加えます。ドメインの証明書を発行できる認証局を宣言します。誤設定されたCAAは正当な更新をブロックする可能性があるため、Let's Encryptのcronジョブが突然動作しなくなったらCAAをチェックしてください。

よくある落とし穴

• 再帰的答えと権威的答えの混同: ISPのリゾルバーは現実から数時間遅れたキャッシュコピーを提供することがあります。ルックアップツールはCloudflareのDNS-over-HTTPSエンドポイントを使い、権威サーバーに直接クエリしてISPキャッシュをバイパスします。
• TTLを無視する: レコードのTTLが86400秒(24時間)なら、変更はどこでも見えるようになるのに丸1日かかることがあります。切り替えの1日前にTTL削減を計画してください。
• 頂点でのCNAME: CNAMEレコードはゾーンのルート(example.com自体)では許可されていません。プロバイダーは回避策としてALIASまたはANAMEレコードを提供しますが、それらは標準DNSではないため動作はさまざまです。
• 複数のSPFレコードを積み重ねる: SPFはv=spf1で始まる正確に1つのTXTレコードを要求します。2つのSPFレコードは、受信サーバーが結果をPermErrorとマークする原因になり、これは到達性を沈めます。
• 末尾のドットを忘れる: ゾーンファイルでは、末尾のドットなしの名前はゾーンに相対的なものとして扱われるため、ドットを忘れるとmail.example.comがmail.example.com.example.comになります。
• IPv4とIPv6のAレコードを混ぜる: AはIPv4のみです。AレコードにIPv6アドレスを入れる(AAAAではなく)のは、一部のUIがキャッチしない設定エラーです。
• ループするCNAMEチェーン: 別のCNAMEを指すCNAMEが戻ってくる場合、解決ループを作ります。リゾルバーは諦める前にチェーンを約8ホップに制限します。
• 複数の層でのキャッシュ: ブラウザ、OS、ルーター、リゾルバーはそれぞれ独立してDNSをキャッシュします。1つだけをフラッシュするのはほとんど十分ではありません。チェーンを完全にバイパスするためにルックアップツールに手を伸ばしてください。
• ワイルドカードレコードが欠落エントリをマスク: ワイルドカードAレコード(*.example.com)は、明示的なレコードのないサブドメインに一致し、誤設定を隠す可能性があります。
• 1つのリゾルバーだけを信頼する: 伝播は不均一です。グローバル変更を検証するときは、いくつかのリゾルバー(1.1.1.1、8.8.8.8、9.9.9.9)をクエリしてください。

DNSをクエリする代替方法

ブラウザベースのルックアップツールはほとんどのチェックに最速の経路ですが、必要なときはコマンドラインツールがより豊富な詳細を提供します。

それぞれにトレードオフがあります。dig +traceはルートからDNSツリーを歩き、すべてのステップを表示します。これはチェーンがどこで壊れているかを証明するのに非常に貴重です。nslookupはどこにでも出荷され、素早い健全性チェックには問題ありません。Webツールは速度と、ターミナルがまったく必要ないことで勝ちます。

プライバシーとDNS

プレーンDNSクエリは平文で移動します。つまり、ISPとネットワーク上の誰もが、訪れるすべてのドメインを見ることができます。2つの暗号化バリアントがこれに対処します。DNS-over-HTTPS(DoH)はクエリをHTTPSで包み、DNS-over-TLS(DoT)は専用ポートのTLSで包みます。ルックアップツールはCloudflareのDoHエンドポイントを使うため、リゾルバーへのクエリは転送中に暗号化されます。質問するドメインはリゾルバー自体にはまだ観察可能です。それが気になる場合は、独自のリゾルバー(Unbound、Pi-hole)を実行するか、ログを取らないと約束する有料のプライバシー重視のサービスを使ってください。

ブラウザベースのルックアップは、クエリを当社サーバーに保存しません。リクエストはブラウザから直接DoHリゾルバーに行き、レスポンスはクライアントサイドでレンダリングされます。召喚するログも、チェックしたドメインの分析も、将来の侵害で漏洩するものもありません。DNSデバッグのような日常的なタスクには、それがまさに作業にふさわしいプライバシーレベルです。