DNSルックアップ

仕組み

1. ドメインを入力: サブドメインを含むドメイン名をフィールドに入力します。
2. レコードタイプを選択: クエリするDNSレコードタイプを選択: A、AAAA、MX、CNAME、TXT、NS、SOA、またはすべて。
3. 結果を表示: 結果は公開DNS-over-HTTPSプロバイダーから取得され、TTL値とデータとともに表示されます。
4. 診断: レコードタイプ間で結果を比較して、誤った構成、伝播の遅延、欠落しているレコードを特定します。

なぜDNSルックアップを使うのか?

DNSの問題は、ウェブサイトのダウンタイム、メール配信の失敗、ドメイン移行の問題の最も一般的な原因の1つです。ブラウザから直接DNSレコードをクエリできることは, digやnslookupなどのコマンドラインツールに頼らずに, 開発者、DevOps、システム管理者にとって貴重です。このツールは、プライバシーとファイアウォール回避のためにDNS-over-HTTPSを介してレコードをクエリします。メールプロバイダーの変更後にMXレコードを確認したり、DNS移行後にA/CNAMEレコードを確認したり、SPF/DKIM認証用のTXTレコードを確認したり、伝播の遅延を診断するために使用してください。

DNSレコードタイプ

• A, ドメインのIPv4アドレス
• AAAA, ドメインのIPv6アドレス
• MX, メールルーティング用のメールサーバーレコード
• CNAME, 別のドメインを指す正規名エイリアス
• TXT, SPF、DKIM、ドメイン検証用のテキストレコード
• NS, ドメインの権威ネームサーバー

DNS の 40 年: RFC 882 から DNS over QUIC まで

ドメインネームシステムは Paul Mockapetris によって USC/ISI で設計され、RFC 882 と RFC 883(1983 年 11 月)で仕様化され、ARPANET が成長しすぎた平らな HOSTS.TXT ファイルを置き換えました。システムは RFC 1034 と RFC 1035(1987 年 11 月)で全面的に見直され正式化され、これらの文書は今でも引用されています。Jon Postel は最初の 13 個のルートネームサーバーの割り当てを調整し、a.root-servers.net から m.root-servers.net までラベル付けされました。この数は容量ではなく、当時の 512 バイトの UDP パケットサイズ制限によって固定されました。今世紀には 2 つの大きな衝撃が DNS を再形成しました。2008 年 7 月に、Dan Kaminsky はキャッシュ汚染攻撃を公開し、攻撃者は数秒以内にリゾルバーに偽造レコードを注入できました。業界は協調パッチ(送信元ポートのランダム化)と DNSSEC(RFC 4033-4035、2005 年 3 月)への関心の再燃で対応し、DNSSEC はレコードを暗号学的に署名します。2 つ目の衝撃はプライバシーでした:クエリは 35 年間、UDP ポート 53 上で平文で送信されていました。DNS over TLS(DoT、RFC 7858、2016 年 5 月)はポート 853 でクエリを TLS でラップします。DNS over HTTPS(DoH、RFC 8484、2018 年 10 月)はポート 443 で HTTPS を介してクエリをトンネリングし、DNS が発生していることさえも隠します。DNS over QUIC(RFC 9250、2022 年 5 月)は最新で、HTTP/3 を動かすのと同じトランスポートを使用します。パブリックリゾルバー 1.1.1.1(Cloudflare、2018 年 4 月 1 日にローンチ)、8.8.8.8(Google Public DNS、2009 年 12 月)、9.9.9.9(Quad9、2017 年 11 月)はすべて今日 DoH と DoT をサポートしています。

レコードタイプの詳細

