DNSの名前解決の仕組みについて

DNSの名前解決とは、人が読みやすいドメイン名を、通信に必要なIPアドレスへ変換する仕組みのことです。

たとえば、私たちはWebサイトにアクセスするときに example.com のようなドメイン名を使いますが、コンピュータやネットワーク機器は、そのままでは通信できません。

実際の通信では、192.0.2.1 や 2001:db8::1 のようなIPアドレスが必要になります。

このとき、ドメイン名とIPアドレスを結び付ける役割を担っているのがDNSです。

DNSはインターネットを支える非常に重要な仕組みのひとつであり、Webサイトの表示、メールの送受信、各種オンラインサービスの利用など、さまざまな場面で使われています。

DNSとは何か

DNSは Domain Name System の略です。

よく「インターネットの電話帳」とたとえられますが、実際には単なる一覧表ではありません。

DNSは、階層構造を持った分散型の仕組みです。

世界中に分散して配置されたDNSサーバーが連携しながら、必要な情報を探し出して返しています。

この仕組みがあることで、私たちは覚えにくいIPアドレスではなく、

• google.com
• example.jp
• openai.com

のようなわかりやすいドメイン名でサービスにアクセスできます。

名前解決とは何か

名前解決とは、ドメイン名に対応するIPアドレスなどの情報を調べる処理を指します。

たとえば、ユーザーがブラウザで www.example.com にアクセスするとき、コンピュータは最終的にその名前に対応するIPアドレスを知る必要があります。

この「名前から通信先を調べる一連の流れ」がDNSの名前解決です。

通常、IPv4アドレスを調べる場合は Aレコード、IPv6アドレスを調べる場合は AAAAレコード が使われます。

DNSの名前解決に関わる主な登場人物

DNSの名前解決を理解するには、まず関係する役割を整理するとわかりやすくなります。

スタブリゾルバ

スタブリゾルバは、PCやスマートフォンなどの端末側で動作する、DNS問い合わせの入口です。

ブラウザやアプリは、通常この仕組みを通じて名前解決を行います。

再帰リゾルバ

再帰リゾルバは、利用者の代わりにDNS情報を探しに行くサーバーです。

一般には、契約しているプロバイダのDNSサーバーや、公開DNSサービス、社内DNSサーバーなどがこれにあたります。

ルートネームサーバー

ルートネームサーバーは、DNS階層の最上位に位置するサーバーです。

目的のドメインについて、まずどのトップレベルドメインへ進めばよいかを案内します。

TLDサーバー

TLDはトップレベルドメインのことで、.com や .jp などが該当します。

TLDサーバーは、そのドメインをどの権威DNSサーバーが管理しているかを示します。

権威DNSサーバー

権威DNSサーバーは、そのドメインに関する正式なDNS情報を持つサーバーです。

最終的に、www.example.com のAレコードやMXレコードなどの答えを返す役割を担います。

DNSの名前解決の基本的な流れ

ここでは、ユーザーが www.example.com にアクセスする場合を例に、名前解決の流れを見ていきます。

端末が手元の情報を確認する

まず、ブラウザやOSは、すぐに使える情報がないかを確認します。

環境によって順序は異なりますが、一般的には次のようなものが参照されます。

• ブラウザのキャッシュ
• OSやローカルの名前解決キャッシュ
• hostsファイル
• 設定されているDNSサーバー

ここで答えが見つかれば、外部のDNSサーバーへ問い合わせる必要はありません。

再帰リゾルバへ問い合わせる

ローカルに情報がなければ、端末は設定されているDNSサーバー、つまり再帰リゾルバへ問い合わせます。

このとき利用者側は通常、「最終的な答えを調べて返してください」という形で依頼します。

再帰リゾルバがルートネームサーバーへ問い合わせる

再帰リゾルバに必要な情報のキャッシュがなければ、まずルートネームサーバーへ問い合わせます。

ルートネームサーバーは、通常、www.example.com の最終的なIPアドレスを返すのではなく、.com ならどのTLDサーバーを参照すべきかという情報を返します。

TLDサーバーへ問い合わせる

次に再帰リゾルバは、.com のTLDサーバーへ問い合わせます。

するとTLDサーバーは、example.com を管理している権威DNSサーバーがどこかという情報を返します。

権威DNSサーバーへ問い合わせる

再帰リゾルバは、案内された権威DNSサーバーへ問い合わせます。

ここで初めて、たとえばwww.example.com のAレコードは 192.0.2.10というような正式な答えが返されます。

端末へ結果を返す

再帰リゾルバは取得した結果を利用者の端末へ返します。

同時に、その情報を一定時間キャッシュすることが一般的です。

そのため、同じ問い合わせが繰り返された場合、次回はより速く応答できるようになります。

DNSの名前解決の流れを簡単にまとめると

DNSの名前解決は、おおまかに次の流れで行われます。

端末 → 再帰リゾルバ → ルートネームサーバー → TLDサーバー → 権威DNSサーバー → 再帰リゾルバ → 端末

利用者から見ると1回の問い合わせに見えても、実際には裏側で複数のサーバーをたどって答えが見つけられています。

