DNSとは何か、その仕組みは？

IPAddress-Lookup.com · June 28, 2025

ブラウザにウェブサイトの名前を入力するたびに、そのサイトが実際にどこにあるのかを特定するために、目に見えないシステムが動き出します。そのシステムこそが「ドメインネームシステム（DNS）」であり、インターネット上で最も重要なインフラの一つです。 これがなければ、example.comのような覚えやすい名前ではなく、アクセスするウェブサイトごとに長い数字の列を暗記しなければならなくなります。このガイドでは、DNSとは具体的に何かを解説し、実際の検索プロセスを最初から最後まで追跡し、主要なレコードの種類を一つひとつ詳しく説明するとともに、ご自身でDNSを確認・トラブルシューティングする方法をご紹介します。

DNSとは？

DNSは、インターネット上の電話帳のようなものです。コンピュータは人間が読み取れる名前を使って通信するのではなく、数値のアドレスを使って通信します。電話で友人に連絡したいとき、名前をダイヤルするのではなく番号をダイヤルしますが、おそらく名前は覚えていて、連絡先リストがその名前を数字に変換してくれるでしょう。DNSはインターネットにおいて同じ役割を果たしています： www.example.com のような、人が覚えやすいドメイン名を、IPv4 では 93.184.216.34 や、IPv6 ではより長い 16 進数の文字列といった、マシンが実際にトラフィックをルーティングするために使用する数値である IP アドレスに変換します。

この変換が重要なのは、IPアドレスが変化するからです。ウェブサイトは新しいサーバーに移転したり、ホスティングプロバイダーを変更したり、あるいは世界中の数十カ所のデータセンターにコンテンツを分散させたりすることがあります。名前があることで、基盤となるアドレスが移動しても変わらない、安定的で覚えやすいラベルが提供されるのです。 DNSは、その約束を果たす層であり、世界中で毎秒数十億回にわたり、名前をアドレスに変換しています。また、DNSは分散型システムであり、単一のコンピュータが電話帳全体を保持しているわけではありません。その代わりに、責任は広大なサーバー階層全体に分散されており、まさにその仕組みによって、DNSは高速で耐障害性が高く、地球規模に拡張できるのです。

DNS検索に関わるプレイヤー

クエリの経路を追跡する前に、その「プレイヤー」たちを紹介しておきましょう。それぞれに特定の役割があり、1回の検索ですべてのプレイヤーが関与することがあります：

• スタブリゾルバー — オペレーティングシステムに組み込まれている小さなソフトウェアです。アプリケーションがアドレスを必要とすると、スタブリゾルバーはそのリクエストを先へ転送します。それ自体ではほとんど処理を行いません。
• 再帰型リゾルバー — 主力となる存在で、通常はインターネットサービスプロバイダー（ISP）や、よく知られている 8.8.8.8 や 1.1.1.1 といったパブリックプロバイダーによって運用されています。クエリを受け取り、最終的な答えを見つけるために必要なあらゆる調査を行い、その結果をユーザーに返します。
• ルートネームサーバー — 階層構造の最上位に位置します。個々のウェブサイトのアドレスは知りませんが、各トップレベルドメインを担当するサーバーがどこにあるかを知っています。
• TLDネームサーバー — .com、.org、.netなどのトップレベルドメイン（TLD）を担当します。これらは、そのドメイン下に登録された各ドメインを管理する権威サーバーを把握しています。
• 権威ネームサーバー — 最終的な真実の源です。これらのサーバーは特定のドメインに関する実際のレコードを保持しており、決定的な回答を提供します。

実際のクエリを追跡する：www.example.com の解決

1つのリクエストを段階を追って追跡してみましょう。ブラウザに「www.example.com」と入力してEnterキーを押したと想像してください。まだ何もキャッシュされていないと仮定した場合、舞台裏では次のようなことが起こります：

