Zenn
😺

ドメインと、その原理

2025/03/28に公開
DNS
url
ドメイン
レコード
dnsサーバ
tech

はじめに

こんにちは！
情報系の学部に通うインターン生です！

今回は、ドメインについて、その原理があまりよくわかっていなかったので、調べた結果をまとめたいと思います！

この記事では、ドメインとDNSの仕組み、基本的なレコードの役割、DNSサーバの構造や管理主体などを体系的にまとめました！
初心者の方にもわかりやすく、実践的な理解が深まる内容を目指します。

基礎知識

ドメインとは

ドメインとは、インターネット上の住所のようなものであり、Webサイトを識別するための文字列。
例：example.com や google.co.jp などがそれにあたる。

ドメインは階層構造になっており、右から左に向かって特定性が高くなる。

.com や .jp は「トップレベルドメイン（TLD）」
example.com 全体で「セカンドレベルドメイン」

ドメインはICANNなどの国際機関によって管理され、レジストラ（例：お名前.comなどのドメイン登録サービス）を通じてユーザーが取得・管理できる。

URLとは

URL（Uniform Resource Locator）とは、インターネット上の特定のリソース（ページや画像など）を指し示す完全な住所である。
例：https://example.com/about のように構成される。

構成要素は以下の通り：

https://example.com/about
└───┬─┘└─┬────────┘└─┬────┘
    │    │           └ パス（リソースの場所）
    │    └─ ホスト名（＝ドメイン名）
    └───── プロトコル（通信方式）

URLはドメイン名を含みつつ、ページの場所や通信手段までを指定している点が特徴である。

DNSサーバとは

DNSサーバ（Domain Name Systemサーバ）とは、ドメイン名とIPアドレスを相互に変換する仕組みを提供するサーバ。

インターネットでは本来、通信はIPアドレス（例：93.184.216.34）で行われるが、人間にとっては覚えづらいため、代わりに「example.com」などのドメイン名が使われる。

DNSサーバの主な役割は

  • 「example.comはどのIPアドレスか？」といった名前解決
  • Aレコード、CNAME、MXレコードなどを返す
  • 階層構造（ルートDNS → TLD DNS → 権威DNS）で分担して動作する

この名前解決があるおかげで、ユーザーはIPアドレスを意識せず、快適にWebを利用できる。

DNSは3階層構造になっている

  1. ルートDNSサーバ：すべてのTLD（トップレベルドメイン）を管理する。例：.comや.jpなど。
  2. TLD DNSサーバ：各TLDごとに存在し、ドメイン名の管理を委任されている。
    例：.comはVerisign、.jpはJPRS。
  3. 権威DNSサーバ：実際にAレコードなどの情報を保持し、ドメインの最終的な解決を担う。
    例：お名前.comなど。

名前解決（ドメイン→IPアドレス）の流れ

ユーザーがブラウザで「example.com」にアクセスするまでに、以下のような手順が行われる

  1. ローカルやISPのキャッシュを確認（なければ次へ）
  2. ルートDNSに「.comのDNSどこ？」と問い合わせ
  3. VerisignのTLD DNSが「example.comのDNSはns1.onamae.comだよ」と返答
  4. 権威DNS（お名前.comのDNS）が「example.comのIPは122.222.222.222だよ」と返す

このようにして、ドメインとIPアドレスが紐づき、正しいWebサーバにアクセスできるようになる。

ルートDNSサーバ・TLD DNSサーバはIPアドレスを持っていない？

VerisignのようなTLD DNSサーバは、IPアドレス（Aレコード）を保持していない。
彼らは「example.comはどのDNSサーバが管理しているか（＝NSレコード）」を知っているだけ。

ルートDNSサーバがIPアドレスを教えてくれた方が早いじゃん！

結論：不可能かつ非効率。
ルートDNSサーバは、IPアドレスではなく “次にどこに問い合わせればいいか” だけを教えるように設計されている。
主な理由３つ↓

世界中のすべてのドメイン情報をルートが管理するのは不可能

ルートDNSがすべてのドメインのAレコード（IPアドレス）を持とうとした場合、何億ものドメイン情報を保持・更新し続けなければならない。

