DNSとは？ドメイン名をIPアドレスに変換する仕組みをやさしく解説【第32回】

この記事でわかること

なぜIPアドレスではなくドメイン名を使うのか
ドメイン名の階層構造（右から読む意味）
DNSサーバーの種類と役割（ルート・TLD・権威DNS・リゾルバー）
名前解決のリレー——PCがIPアドレスを手に入れるまでの流れ
DNSキャッシュとTTL、「DNS伝搬に時間がかかる」理由
代表的なDNSレコードの種類（A・CNAME・MX・TXTなど）
nslookup・digコマンドで名前解決の結果を確認する方法

はじめに

インターネットに接続するには、相手のIPアドレスが必要です。でも私たちは 142.250.185.46 と入力してGoogleを開くことはしません。google.com と入力します。

もしDNSが存在しなかったら、ウェブを使うたびに相手のIPアドレスを暗記しなければなりません。Googleは 142.250.185.46、Amazonは 205.251.242.103……数十億のサイトが存在するインターネットで、それは現実的ではありません。

DNS（Domain Name System） は、人間が覚えやすい「名前（ドメイン名）」とコンピューターが使う「番号（IPアドレス）」を結びつける仕組みです。インターネットの電話帳——そんなイメージです。

DNSとは何か

英単語を分解してみましょう。

Domain（ドメイン）：「領域」「管轄範囲」という意味。インターネットでは「名前の管轄単位」を指します
Name（ネーム）：「名前」
System（システム）：「仕組み」「体系」

合わせると「ドメイン名の体系」です。

DNSはただの名前帳ではありません。インターネット全体に分散した巨大なデータベースです。世界中のドメイン名とそれに対応するIPアドレスの情報を、階層的に管理しています。

ドメイン名の構造——右から読む

www.google.com というドメイン名を見てみましょう。これは右から左へ読むと、階層構造が見えてきます。

www  .  google  .  com  .
 ↑         ↑         ↑    ↑
サブ    第2レベル    TLD   ルート
ドメイン  ドメイン        （省略）

ルート（.）：最上位の階層。普段は省略されていますが、正式なドメイン名の末尾には .（ドット）があります
TLD（com）：Top Level Domain（トップレベルドメイン）→「最上位のドメイン」。.com・.jp・.net・.org などがこれにあたります
第2レベルドメイン（google）：組織や個人が取得するドメイン名。「google.com」のこと
サブドメイン（www）：第2レベルドメインの下に設ける区分。www（ウェブ）・mail（メール）・api（API）など用途ごとに設けられます

ドメイン名の階層は、ちょうどファイルシステムのフォルダ構造に似ています。右が上位（大きな括り）、左が下位（具体的な宛先）です。

DNSサーバーの種類

名前解決を支えるDNSサーバーには4種類あります。それぞれの役割を理解すると、名前解決の流れが見えてきます。

① フルリゾルバー（キャッシュDNSサーバー）

Resolver（リゾルバー）：Resolve（解決する）+ -er（〜するもの）→「名前を解決するもの」

あなたのパソコンやルーターが「DNSサーバー」として設定している相手がこれです。第25回で学んだDHCPが自動配布する4項目のひとつ（DNSサーバーのIPアドレス）がこのフルリゾルバーの住所です。

フルリゾルバーはクライアントの代わりに、次の③④のサーバーに問い合わせて回答を返します。よく使われるものには 8.8.8.8（Google）や 1.1.1.1（Cloudflare）があります。

② スタブリゾルバー

あなたのパソコン内部に組み込まれた、最もシンプルなDNSクライアントです。ブラウザが「このドメイン名のIPアドレスを調べて」と依頼すると、スタブリゾルバーがフルリゾルバーに問い合わせを投げます。

③ ルートDNSサーバー

DNS階層の最上位に立つサーバーです。世界に13セット（a〜m.root-servers.net）が配置されています。どのTLDのDNSサーバーに聞けばよいかを知っています。

④ TLDネームサーバー

.com・.jp などのTLDを管轄するサーバーです。「google.com の情報は、Googleが管理する権威DNSサーバーに聞いてください」と教えてくれます。