再帰問い合わせと反復的な解決

DNSでは、問い合わせの考え方として「再帰」と「反復的な解決」を区別して理解するとわかりやすくなります。

再帰問い合わせ

再帰問い合わせとは、「最終的な答えを調べて返してください」という形の問い合わせです。

一般的に、端末から再帰リゾルバへの問い合わせはこの形式です。

反復的な解決

一方、再帰リゾルバは、必要に応じてルート、TLD、権威DNSサーバーを順番にたどりながら情報を集めます。

この過程では、途中のサーバーから「次に参照すべきサーバー」の情報を受け取り、最終回答に近づいていきます。

このような流れを、反復的な解決として説明することがあります。

DNSの階層構造

DNSは階層構造になっています。

たとえば www.example.com は、概念的には次のように分けられます。

• . ルート
• com トップレベルドメイン
• example 第2レベルドメイン
• www ホスト名

DNSはこの階層に沿って、上位から下位へと必要な情報をたどっていく仕組みです。

主なDNSレコードの種類

DNSではさまざまな種類のレコードが使われます。代表的なものを見てみましょう。

Aレコード

ドメイン名をIPv4アドレスに対応させるレコードです。

例：www.example.com -> 192.0.2.10

AAAAレコード

ドメイン名をIPv6アドレスに対応させるレコードです。

CNAMEレコード

ある名前を、別の正規名の別名として扱うためのレコードです。

たとえば www.example.com を example.com に向けるといった使い方があります。

MXレコード

メールの配送先となるメールサーバーを示すレコードです。

NSレコード

そのゾーンを管理している権威DNSサーバーを示すレコードです。

TXTレコード

任意のテキスト情報を設定するレコードです。

SPF、DKIM、DMARCなど、メール認証関連でもよく利用されます。

SOAレコード

ゾーンの基本情報を持つ重要なレコードです。

シリアル番号や更新間隔など、ゾーン管理に必要な情報が含まれます。

PTRレコード

IPアドレスからドメイン名を調べる逆引きに使われるレコードです。

キャッシュとTTLの仕組み

DNSでは、毎回ルートから順番に情報をたどっていては効率が悪くなります。

そのため、再帰リゾルバやOSなどは、取得したDNS情報を一定時間保存して再利用します。これがキャッシュです。

TTLとは

TTLは Time To Live の略で、「この情報をどれくらいの時間キャッシュしてよいか」を示す値です。

たとえばTTLが300であれば、通常は300秒間、その情報を再利用できます。

キャッシュのメリット

キャッシュには次のような利点があります。

• 名前解決が速くなる
• DNSサーバーの負荷を減らせる
• 通信全体の効率が向上する

キャッシュの注意点

一方で、DNSレコードを変更しても、すぐにすべての利用者へ反映されるとは限りません。

キャッシュが残っている間は、古い情報が参照されることがあります。

このため、サーバー移転やメール設定変更の際には、TTLとキャッシュの影響を考慮することが重要です。

正引きと逆引き

正引き

ドメイン名からIPアドレスを調べることを正引きといいます。

一般的なWebアクセスで行われるのはこちらです。

逆引き

IPアドレスからドメイン名を調べることを逆引きといいます。

逆引きにはPTRレコードが使われ、メールサーバーの信頼性確認やログ解析などで利用されます。

権威DNSサーバーとは何か

権威DNSサーバーは、そのゾーンに対して正式な回答権限を持つサーバーです。

キャッシュされたコピー情報を返す再帰リゾルバとは異なり、そのドメインに関する正式な情報源として機能します。

たとえば、自社ドメインのDNSをクラウドサービスやDNSホスティングサービスで管理している場合、そのサービス上の権威DNSサーバーが正式な回答元になります。

ゾーンとは何か

DNSでは、管理の単位をゾーンと呼びます。

たとえば example.com のゾーンには、

• www
• mail
• blog
• MXレコード
• TXTレコード

などの情報が含まれます。

なお、ドメイン名とゾーンは似ていますが、必ずしも同じ意味ではありません。

管理の委任が行われれば、sub.example.com を別ゾーンとして切り出して管理することも可能です。

DNS委任とは何か

DNSでは、下位ドメインの管理を別の権威DNSサーバーへ任せることができます。

これを委任といいます。

たとえば、

• example.com は本体側で管理する
• shop.example.com は別システムや別チームで管理する

といった運用も可能です。

この場合、親ゾーン側でNSレコードを設定し、子ゾーンの権威DNSサーバーを示します。

DNSの名前解決が終わった後はどうなるのか

DNSでIPアドレスがわかったあと、実際の通信が始まります。

たとえばWebサイトにアクセスする場合は、一般的に次のような流れになります。

1. DNSでIPアドレスを取得する
2. そのIPアドレスへ接続する
3. HTTPSならTLS通信を開始する
4. HTTPリクエストを送る
5. HTMLや画像などのデータを受け取る

つまりDNSは、インターネット通信の入口として重要な役割を果たしています。

名前解決が失敗する主な原因

DNSの名前解決がうまくいかない原因としては、次のようなものがあります。