ドメインの登録・変更は毎日のように世界中で行われており、ルートDNSにそのすべてをリアルタイムで反映するのは現実的でない。

変更に追従できない

IPアドレス（Aレコード）はドメイン所有者の都合で頻繁に変わる。

一方、ルートDNSサーバはインターネットの根幹インフラとして非常に安定かつ滅多に変更されないことが求められている。

ルートDNSに動的な情報（IPアドレス）を持たせることは、安定性と信頼性を損なう行為である。

負荷が集中してしまう

すべての名前解決がルートDNSに集中すると、全世界からの膨大なトラフィックが一箇所に集まってしまう。

現在のように階層で分散されているからこそ、各TLDや権威DNSが分担して負荷を受け持てる仕組みになっている。

お名前.comでドメインを取得した場合の処理

お名前.comでexample.comを取得した場合、次のような手続きが行われる。

  1. お名前.comがVerisignに「example.comはns1.onamae.comで管理」とNSレコードを登録
  2. ユーザーはお名前.comの管理画面で、example.comに対するAレコード（IP）を登録

レコードとは

DNSにおける「レコード」とは、ドメイン名に関する情報を記述したデータの単位である。
DNSサーバはこのレコード情報を参照して、ドメイン名とIPアドレスの対応関係や、メールサーバ、別名の情報などを返答する。

DNSレコードは、ゾーンファイル（DNSの設定ファイル）の中に記述されており、以下のような形式で構成される

example.com.    IN    A     123.123.123.123

この1行が「1レコード」である。

よく使われるDNSレコードと解説

  • Aレコード ドメイン名をIPv4アドレスに紐づける
    • example.com → 123.123.123.123
  • CNAMEレコード 別名（エイリアス）を定義し、他のドメイン名に転送する
    • www.example.com → example.com
    • shop.example.com → myapp.hosting-service.com

CNAMEレコードを使えば、1つの実体（サーバやIP）に対して、複数のドメイン名を割り当てることができる。
そのため、「実質的に複数の独自ドメインを持てる」ような振る舞いが可能になる。

※CNAMEは「エイリアス（別名）」であり、本当に複数のドメインを所有しているわけではない。

実際にドメインを取得してみる（お名前ドットコム）

https://www.onamae.com/advanced/
このサイトにアクセスして、適当なドメインを検索する。

検索結果
その名前のドメインが使えるかどうかが確かめられる。

好きなトップレベルドメイン（TLD：Top Level Domain、.comや.jpなど）を選んでクレジットカードを登録することで自分のものになる。（お名前ドットコムアカウントの作成も必要）

github student developer packの特典として、.techというドメインも無料で取得できたので、登録してみたが、基本的な手順は一緒だった！

実際にレコードを登録してみる

今回は、お名前ドットコムで取得したドメインをGithubpagesで公開したページに紐づけます。

  1. まずGithubpages側で取得したドメインを設定する。（詳細は省略）
  2. お名前ドットコムで「TOP」 > ドメイン名を選択 > 「ドメイン機能一覧」 > 「DNS設定」 > 「DNSレコード設定」 > 「レコードを追加」
  3. ホスト名「www」、VALUE「Githubアカウント名.github.io」のCNAMEレコードを追加する。
  4. 以下のAレコードを追加する。ホスト名は空白
185.199.108.153  
185.199.109.153  
185.199.110.153  
185.199.111.153

以下の理由によりGithubがIPアドレスを複数用意しているため、Aレコードを複数追加する必要がある。

  • 冗長性：どれかのサーバが落ちても、他がカバーできる
  • 負荷分散：アクセスが複数のサーバに分散されて混雑しにくい
  • 高速化：世界中のユーザーが近くのサーバに接続できる（Anycast対応）

    上4つはもとから設定されているもの

最後に

今までふわふわとしか理解できていなかったドメイン・DNSについて、以前よりも理解を深めることができました！

WEB開発をするものとしては必要な情報なので、これからも独自ドメイン・レコードを使って忘れないようにしていこうと思います！

参考元

Discussion