1. ブラウザはスタブリゾルバーに問い合わせます。オペレーティングシステムのスタブリゾルバーが www.example.com へのリクエストを受け取ります。まず、自身のローカルキャッシュを確認します。最近この名前を検索した記録があれば、即座に回答を返し、処理はここで終了します。
2. スタブリゾルバは再帰リゾルバに連絡します。キャッシュされた回答がないため、スタブリゾルバは設定された再帰リゾルバにクエリを転送します。
3. 再帰リゾルバはルートサーバーに問い合わせます。再帰リゾルバはまだ .com がどこにあるかを知らないため、ルートサーバーの1つに問い合わせます。ルートサーバーは www.example.com を知りませんが、「その回答は持っていないが、.com を担当するサーバーはここにある」というリファラルを返答します。
4. 再帰リゾルバーは、.com TLDサーバーにクエリを送信します。そのリファラルに従い、リゾルバーは.com TLDサーバーにwww.example.comについて問い合わせます。TLDサーバーは、別のリファラルで応答します。「そのアドレスは知りませんが、example.comの権威あるネームサーバーはここです。」
5. 再帰的リゾルバーは、権威サーバーにクエリを送信します。最終的に、リゾルバーは example.com の権威ネームサーバーに問い合わせます。このサーバーは実際のレコードを保持しており、明確に次のように回答します。「www.example.com の IP アドレスは 93.184.216.34 です。」
6. この回答はユーザーのもとへ戻ってきます。再帰的リゾルバーはこの回答をキャッシュし、スタブリゾルバーに渡すと、ブラウザはそのIPアドレスへの接続を確立します。この一連の処理は通常、数十ミリ秒で完了します。

再帰的クエリと反復的クエリ

上記の解説では、2つの異なるクエリのスタイルが示されています。この違いを理解することで、多くの混乱が解消されます。デバイスが再帰的リゾルバーに質問を行う際、完全な最終回答を期待しています。これが再帰的クエリです。リゾルバーは、完全な結果を返すために必要なあらゆる処理を行う責任を負います。デバイスはただ待機するだけです。

再帰的リゾルバーがルートサーバー、TLDサーバー、および権威サーバーと交わすやり取りは、反復的なクエリです。これらのサーバーは、ユーザーに代わって答えを追い求めることはありません。その代わりに、手元にある最善の情報、通常は目的地へ一歩近づくための参照先を返します。 その後、再帰的リゾルバーはこのプロセスを繰り返し、権威ある回答に到達するまで階層を下ってイテレーティブに処理を進めます。要するに、デバイスは再帰的に問い合わせを行い、リゾルバーはイテレーティブに処理を行うのです。

各レイヤーにおけるキャッシュとTTL

もしすべての検索が権威サーバーまで直接行われなければならないとしたら、インターネットの速度は著しく低下し、ルートサーバーは負荷に耐えきれずダウンしてしまうでしょう。キャッシュ機能はそれを防ぎます。ほぼすべてのレイヤーで、回答は一時的に保存され、再利用できるようになっています。ブラウザも、オペレーティングシステムも、そして再帰的リゾルバーも、大量のキャッシュを行っています。

レコードがキャッシュされる期間は、TTL（Time to Live：有効期間）によって制御されます。TTLは秒単位で測定され、ドメイン所有者によって設定されます。TTLが3600に設定されたレコードは、リゾルバーが新しいコピーを取得するまで1時間キャッシュされます。 TTLを短く設定するとレコードを迅速に変更できるため、サーバーの移行時には便利ですが、クエリの量が増加します。TTLを長く設定するとパフォーマンスが向上し負荷は軽減されますが、変更が世界中に反映されるまでに時間がかかります。そのため、管理者は計画的な変更を行う1日前にレコードのTTLを下げ、変更後には再びTTLを上げるのが一般的です。

DNSの階層構造とルートサーバー

DNSは逆さツリー構造で構成されています。最上位にはルートがあり、通常は表示されない単一のドットで表されます。ルートの下には、.comや.orgといったトップレベルドメイン（TLD）や、.ukや.deのような国別コードがあります。各TLDの下には、example.comのように個人や組織が登録するセカンドレベルドメインがあります。 その下には、wwwやmailといったサブドメインがあります。ドメイン名を右から左に読むと、一般的なものから具体的なものへと階層を下っていくことになります。

ルートは、「13のルートサーバー」としてよく知られるシステムによって提供されています。実際には、これらはAからMまでのラベルが付けられた13のクラスターであり、それぞれが異なる組織によって運用されています。 これら13のアドレスの背後には、アニキャストと呼ばれる技術を用いて世界中に分散配置された数百台の物理サーバーが存在し、リクエストを最も近い利用可能なインスタンスにルーティングします。このようにして、ごく少数の名前付きエントリポイントで、低遅延かつ障害や攻撃に対する高い耐性を保ちながら、地球規模のクエリに確実に応答することが可能になっているのです。

DNSレコードの種類について

ドメインのDNSゾーンはレコードの集合体であり、各レコードタイプにはそれぞれ異なる目的があります。これらを理解することは、ウェブサイトを運営したり、メールを管理したりするすべての人にとって不可欠です。以下の表では、最も重要なタイプを、それぞれの例とともにまとめました。