• A(RFC 1035)。32 ビットの IPv4 アドレス。1 つのドメインには負荷分散のために多くの A レコードを持つことができ、リゾルバーはそれらを回転させます(ラウンドロビン DNS)。
• AAAA(RFC 3596、2003)。128 ビットの IPv6 アドレス。「クアッド-A」と発音されます。2024 年時点で、Google のトラフィックの約 45% は IPv6 です。
• CNAME(RFC 1035)。エイリアス:「この名前に従い、代わりにそのレコードを検索する」。同じ名前で他のレコードと共存できません。これが example.com が頂点で CNAME と MX または A の両方を持つことができない理由です;現代の代替案は ALIAS または ANAME(ベンダー固有)または HTTPS レコード(RFC 9460、2023)を使用します。
• MX(RFC 1035、RFC 7505「null MX」で更新)。優先度値を持つメール交換サーバー。低い優先度が優先されます;同点はランダム化されます。0 .(RFC 7505、2015 年 6 月)は明示的に「このドメインはメールを受信しない」と述べ、メールボックスのないドメインへのスパムをブロックします。
• TXT(RFC 1035)。自由形式のテキスト文字列。今では重要な認証を運びます:SPF(RFC 7208、2014)、DKIM(RFC 6376、2011)、DMARC(RFC 7489、2015)、および Google Search Console、Microsoft 365、ACME(Let's Encrypt)DNS-01 チャレンジの所有権検証。
• NS(RFC 1035)。権威ネームサーバーの名前。冗長性のために常に少なくとも 2 つ。親ゾーンの「グルーレコード」は IP を提供し、再帰リゾルバーが循環ルックアップなしでネームサーバーに到達できるようにします。
• SOA(RFC 1035)。Start of Authority。プライマリネームサーバー、管理者メール(最初の . を @ に置き換え)、シリアル番号(変更時にインクリメント)、refresh、retry、expire、および最小 TTL をリストするゾーンごとの単一レコード。
• CAA(RFC 8659、2019;元々 RFC 6844、2013)。Certificate Authority Authorisation。ドメインに証明書を発行できる CA をリストします。2017 年 9 月以降、CA/Browser Forum ベースライン要件による必須チェック。
• SRV(RFC 2782、2000)。サービスの場所:プロトコル、優先度、重み、ポート、ターゲットホスト。Microsoft Active Directory、XMPP、SIP、Matrix 連合はすべてサービス発見に SRV レコードを使用します。
• PTR(RFC 1035)。逆引き DNS。IP をドメインに戻します。in-addr.arpa(IPv4)または ip6.arpa(IPv6)ゾーンに存在します。多くのメールサーバーがメールを受け入れるために必要;PTR の欠落は一般的なスパムシグナルです。
• DNSKEY / DS / RRSIG(RFC 4034-4035)。DNSSEC の配管。DNSKEY はゾーンの署名キーを公開します;親ゾーンの DS は暗号化された「これがチェーンの次のリンクです」ポインターです;RRSIG は各レコードセットの実際の署名を運びます。

DNS ルックアップが実際に役立つ場所

• 新しいドメインでのメール設定。MX レコードが正しいプロバイダー(Google Workspace aspmx.l.google.com、Microsoft 365 example-com.mail.protection.outlook.com、Fastmail、ProtonMail)を指していることを確認します。SPF(v=spf1 include:_spf.google.com ~all)、DKIM(selector._domainkey)、DMARC(_dmarc TXT)をチェックします。
• ドメインの移行と伝播。レジストラでネームサーバーを更新した後、変更が世界的に伝播したことを確認するために、古いものと新しい権威サーバーの両方をクエリします。リゾルバーが異なれば、キャッシュする期間も異なります(TTL は契約ではなく、ヒントです)。
• TLS / SSL 証明書のトラブルシューティング。Let's Encrypt などで使用される ACME DNS-01 チャレンジでは、_acme-challenge.example.com に TXT レコードを配置する必要があります。無駄なレート制限の試みを避けるために、証明書の発行をトリガーする前に値をチェックします。
• サブドメインの乗っ取りリスクの検出。登録されていないサービス(削除された Heroku アプリ、解放された S3 バケット)を指す CNAME は、攻撃者にそれを登録してあなたのサブドメインでコンテンツを提供することを許可します。クイックな CNAME 監査でぶら下がっているポインターを捕まえます。
• CDN とロードバランサーの検証。デプロイ後にドメインが正しい Cloudflare、Fastly、Akamai、CloudFront、Vercel エンドポイントに CNAME することを確認します。ステージングが誤って本番を指しているときを検出します。
• 地理的 DNS 比較。一部のサイトは地域別に異なる A レコードを提供します(GeoDNS)。異なる DoH エンドポイント(Cloudflare 1.1.1.1 対 Google 8.8.8.8)からクエリすることは、フランクフルトとムンバイのユーザーがサイトをどのように見るかを示唆します。
• セキュリティとインシデント対応。予期しない NS レコード(レジストラハイジャック)、疑わしい TXT レコード、または最近追加された MX レコードを探します。SOA シリアルを使用して、ゾーンが最後に変更された時期を追跡します。

サイトとメールを壊す DNS の間違い

• 頂点での CNAME。RFC 1034 は example.com 自体に CNAME を置くことを禁じています(www.example.com のようなサブドメインのみ)。Cloudflare、Route 53、DNSimple は CNAME フラット化または ALIAS レコードでこれを回避します;Vercel、Netlify は HTTPS サービスバインディングレコード(RFC 9460)を使用します。基本的なレジストラの DNS パネルで試すと、メールが静かに壊れます。
• 移行前に TTL を下げ忘れる。A レコードの TTL が 86400(24 時間)で、切り替え当日の朝に変更すると、世界中のリゾルバーは最大 1 日間古い IP を配布し続けます。変更の数日前に TTL を 300 秒に下げます。
• DNS ルックアップが多すぎる SPF レコード。RFC 7208 は SPF を評価ごとに 10 回の DNS ルックアップに制限します。include: ディレクティブを多すぎチェーンすると、SPF レコードが permerror で失敗し、DMARC はこれを失敗として扱います。SPF Surveyor などのツールで平坦化または統合します。
• サービス撤去後のぶら下がっている CNAME。Heroku アプリを削除したが、app.example.com CNAME がまだ example.herokuapp.com を指していますか?誰でもそのアプリ名を登録し、あなたのサブドメインで彼らのコンテンツをホストできます。孤立した CNAME を監査して削除します。
• CAA レコードなし。CAA レコードがなければ、WebPKI のどの CA(世界中で約 50)もあなたのドメインに証明書を発行できます。1 つまたは 2 つの信頼できる CA にロックします:0 issue "letsencrypt.org"。2017 年 9 月以来の必須 CA チェック。
• 欠落エントリをマスクするワイルドカードレコード。*.example.com A レコードは、タイプミスのあるすべてのサブドメインを解決し、実際の構成ミスを隠します。タイプミスのアドレスへのスパムを避けるために、明示的な MX ルールと注意深く組み合わせます。
• カットオーバー中の DNSSEC と署名されていないゾーンの混在。新しいネームサーバーが署名されたレコードを提供する前にレジストラで DNSSEC を有効にすると、検証する各リゾルバー(Cloudflare 1.1.1.1、Quad9)に SERVFAIL を生成します。常に最初に署名し、それから DS レコードを公開します。

その他のよくある質問

関連ツール