DNSによる名前解決のプロセスと関連ワードをまとめてみた

# はじめに
はじめてDNS周りを調べたり、学習したりすると、似たような用語がたくさん出てきます。
DNSキャッシュ、DNSリゾルバ、ルートDNS、権威サーバー ... などたくさんあります。
本記事では、DNSサーバーがドメイン名からIPアドレスを取得する名前解決のプロセスを追いながら、それぞれの用語を整理しながら解説していきます。
なお、名前解決のプロセスにフォーカスしているため、DNSの仕組みなどについては理解していることを前提にしています。


## 全体像
>![](https://storage.googleapis.com/zenn-user-upload/718866a53e2e-20250516.jpeg)
※https://www.xdomain.ne.jp/column/about-dns/ より

① ユーザーがブラウザにドメイン名を入力
② ローカルキャッシュの確認
③ OSへ問い合わせ
④ キャッシュDNSサーバーへのクエリ送信
⑤ DNSリゾルバの処理
⑤-a 自身のキャッシュを確認
⑤-b キャッシュに存在しない場合
⑤-b-1 ルートDNSサーバーへの問い合わせ
⑤-b-2 TLD DNSサーバーへの問い合わせ
⑤-b-3 セカンドレベルドメイン DNSサーバーへの問い合わせ
⑤-b-4 権威DNSサーバーからの応答
⑤-c 結果のキャッシュ
⑥ キャッシュDNSサーバーからクライアントへ応答
⑦ OSからブラウザへ応答
⑧ ブラウザがWebサーバーへ接続(HTTPリクエスト)


## ① ユーザーがブラウザにドメイン名を入力
ユーザーがドメイン名を入力し、Enterキーを押すか、アドレスバーの移動ボタンをクリックすると、ブラウザはまずそのドメイン名に対応するIPアドレスを知る必要があります。この要求が、DNSによる名前解決プロセスを開始させる最初の合図となります。

ユーザーのデバイス（またはその上で動作するブラウザ）は、DNSによる名前解決のプロセスにおいて、説明の文脈によって**DNSクライアント**と呼ばれたり、より具体的に**スタブリゾルバ**と呼ばれたりします。

>![](https://storage.googleapis.com/zenn-user-upload/e29aee55daff-20250516.jpeg)
※https://jprs.jp/glossary/index.php?ID=0171 より

**DNSクライアント**
ユーザーのデバイス（PC、スマートフォンなど）は、Webサイトにアクセスしようとする際に、ドメイン名に対応するIPアドレスを知りたいという「要求」をDNSシステムに対して行ないます。この「要求を行う主体」という役割に焦点を当てる場合、ユーザーのデバイスはDNSクライアントと呼ばれます。

**スタブリゾルバ (Stub Resolver)**
DNSクライアントが持つ、DNSリゾルバに問い合わせを行う機能やライブラリ、ソフトウェアコンポーネントを指します。
OSやブラウザに組み込まれており、アプリケーションからの**DNSクエリ**を受け取り、それをDNSリゾルバに転送し、リゾルバからの応答を受け取ってアプリケーションに返す役割を担います。

**DNSクエリ**
DNSクライアント（DNSリゾルバまたはスタブリゾルバ）が、DNSサーバーに対して特定の情報を要求するために送信するメッセージのことを指します。


## ② ローカルキャッシュの確認
ブラウザは、まず自身が過去にアクセスしたWebサイトのIPアドレスを一時的に保存している「ブラウザキャッシュ」を確認します。もし、入力されたドメイン名のIPアドレスがキャッシュに残っていれば、DNSリゾルバへの問い合わせを行なうことなく、直接そのIPアドレスを使ってサーバーへの接続を試みます。これにより、再アクセス時の表示速度が向上します。
※このプロセスでIPアドレスが見つかれば処理終了になりますが、ない場合は③に続きます。


## ③ OSへ問い合わせ
>![](https://storage.googleapis.com/zenn-user-upload/d1b26e8d200d-20250516.jpeg)
※https://think.unblog.ch/en/how-to-check-and-query-dns-caching/ より

ブラウザキャッシュに目的のIPアドレスが見つからなかった場合、ブラウザは OS にそのドメイン名のIPアドレスを問い合わせます。OSもまた、過去の名前解決結果を**DNSクライアントキャッシュ**として保持しており、ここでIPアドレスが見つかれば、ネットワーク上のDNSリゾルバへの問い合わせは不要となります。
※このプロセスでIPアドレスが見つかれば処理終了になりますが、ない場合は④に続きます。


## ④ キャッシュDNSサーバーへのクエリ送信
![](https://storage.googleapis.com/zenn-user-upload/86fbaec63d9c-20250516.jpeg)
※https://www.nic.ad.jp/ja/newsletter/No51/0800.html より

ローカルのブラウザキャッシュとOSキャッシュの両方に見つからなかった場合に、初めてデバイスに設定された**キャッシュDNSサーバー**（**フルサービスリゾルバ**）に対して、ドメイン名のIPアドレスを要求するDNSクエリがブラウザから送信されます。
上記のイメージ図の"a"に該当します。

**キャッシュDNSサーバー**
キャッシュDNSサーバーは、インターネット上のドメイン名とそれに対応するIPアドレスの対応関係を一時的に記憶（キャッシュ）する機能を持つDNSサーバーのことを指します。
DNSリゾルバの一種で、特に名前解決の結果をキャッシュする機能を持つサーバーを意味します。

**DNSリゾルバ**
クライアントからのDNSクエリ（ドメイン名に対応するIPアドレスの要求）を受け取り、その要求に応えるために必要な一連の処理を行う、ソフトウェアまたはサーバーのことを指します。
このDNSリゾルバには、**スタブリゾルバ**・**フルサービスリゾルバ**があります。
※多くの解説では、「DNSリゾルバ ＝ フルサービスリゾルバ」として解説しているものがありますが、厳密には異なるようです。DNSリゾルバは、クライアントからのDNSクエリを解決する役割を持つ総称であり、その種類の一つがフルサービスリゾルバです。

**フルサービスリゾルバ**
DNSクライアントからの問い合わせを受け、自ら権威DNSサーバーに問い合わせを行なうなど、DNSの階層構造を探索してIPアドレスを取得する能力を持つリゾルバです。
取得した情報をキャッシュする機能を持っているため、**キャッシュDNSサーバー**とも呼ばれます。
ISP が提供するDNSサーバーや、Google Public DNSなどのパブリックDNSサーバーがこれに該当します。

**再帰的問い合わせ**
DNSクライアント（スタブリゾルバ）がキャッシュDNSサーバー（フルサービスリゾルバ）にドメイン名のIPアドレスを問い合わせた際に、フルサービスリゾルバがその問い合わせの解決を最後まで「引き受ける」ことから、このクエリの性質は**再帰的問い合わせ**と呼ばれます。

**「再帰的問い合わせ」と「非再帰的問い合わせ」**
>![](https://storage.googleapis.com/zenn-user-upload/503bb4f89026-20250516.jpeg)
※https://jprs.jp/glossary/index.php?ID=0173 より


## ⑤ DNSリゾルバの処理
### ⑤-a 自身のキャッシュを確認
まず、自身のキャッシュ（過去に問い合わせて得られたDNSレコード）の中に、検索対象である`www.example.com` のIPアドレスが有効な状態で保存されているかを確認します。
**キャッシュに存在する場合**、そのIPアドレスを応答としてDNSクエリを送信したDNSクライアント（デバイスのOSに組み込まれたスタブリゾルバ）に返します。

### ⑤-b キャッシュに存在しない場合
キャッシュDNSサーバー（フルサービスリゾルバ）は、自身のキャッシュに問い合わせられたドメイン名の情報がない場合、そのドメイン名を解決するために、DNSの階層構造に従って権威DNSサーバーへの問い合わせを開始します。
この問い合わせのプロセスは、**ルートサーバー**から始まり、**TLDサーバー**、そして目的のドメインを管理する**権威DNSサーバー**へと段階的に行われます。
これらのキャッシュDNSサーバー（フルサービスリゾルバ）から各DNSサーバーへの問い合わせは、**非再帰的問い合わせ**と呼ばれ、上位の階層から順番に行われます。


### ⑤-b-1 ルートDNSサーバーへの問い合わせ
ドメイン名を解決しようとするキャッシュDNSサーバー（フルサービスリゾルバ）は、まずルートDNSサーバーに、目的のドメインのトップレベルドメイン（例 `.com`）を管理する権威DNSサーバーのアドレスを問い合わせます。

**ルートDNSサーバー**
DNSは、管理領域である**ゾーン**によって階層的に構成されており、この構造によって、インターネット全体のドメイン名空間が一元的かつ分散的に管理されています。
ルートDNSサーバーは**ルートゾーン**と呼ばれる最上部の階層に位置しています。つまり、ルートDNSサーバーは、このルートゾーンで動作するDNSサーバーのことを指します。

>![](https://storage.googleapis.com/zenn-user-upload/6c01c82d7e40-20250516.jpeg)
※https://www.cloudns.net/blog/master-slave-dns/ より

ルートDNSサーバーは、`.com`、`.org`、`.jp` などの**トップレベルドメイン** (**TLD**) を管理する権威DNSサーバーのアドレス情報を持っており、そのTLD（トップレベルドメイン）を管理する権威DNSサーバーのアドレスを応答としてキャッシュDNSサーバー（フルサービスリゾルバ）に返します。
「このサーバーに確認してください」と確認先を応答します。


### ⑤-b-2 TLD (トップレベルドメイン) DNSサーバーへ問い合わせ
ルートDNSサーバーから、目的のドメイン（例えば .com）を管理する権威DNSサーバーのアドレスを受け取ったキャッシュDNSサーバー（フルサービスリゾルバ）は、次に TLD (トップレベルドメイン) DNSサーバーへと問い合わせます。

TLD DNSサーバーは、自身が担当するトップレベルドメイン（例: `.com` であれば、`.com` ドメインに属するすべてのセカンドレベルドメインに関する情報）を管理しています。ただし、通常はセカンドレベルドメイン自身のIPアドレスを直接管理するのではなく、そのセカンドレベルドメインを管理する権威DNSサーバーのアドレス情報を保持しています。

TLD DNSサーバーは、`.com` ドメインを管理する権威DNSサーバーの情報の中から、`example.com` を管理する権威DNSサーバーのアドレスを見つけ出し、キャッシュDNSサーバーに応答として返します。

**ドメインの階層構造**
>![](https://storage.googleapis.com/zenn-user-upload/531a8d81a577-20250516.jpeg)
※https://xtech.nikkei.com/atcl/nxt/column/18/00780/062000011/?P=2 より


### ⑤-b-3 セカンドレベルドメインDNSサーバーへの問い合わせ
キャッシュDNSサーバー（フルサービスリゾルバ）は、`.com` TLD DNSサーバーから得られた `example.com` ドメインの権威DNSサーバーに、`www.example.com` のIPアドレスを問い合わせます。
このセカンドレベルドメインDNSサーバーは、`example.com` という特定のドメインに関する正式な情報（DNSレコード）を管理している、いわばそのドメインの「本家」のような存在です。キャッシュDNSサーバーはここで、最初に知りたかった `www.example.com` のIPアドレスを直接尋ねます。


### ⑤-b-4 権威DNSサーバーからの応答
問い合わせを受けた `example.com` の権威DNSサーバーは、自身の持つDNSレコードの中から `www.example.com` に対応するIPアドレスを見つけ出し、その答えをキャッシュDNSサーバー（フルサービスリゾルバ）へ返します。


### ⑤-c 結果のキャッシュ
キャッシュDNSサーバー（フルサービスリゾルバ）は、権威DNSサーバーから受け取ったIPアドレスを、そのDNSレコードに設定されたTTL (Time To Live) にしたがって自身のキャッシュに保存します。これにより、同じドメイン名への問い合わせに対して、高速に応答できるようになります。


## ⑥ キャッシュDNSサーバーからクライアントへ応答
キャッシュDNSサーバー（フルサービスリゾルバ）は、取得した `www.example.com` のIPアドレスを、④で問い合わせてきたDNSクライアント（OSのDNSクライアント機能）に応答として返します。


## ⑦ OSからブラウザへ応答
OSのDNSクライアント機能は、受け取ったIPアドレスをブラウザに伝えます。


## ⑧ ブラウザがWebサーバーへ接続
ブラウザは、取得したIPアドレスを使って、`www.example.com` のWebサーバーに対してTCP接続を確立し、HTTP/HTTPSリクエストを送信してWebページのコンテンツを取得します。


# まとめ
DNSによる名前解決には多くのプロセス、多くの関連ワードがあります。これらを1つ1つ理解していくことで、名前解決のプロセスの全体像とさまざまな解説の意味を理解することができるようになります。
文脈によって同じ立ち位置でも使用されるワードが変わってくるので、しっかり整理しておきましょう。
最後までお読みいただき、ありがとうございました。


# 参考・画像引用元URL
https://www.rworks.jp/system/system-column/sys-entry/21619/
https://www.xdomain.ne.jp/column/about-dns
https://www.rworks.jp/system/system-column/sys-entry/21619/
https://www.infraexpert.com/study/tcpip24.html
https://think.unblog.ch/en/how-to-check-and-query-dns-caching/
https://jprs.jp/glossary/index.php?ID=0173
https://www.cloudns.net/blog/master-slave-dns/
https://xtech.nikkei.com/atcl/nxt/column/18/00780/062000011/?P=2