AレコードおよびAAAAレコード

これらは、名前とアドレスを結びつける中核となるレコードです。 AレコードはIPv4アドレスを指し、AAAAレコードはIPv6アドレスを指します。ドメインには両方が設定できるため、どちらのプロトコルを使用するクライアントもそのドメインにアクセスできます。ブラウザが「example.comはどこにあるのか」と問い合わせた際、最終的な答えを提供するのは通常、これら2つのレコードのいずれかです。

CNAMEレコード

CNAMEはエイリアスを作成し、ある名前を別の正規名（canonical name）に転送します。これは一般的に、wwwをドメイン本体に指し示す場合や、カスタムサブドメインをホスティングプロバイダのアドレスに指し示す場合に使用されます。 重要なルールとして、CNAMEは同じ名前で他のレコードと共存できないため、ドメインのルートでは通常、CNAMEの代わりにAレコードまたはAAAAレコードが使用されます。

MXレコードとメールレコード

MXレコードは、どのサーバーがドメインのメールを受信するかを指定するもので、優先度番号によって試行される順序が決まります。数値が小さいほど優先されるため、優先度10のサーバーは優先度20のサーバーよりも先に試行されます。しかし、MXレコードはメールに関するDNSの一部に過ぎません。

TXTレコード：SPF、DKIM、およびDMARC

TXTレコードには自由形式のテキストが格納され、メールの世界では、3つの相互に関連した認証メカニズムにおいて、これらに大きく依存しています。SPFは、ドメインを代表してメールを送信することが許可されたサーバーをリストアップし、受信者が偽造メールを拒否するのに役立ちます。 DKIMは暗号化された公開鍵を公開し、受信者がメッセージがあなたのドメインによって署名され、転送中に改ざんされていないことを確認できるようにします。DMARCはこれら2つを結びつけ、SPFまたはDKIMのチェックに失敗したメッセージに対して受信者がどう対処すべきか、またレポートをどこに送信すべきかを指示します。これら3つが一体となって、現代の電子メール配信の基盤を形成しています。

NSレコードとSOAレコード

NSレコードは権限を委譲し、ゾーンを担当するサーバーを指定します。SOAレコードはすべてのゾーンの最上位に位置し、プライマリネームサーバー、責任者連絡先、ゾーンの編集時に変更されるシリアル番号、セカンダリサーバーがゾーンのコピーを更新する頻度を制御するタイマーなどの管理情報を保持しています。

CAAレコードとPTRレコード

CAAレコードは、ドメインの証明書を発行できる認証局を制限し、不正な証明書に対する保護層を追加します。これらの証明書がトラフィックをどのように保護しているかを理解したい場合は、SSL証明書の解説ガイドをご覧ください。 PTRレコードは逆DNSを処理し、IPアドレスをホスト名にマッピングします。これは、送信者の正当性を判断するためにメールサーバーによって頻繁に確認されます。

DNSとメールの配信率

DNSは、Webと同様に電子メールにとっても極めて重要であると言えます。メールサーバーがあなたのドメインにメッセージを配信しようとする際、適切な宛先を見つけるためにMXレコードを参照します。 受信サーバーが受信メッセージの信頼性を判断する際、SPF、DKIM、DMARCレコードを確認し、多くの場合、送信サーバーのPTRレコードも検証します。 これらのいずれかが欠落していたり、設定が誤っていたりすると、正当なメールがスパムフォルダに振り分けられたり、完全に拒否されたりする可能性があります。DNSのメールレコードを正しく設定することは、メッセージが迷惑メールフォルダに消えてしまうことなく、受信トレイに確実に届くようにするための、最も効果的な対策の一つです。

DNSセキュリティ

DNSは非常に基礎的なものであるため、攻撃の標的となっており、そのセキュリティを強化するためのいくつかの技術が存在します：

• DNSSECは、DNSレコードに暗号署名を追加することで、リゾルバーが応答が真正な権威あるソースから送信されたものであり、改ざんされていないことを検証できるようにします。これはデータの完全性を保護しますが、データを暗号化することはありません。
• DNS over HTTPS（DoH）およびDNS over TLS（DoT）は、デバイスと再帰的リゾルバー間の通信を暗号化します。従来、DNSクエリは平文で送信されていたため、ネットワーク経路上の誰でもその内容を閲覧したり、改ざんしたりすることが可能でした。DoHとDoTは、クエリを暗号化することでこの脆弱性を解消します。
• キャッシュポイズニングは、悪意のある攻撃者がリゾルバーを騙して偽の応答をキャッシュさせ、被害者を詐欺的なサーバーにリダイレクトさせる典型的な攻撃です。DNSSECや、ランダム化された送信元ポートなどの最新のリゾルバー保護機能により、この攻撃の実行ははるかに困難になっています。