⑤ 権威DNSサーバー（Authoritative DNS）

Authoritative（オーソリタティブ）：「権威ある」「公式の」という意味

そのドメインの正式な情報を持つサーバーです。google.com の情報はGoogleが管理する権威DNSサーバーが保持しており、ここに聞けば正確なIPアドレスが返ってきます。

名前解決の流れ——リレーで届くIPアドレス

www.google.com のIPアドレスが手に入るまでの流れを順番に見ていきましょう。

① あなたのPC（スタブリゾルバー）
   「www.google.comのIPアドレスを教えて」
           ↓
② フルリゾルバー（8.8.8.8 など）
   「キャッシュにない。ルートに聞こう」
           ↓
③ ルートDNSサーバー
   「.comはこのTLDサーバーが担当です」
           ↓
④ .com TLDネームサーバー
   「google.comはこの権威DNSサーバーが担当です」
           ↓
⑤ google.comの権威DNSサーバー
   「www.google.com = 142.250.185.46 です」
           ↓
⑥ フルリゾルバーが結果をキャッシュして①に返答
           ↓
⑦ あなたのPC
   「IPアドレスは 142.250.185.46」

フルリゾルバーが「自分で知らなければ上位に聞く」を繰り返しながら答えを集めてくることを、再帰的（Recursive）な問い合わせと呼びます。

Recursive（リカーシブ）：「再帰的な」→ 答えが得られるまで何度も繰り返す

あなたのPCはフルリゾルバーに1回聞くだけで済みます。ルートへの問い合わせや、TLDへの問い合わせはフルリゾルバーが代わりにすべてやってくれます。

このリレーが完了するまでの時間はミリ秒単位ですが、仕組みとしては複数のサーバーを経由していることになります。

DNSキャッシュとTTL

毎回このリレーを最初から行っていては、世界中のフルリゾルバーがルートDNSサーバーに殺到してしまいます。そこで各段階でキャッシュ（一時保存）が使われます。

フルリゾルバーが過去に解決した結果を保存
あなたのOSもDNSキャッシュを持つ
ブラウザ自身もDNSキャッシュを持つ

キャッシュの有効期限を決めるのが TTL（Time To Live） です。

IPパケットのTTL（ルーターを通るたびに減る）とは別の概念です。DNSのTTLは「このレコードを何秒間キャッシュしてよいか」をドメインの管理者が設定します。

www.google.com.   300   IN   A   142.250.185.46
                   ↑
                TTL=300秒（5分間キャッシュしてよい）

TTLが切れると、次の問い合わせ時にまた上位のサーバーへ確認が走ります。

DNS伝搬（DNS Propagation）に時間がかかる理由

ウェブサイトを別のサーバーに引っ越したとき、「DNSが浸透するまで数時間〜数日かかる」と言われます。その理由がTTLです。

旧サーバーのIPアドレスがフルリゾルバーにキャッシュされている間は、そのキャッシュが使われ続けます。TTLに設定した時間が過ぎてキャッシュが消えて初めて、新しいIPアドレスへの問い合わせが行われます。

TTLを短く設定（たとえば300秒）しておけば伝搬は速く、長く設定（86400秒=1日）しておけば伝搬に時間がかかる代わりにDNSサーバーへの負荷が減ります。

代表的なDNSレコードの種類

DNS はIPアドレス以外にもさまざまな情報を管理しています。情報の種類ごとに「レコードタイプ」があります。

レコードタイプ	用途
A	ドメイン名 → IPv4アドレス（最も基本的なレコード）
AAAA	ドメイン名 → IPv6アドレス（AAAはAAAAと4つ続く。IPv6が128ビットで4倍の意味）
CNAME	ドメイン名 → 別のドメイン名（エイリアス・別名）
MX	メール配送先サーバーの指定（Mail eXchange = メール交換）
NS	そのドメインの権威DNSサーバーの指定（Name Server）
TXT	テキスト情報（SPFやDKIMによるメール認証、ドメイン所有確認に使われる）
PTR	IPアドレス → ドメイン名への逆引き（Pointer）