設定ミス

• AレコードやAAAAレコードの誤設定
• CNAMEの向き先ミス
• NS設定の誤り
• MXやTXTの設定不備

キャッシュの影響

• 古いDNS情報が残っている
• TTLの影響で変更がすぐ反映されない

権威DNS側の問題

• DNSサーバーの障害
• ゾーン未反映
• 設定内容の不整合

クライアント側の問題

• ローカルキャッシュの不具合
• hostsファイルの誤設定
• 利用中のDNSサーバー障害

セキュリティや通信制御の影響

• DNSSEC検証の失敗
• ファイアウォールによる通信制限
• DoHやDoTの設定不整合

DNSSECとは何か

DNSSECは、DNS応答が改ざんされていないかを検証しやすくするための仕組みです。

通常のDNSだけでは、返ってきた情報が本当に正しいものかを十分に確認できない場合があります。

そこでDNSSECでは、DNSデータに電子署名を付けることで、

• 応答が改ざんされていないか
• 正しい権威側の情報か

を検証できるようにします。

ただし、DNSSECはDNS通信そのものを暗号化する仕組みではありません。

主な目的は、応答内容の完全性と正当性を確認することにあります。

DoHとDoTとは何か

近年では、DNS問い合わせ自体を暗号化して保護する仕組みも広く使われるようになっています。

DoH

DoHは DNS over HTTPS の略です。

HTTPS通信の中でDNS問い合わせを行う方式です。

DoT

DoTは DNS over TLS の略です。

TLSを使ってDNS問い合わせを暗号化する方式です。

従来の通常DNS問い合わせは暗号化されないことが多く、経路上で内容を見られる可能性がありました。

DoHやDoTは、この問い合わせ内容を保護し、プライバシーや安全性を高めるために使われます。

なお、DNSSECとDoH/DoTは役割が異なります。

DNSSECは応答内容の正当性確認、DoH/DoTは問い合わせ経路の保護に重点があると考えると理解しやすくなります。

具体例で見るDNSの名前解決

たとえば www.example.com にアクセスする場合の流れを簡単に表すと、次のようになります。

利用者の端末

「www.example.com のIPアドレスを知りたい」

再帰リゾルバ → ルートネームサーバー

「.com はどこへ問い合わせればよいですか」

ルートネームサーバー

「.com のTLDサーバーはこちらです」

再帰リゾルバ → TLDサーバー

「example.com はどの権威DNSサーバーが管理していますか」

TLDサーバー

「example.com の権威DNSサーバーはこちらです」

再帰リゾルバ → 権威DNSサーバー

「www.example.com のAレコードを教えてください」

権威DNSサーバー

「192.0.2.10 です」

再帰リゾルバ → 利用者の端末

「答えは 192.0.2.10 です」

Web担当者が知っておきたい実務上のポイント

DNSは技術者だけのものではなく、Web担当者にとっても非常に重要です。

DNS変更はすぐに全員へ反映されるとは限らない

サーバー移転やCDN導入、メール設定変更の際は、TTLやキャッシュの影響を考慮する必要があります。

CNAMEとAレコードの違いを理解しておく

サブドメイン設定、外部サービス連携、広告計測やLP運用などでDNS設定を触る場面は少なくありません。

MXやTXTはメール運用に直結する

SPF、DKIM、DMARCの設定不備は、メール到達率やなりすまし対策に影響します。

NSの変更は影響が大きい

ネームサーバー変更は、単純なレコード修正よりも影響範囲が広く、慎重な確認が必要です。

サイト障害のように見えてDNSが原因のこともある

Webサーバーそのものではなく、DNS設定やキャッシュが原因で接続できなくなるケースもあります。

よくある誤解

DNSは1台のサーバーに全部入っている

実際には、DNSは世界中に分散した階層型の仕組みです。

DNSはドメイン名をIPに変えるだけ

基本的な役割はその通りですが、実際にはメール配送、認証、委任、負荷分散などにも関わっています。

DNS変更をすればすぐ全員に反映される

TTLや各種キャッシュの影響により、反映まで時間がかかることがあります。

権威DNSと再帰リゾルバは同じもの

両者は役割が異なります。

権威DNSは正式な情報を持つ側、再帰リゾルバは情報を探して利用者へ返す側です。

まとめ

DNSの名前解決とは、ドメイン名に対応するIPアドレスなどの情報を、階層化された分散型の仕組みの中で探し出す処理です。

大まかな流れとしては、

• 利用者がドメイン名を入力する
• 端末が再帰リゾルバへ問い合わせる
• 再帰リゾルバが必要に応じてルート、TLD、権威DNSをたどる
• 最終的なIPアドレスが端末へ返される
• その後、実際の通信が始まる

という形になります。

DNSは普段あまり意識されにくい仕組みですが、Webサイトの表示やメールの送受信を支える非常に重要な基盤です。

名前解決の流れを理解しておくと、DNS設定変更時のトラブルや、サイトが表示されない原因の切り分けにも役立ちます。

以上、DNSの名前解決の仕組みについてでした。

最後までお読みいただき、ありがとうございました。