一般的なDNSの問題とトラブルシューティング

ウェブサイトが読み込まれない場合、その原因は多くの場合DNSにあります。最も頻繁に見られる問題には、次のようなものがあります：

• 伝播の遅延。レコードを変更した後も、TTLが切れるまで古いキャッシュ値が残り続けることがあります。これが、自分には変更が反映されているように見えても、他の人にはまだ反映されていない理由です。
• 入力ミスやレコードの欠落。ホスト名のスペルミスやAレコードの登録漏れは、見落としがちな障害の原因となります。
• ネームサーバーの不一致。レジストラがドメインを誤ったネームサーバーに設定している場合、入念に作成したレコードは一切参照されません。
• CNAMEの競合。同じ名前に対して他のレコードと並行してCNAMEを配置すると、解決が失敗します。
• リゾルバーのキャッシュ。問題の原因が自身のデバイスやルーター内の古いエントリである場合があり、キャッシュをクリアすることで解決することがあります。

DNSレコードを自分で確認する方法

DNSレコードを検索するのに、ネットワークエンジニアである必要はありません。ほとんどのシステムで利用可能なdigやnslookupといったコマンドラインツールを使えば、あらゆる種類のレコードを直接照会できます。例えば、ドメインのAレコードを照会するとそのIPv4アドレスが返され、MXレコードを照会するとそのメールサーバーが判明します。 コマンドラインが苦手な場合は、オンラインのDNS検索ツールを利用すれば、ソフトウェアをインストールすることなくブラウザから任意のドメインのレコードを照会できます。これにより、最近の変更が反映されたかどうかを確認したり、設定ミスを診断したりするのが簡単になります。

DNSレコードを確認する習慣を身につければ、システム全体の仕組みが理解しやすくなります。自分のドメインのAレコード、MXレコード、TXTレコードを確認できるようになれば、抽象的な「電話帳」は、自分が管理する具体的で理解しやすいエントリの集合へと変わります。 そうすれば、サイトの表示が遅い、メールがバウンスする、証明書の警告が表示されるといった問題を診断する際も、推測に頼るのではなく、レコードを確認するだけで済むようになります。

よくある質問

DNSとは何の略ですか？

DNS は Domain Name System（ドメインネームシステム）の略です。これは、人間が読みやすいドメイン名を、コンピュータ同士が通信するために使用する数値の IP アドレスに変換する分散型システムです。

なぜ DNS は「インターネットの電話帳」と呼ばれるのですか？

電話帳で名前から電話番号を調べられるのと同じように、DNS を使えば、コンピュータはドメイン名からウェブサイトの IP アドレスを調べることができます。ユーザーは覚えやすい名前を記憶しておけばよく、実際にマシンが必要とする番号への変換は DNS が処理してくれます。

DNSの変更が反映されるまでどれくらいかかりますか？

これは、レコードのTTL（有効期間）や、経路上のリゾルバーがどれほど積極的にそのレコードをキャッシュしているかによって異なります。TTLが短い場合は数分以内に変更が反映されますが、古いキャッシュ値がまだ使用されている場合、世界中に完全に反映されるまで最大24～48時間かかることがあります。

再帰的リゾルバーと権威サーバーの違いは何ですか？

再帰的リゾルバーは、ユーザーに代わって他のサーバーにクエリを送信し、結果をキャッシュすることで、回答を見つけるための作業を行います。権威サーバーは、ドメインのレコードを実際に保持し、最終的な回答を提供する決定的な情報源です。

DNSは暗号化されていますか？

従来のDNSは暗号化されておらず、クエリは平文で送信されます。DNS over HTTPSやDNS over TLSなどの新しい規格では、デバイスとリゾルバー間のトラフィックが暗号化されます。一方、DNSSECでは、回答の真正性を検証するための署名が追加されます。

ドメインのDNSレコードを確認するにはどうすればよいですか？

dig や nslookup といったコマンドラインツール、またはブラウザベースの DNS 検索サービスを利用できます。これらを使用すると、A、AAAA、MX、TXT などの特定のレコードタイプを照会できるため、設定の確認やトラブルシューティングを行うことができます。