たとえば blog.example.com が example.com と同じサーバーを指したいとき、CNAMEレコードで blog.example.com → example.com と設定します。example.com のIPアドレスが変わっても、CNAMEだけ設定していれば自動で追従します。

DNSが使うプロトコルとポート番号

DNSは原則としてUDPの53番ポートを使います。問い合わせ・応答ともに小さなパケットで完結するため、接続確立の手間がないUDPが適しています。

ただし応答データが大きくなる場合（たとえば多くのレコードを返す場合）や、ゾーン転送（権威DNSサーバー同士がレコードを同期する操作）にはTCPの53番ポートを使います。

この「小さなやりとりはUDP、大きなデータはTCP」という使い分けは、第29回で学んだUDPとTCPの特性をそのまま活かしたものです。

パブリックDNSサーバー

フルリゾルバーとして世界中から利用できる「パブリックDNSサーバー」が公開されています。

提供元	IPアドレス
Google Public DNS	`8.8.8.8` / `8.8.4.4`
Cloudflare	`1.1.1.1` / `1.0.0.1`
OpenDNS（Cisco）	`208.67.222.222`

デフォルトでは、ISPが提供するDNSサーバーやルーターのDNS機能が使われています。上記のパブリックDNSに変更すると、ISP側のDNSキャッシュの状態に左右されず、応答速度や信頼性が改善することがあります。

nslookupとdigコマンドで確認してみよう

nslookupコマンド（Windows / Mac / Linux）

nslookup google.com

次のような出力が得られます。

Server:  192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name:    google.com
Address: 142.250.185.46

Server が問い合わせ先のDNSサーバー（ここではルーター）
Non-authoritative answer は「権威DNSサーバーから直接返ってきたのではなく、キャッシュから返ってきた回答」という意味です

MXレコード（メール配送先）を調べたいときは：

nslookup -type=MX google.com

digコマンド（Mac / Linux）

dig はより詳細な情報を表示します。

dig google.com

TTLの値やレコードタイプも一緒に確認できます。

;; ANSWER SECTION:
google.com.		300	IN	A	142.250.185.46
               ↑
            TTL（秒）

dig +trace——名前解決のリレーを実際に見る

dig +trace google.com

ルートDNSサーバーから権威DNSサーバーまで、名前解決がどのようにリレーされるかを段階的に表示します。

.			518400	IN	NS	a.root-servers.net.
...（ルートDNSサーバーの一覧）

com.			172800	IN	NS	a.gtld-servers.net.
...（.com TLDサーバーの一覧）

google.com.		345600	IN	NS	ns1.google.com.
...（Googleの権威DNSサーバー）

google.com.		300	IN	A	142.250.185.46
（最終的なIPアドレス）

実際に実行すると、「こんなにたくさんのサーバーを経由していたのか」という驚きとともに、階層構造が目で見えます。

Windowsでのdns キャッシュ確認・クリア

ipconfig /displaydns   ← キャッシュ確認
ipconfig /flushdns     ← キャッシュクリア

サイトにアクセスできない原因がDNSキャッシュの古い情報にある場合、flushdns でキャッシュを消去すると解決することがあります。

まとめ

DNSは「ドメイン名（人間が読める名前）」を「IPアドレス（コンピューターが使う番号）」に変換する分散データベースの仕組み
ドメイン名は右から読むと階層が見える。ルート → TLD（.com / .jp）→ 第2レベル（google）→ サブドメイン（www）
DNSサーバーには4種類あり、名前解決はフルリゾルバー→ルートDNS→TLD DNS→権威DNSというリレーで行われる
結果は各段階でキャッシュされ、TTL（秒数）が有効期限を決める。TTLが伸びるほどDNS変更の伝搬に時間がかかる
代表的なレコードタイプは A（IPv4アドレス）・AAAA（IPv6）・CNAME（別名）・MX（メール配送先）・TXT（テキスト情報）
DNS通信は通常UDP 53番ポートを使い、大きなデータや同期処理にはTCP 53番ポートを使う
nslookup（全OS）や dig +trace（Mac/Linux）でドメイン名の解決結果と経路を確認できる