ドメイン名とは、DNSの階層的な名前空間にある名前
ドメイン名は、ドットで区切ったラベルを階層として並べ、インターネット上のWeb、メール、その他の資源を識別・参照するために使う名前です。
RFC 1034は、ドメイン名をルートまでの経路上にあるラベルの並びとして説明し、最も具体的なラベルからルートに近いラベルへ左から右に表記します。example.comでは、comがトップレベルドメイン（TLD）、exampleがその直下のラベルです。末尾のルートラベルまで明示した完全修飾表記はexample.com.ですが、利用者向け画面では最後のドットを省くのが一般的です。日本語の会話では「ドメイン」と「ドメイン名」を同じ意味で使うことが多い一方、DNSの技術用語としてdomainは、あるノード以下の名前空間全体を指す場合もあります。この記事では、登録・URL・メールで使う文字列を主に「ドメイン名」と呼びます。
階層は右から左へ読む
www.shop.example.comなら、ルートの直下がcom、その下がexample、さらにshop、wwwです。DNSの管理は階層の途中で委任できます。ただし、どの階層を一般利用者が登録できるかはTLDの規則で異なります。.comのexample.comと、.jpのexample.co.jpでは登録対象となる境界が同じ見た目ではありません。
登録は契約に基づく管理権限
ICANNは、登録者がレジストラと契約し、契約条件に従って登録・維持される名前を管理すると説明しています。土地や物品を無期限に所有するのとは異なり、期間、更新、連絡先、利用規則、紛争処理等に従う登録です。「購入して永久所有」とは考えず、登録者情報、期限、支払方法、移管方法を継続管理します。
ドメイン名を登録しただけでは、Webサイトもメールも動かない
登録により名前の管理を始めても、権威DNSへの委任、DNSレコード、Web・メールの提供先、TLS証明書、アプリケーション設定は別です。逆にサーバーを契約しても、ドメイン名とDNSを接続しなければ希望する名前では到達できません。障害時は登録、委任、DNS応答、ネットワーク、TLS、Webの順に層を分けて確認します。
具体例：URL入力からWebページ表示までを分解する
ブラウザへ「https://shop.example.com/products/42?color=blue#spec」と入力した例を追います。example.comと192.0.2.1は文書用の例示であり、実サービスの接続先を示すものではありません。実際にはIPv4とIPv6、CDN、複数の接続先、キャッシュ、プロキシ等が関与する場合があります。
URLの構成
https://shop.example.com/products/42?color=blue#spec
httpsがスキーム、shop.example.comがホスト、/products/42がパス、color=blueがクエリ、specがフラグメントです。URLは資源の指定全体で、ドメイン名はホスト部分を構成する名前です。ポート番号が明示される場合はホストの後ろに続きます。
DNSで調べる名前
shop.example.com. A / AAAA → 接続先IP
リゾルバーはURL全体ではなく、ホスト名に対する必要なレコードを問い合わせます。AはIPv4アドレス、AAAAはIPv6アドレスを表します。CNAMEで別名をたどる構成もあります。得られた値はTTL等に従ってキャッシュされるため、変更が全利用者へ同時に見えるとは限りません。
ブラウザが行う処理の概略
- 1URLを解析する：スキーム、ホスト、ポート、パス、クエリ、フラグメントへ分ける。フラグメントは通常、サーバーへのHTTP要求には含めず、取得した表現内の位置指定等に使う。
- 2名前を解決する：端末やブラウザのキャッシュを確認し、必要ならキャッシュDNSへshop.example.comのA・AAAA等を問い合わせる。キャッシュDNSは保持情報または権威DNSへの問い合わせから応答を得る。
- 3接続して相手を確認する：得られたIPアドレスへHTTPSで接続し、ホスト名に対応するTLS証明書を検証する。同じIPで複数サイトを提供できるため、IPアドレスだけでは閲覧先を一意に決められない。
- 4HTTP要求を送る：ホストと/products/42?color=blueを指定して応答を受ける。Webサーバーやアプリがコンテンツを返し、ブラウザが描画して#specに対応する位置を扱う。
ドメイン名はURLのホスト部分に現れ、DNSはその名前に対応する接続情報を返し、Webサーバーがページを返します。三者は一連の処理で連携しますが、同じものではありません。
ドメイン名の階層と利用場面を整理する
「末尾がTLD、その前がセカンドレベル」と数えるだけでは、登録単位や用途を誤解することがあります。IANAのRoot Zone DatabaseはTLDと管理者の委任情報を示します。その下で何を登録できるか、資格や個数に制限があるかは各レジストリの規則で決まります。JPRSでは汎用JP、都道府県型JP、CO.JP等の属性型・地域型JPを区分しています。
表は横方向にスクロールできます
| 対象 | 例 | 役割・意味 | 注意点 |
|---|---|---|---|
| TLD | .com、.org、.jp | DNSルート直下のトップレベルドメイン。IANAのRoot Zone Databaseに委任情報が記録される | gTLD・ccTLD等の区分だけで、登録資格、料金、信頼性、SEO効果を一律に判断しない |
| 登録ドメイン名 | example.com | .com配下で登録者がレジストラを通じて登録・管理する例。Webとメールの共通基盤にできる | 登録可否、商標、契約、更新価格、移管、回復条件、連絡先、権限を確認する |
| JPの登録例 | example.jp、example.co.jp | 汎用JPと属性型JPでは構造・登録資格・登録数等の規則が異なる | coを単にサイト名と呼ばず、JPRSの現行区分と登録規則で登録単位を確認する |
| サブドメイン／ホスト | shop.example.com、www.example.com | 登録済み名前の配下に管理者が作る名前。サイト、API、管理画面等を分けられる | 環境・権限・Cookie・TLS・検索公開範囲を名前だけで安全に分離できるとは限らない |
| メールドメイン | user@example.com | @の右側がメール配送で参照されるドメイン名。MX等が配送先の判断に使われる | Web用Aレコードだけではメールは完成しない。MX、送受信サービス、SPF・DKIM・DMARC等を別途設計する |
| 国際化ドメイン名 | 日本語.jp など | Unicode文字を利用者向けに表示し、DNSではASCII互換表現へ変換して扱う仕組み | 利用可能文字、正規化、メール対応、見た目が似た文字、表示・入力環境を確認する |
「wwwは必須」「TLD直前が必ず取得者の名前」と決めつけない
wwwは慣習的なホスト名の一つで、必須ではありません。また登録境界はTLDごとの規則やPublic Suffixの扱いで異なります。example.comではexample.comを登録する例が一般的ですが、example.co.jpではexample.co.jpが登録単位です。文字列の位置だけで所有・登録関係を推測せず、レジストリまたはRDAP等の現行情報を確認します。
登録・運用で確認する6つの項目
名前の短さや初年度価格だけで決めると、更新、移管、権限、メール、ブランド保護で問題が起きます。登録前から廃止までのライフサイクルとして管理します。
登録単位・資格・類似名
希望文字列が登録可能か、個人・法人・所在地等の資格があるか、同名・表記揺れ・ハイフン・複数TLDをどう扱うかを確認します。商標や第三者の権利も、空いているかどうかとは別に確認します。
Web・メールの利用設計
ルート名、www、shop、api、管理画面、メールをどの名前で提供するかを決めます。A・AAAA・CNAME・MX・TXT等は目的が異なり、同じ名前で組み合わせられない構成もあるためDNS事業者の仕様を確認します。
期限・更新・失効・回復
登録期間、満了日、自動更新、更新価格、請求連絡先、失効後の停止・回復・削除条件を確認します。ICANNの説明では典型的なgTLDの登録期間は1〜10年ですが、TLDと契約で異なります。更新通知だけに依存せず、複数人で期限を監視します。
アカウント・変更権限
登録者名義、管理用メール、レジストラとDNSの多要素認証、最小権限、監査ログ、移管ロック、重要変更の承認手順を整えます。退職者や制作会社個人のアカウントだけに管理を残しません。
表記・国際化・ブランド
音声で伝えやすいか、誤入力しにくいか、他言語で不適切な意味がないか、IDNとASCII表記をどの画面で使うかを確認します。似た文字を使うなりすましへの監視と、正式ドメインの周知も検討します。
変更・移管・廃止の検証
DNS変更は事前にTTL、旧新の併存、TLS、メール、リダイレクト、監視、切り戻しを計画します。移管時はAuthCode等の要件を確認し、廃止時はWebだけでなくメール、API、OAuth、Cookie、証明書、外部サービス連携を洗い出します。
DNSSEC、TLS、レジストリロックは代替関係ではない
DNSSECはDNS応答の真正性検証を支援し、TLSは接続先の認証と通信保護を担います。レジストリロックやレジストラロックは登録情報・移管等の変更統制に関係します。一つを導入しても他の層の脅威は消えないため、対象TLD・事業者の対応と運用手順を確認して組み合わせます。
ドメイン名・DNS・URL・サーバーの違い
似た語を「住所」「電話帳」「土地」といった比喩だけで覚えると、障害箇所や変更責任を誤ります。何を識別し、誰が設定し、どの段階で使われるかで分けます。
| 用語 | 定義・役割 | ドメイン名との違い |
|---|---|---|
| ドメイン名 | DNSの階層的な名前空間にある、ドット区切りのラベルで構成された名前 | Web・メール等で使える識別名。登録、委任、DNSレコード、サービス提供は別工程 |
| DNS | ドメイン名に対応するIPアドレス、メール配送先等の資源レコードを分散管理・問い合わせする仕組み | 名前そのものではなく、名前空間と対応情報を扱うシステム。Web本文を保存・配信する仕組みではない |
| URL | スキーム、権限部、ホスト、ポート、パス、クエリ、フラグメント等で資源を識別する表現 | ドメイン名はURLのホスト部分に使われ得るが、URL全体ではない。URLのホストがIPリテラルの場合もある |
| IPアドレス | IPネットワークでインターフェースや接続先を扱う数値のアドレス | DNSでドメイン名から取得する情報の一種。同じ名前に複数IP、同じIPに複数ホストを対応させられる |
| Webサーバー | HTTP要求を受けてHTML、画像、API応答等を返すソフトウェアまたはその実行環境 | ドメイン名を登録・管理する主体ではない。DNSが接続先を示した後にコンテンツを提供する層 |
| ホスト名 | ネットワーク上のホストやサービスを識別するために使うドメイン名。shop.example.com等 | 登録ドメイン名の配下へ管理者が設定する場合がある。会話ではドメイン名と呼ばれても、登録単位とは限らない |
| サブドメイン | あるドメインの名前空間に含まれる下位のドメイン。shop.example.comはexample.comの下位 | 通常は登録済みドメインの管理者がDNSで作る。必ず別契約・別サーバー・別組織になるわけではない |
| レジストラ／レジストリ | レジストラは登録者へ登録・管理窓口を提供し、レジストリはTLDの登録データベース等を管理する | ホスティングやDNSと同じ会社が提供することもあるが役割は別。障害・移管時は契約先と管理主体を切り分ける |
リダイレクトはDNSの機能ではない
example.comからwww.example.comへ転送したい場合、DNSは接続先を示せてもHTTP 301・308等の応答は返しません。通常はWebサーバー、CDN、ロードバランサー等でリダイレクトを設定し、転送元・転送先双方のDNSとTLSを成立させます。「DNS転送」と表示する事業者機能も、内部でHTTPサービスを使う場合があります。
取得から運用までの実務手順
ドメイン名は公開後にWeb、メール、認証、外部サービスへ広がります。取得時だけでなく、変更・移管・失効・廃止まで戻せる手順を残します。
- 1
用途、名前、登録資格、権利を確認する
企業名・サービス名・メール利用・対象国を整理し、候補の読みやすさ、誤入力、類似名、商標、TLDの登録資格を確認します。空き表示は第三者の権利を保証しません。
- 2
契約主体と管理者を決めて登録する
会社利用なら会社が管理できる名義・メール・支払方法を使い、レジストラの更新価格、移管、失効・回復、サポート条件を確認します。登録後は管理画面に多要素認証を設定し、回復手段を保管します。
- 3
権威DNSとサービス別レコードを設計する
どのDNS事業者を権威とするかを決め、WebのA・AAAA・CNAME、メールのMX、検証や送信認証に使うTXT等を目的ごとに設定します。委任先ネームサーバーとゾーンの内容が一致しているか確認します。
- 4
Web・メール・TLSを接続して外部から確認する
複数のネットワークとキャッシュ条件からDNS応答、IPv4・IPv6、TLS証明書、HTTP状態、正規URL、メール送受信を確認します。管理画面の表示だけを成功条件にせず、権威応答と実際の通信を観測します。
- 5
更新、変更、移管、緊急時を運用する
満了日、更新責任者、請求、登録者情報、DNS変更履歴を定期確認します。変更はTTL調整、旧新併存、監視、切り戻しを準備し、乗っ取り・誤変更・失効時の連絡先と復旧証跡を整えます。
変更直後の見え方を「反映待ち」だけで片付けない
DNSキャッシュは差の一因ですが、委任先の不一致、権威サーバー間の差、誤ったレコード、DNSSEC検証失敗、IPv4・IPv6の片側不備、TLS、Web設定も確認が必要です。問い合わせたリゾルバー、レコード型、応答値、TTL、時刻を記録し、層ごとに切り分けます。
一次資料・公式資料
用語定義、階層、URL構文、登録・更新、JPドメイン名の区分は、次の一次資料・管理組織資料で確認しました。
ドメイン名についてよくある質問
ドメインとURLは同じですか？
同じではありません。ドメイン名はDNSの階層的な名前です。URLはhttps等のスキーム、shop.example.com等のホスト、パス、クエリ、フラグメント等を含む資源の識別表現で、ドメイン名はそのホスト部分に使われます。
ドメイン名とDNSは同じですか？
同じではありません。ドメイン名は名前、DNSはその名前空間と、名前に対応するIPアドレス・メール配送先等の情報を分散管理して問い合わせる仕組みです。DNSを設定してもWeb本文はWebサーバー等が返します。
wwwはドメイン名に必須ですか？
必須ではありません。wwwはexample.com配下に作れるホスト名の慣習的な例です。example.comとwww.example.comの両方を使う場合は、DNS、TLS、Web設定を用意し、検索や共有で使う正規URLを決めてリダイレクト等を設計します。
ドメイン名を登録すれば、すぐサイトを表示できますか？
登録だけでは表示できません。権威DNSを委任し、A・AAAA・CNAME等で接続先を設定し、接続先でWebサーバーまたは配信サービスを構成し、HTTPSなら証明書を用意します。各層が揃って初めて希望URLで閲覧できます。
ドメイン名は一度買えば永久に使えますか？
永久所有ではありません。登録者はレジストラとの契約とTLDの規則に従い、登録期間中の名前を管理します。継続利用には期限前の更新が必要です。期間、料金、失効後の回復・削除条件はTLDと事業者で異なります。
DNSの変更は何時間待てば必ず反映しますか？
一律の時間は決められません。旧応答のTTL、各キャッシュの保持状態、委任変更、権威サーバーの同期、負のキャッシュ等で異なります。待つだけでなく、権威DNSと複数リゾルバーの応答、TTL、A・AAAA等の型を時刻付きで確認します。
ドメイン名とサーバーは同じ会社で契約すべきですか？
必須ではありません。同じ事業者なら初期設定が簡単な場合がありますが、登録者名義、移管性、DNS機能、障害時の責任分界、更新価格、解約時の手順も比較します。会社が変わっても、レジストラ、権威DNS、ホスティングの役割を記録しておけば管理できます。
DNSSECを有効にすればドメインは安全ですか？
DNSSECは重要な一層ですが、すべての脅威を防ぎません。レジストラアカウントの乗っ取り、誤設定、Webサーバー侵害、TLS不備、フィッシング、更新忘れ等には別の対策が必要です。多要素認証、最小権限、変更承認、TLS、監視、更新管理と組み合わせます。
関連する用語・実装
まとめ：ドメイン名を、名前・DNS・サービスの三層で管理する
ドメイン名はURLそのものでも、DNSそのものでも、サーバーそのものでもありません。example.comのような名前を契約に基づいて登録・管理し、DNSでWebやメールに必要な対応情報を公開し、接続先でサービスを提供します。取得時は登録資格と権利、公開時は委任・レコード・TLS、運用時は期限・権限・変更・移管・廃止を確認します。障害時に各層を分けて観測できる管理表と手順を残すことが、名前を継続して安全に使う基礎です。
執筆・事実確認
Finite Field 編集部
サーバー、Webアプリケーション、DNS、公開運用を扱う編集部が、IETF標準、IANA、ICANN、JPRSの一次資料を基準に、用語の境界と実務上の責任分界を確認しました。
ドメイン・DNS・公開構成の相談
移管やDNS変更を含む公開設計を整理します
Web、メール、複数環境、CDN、TLS、外部サービスが絡むドメイン移行では、レジストラ、権威DNS、接続先、TTL、証明書、監視、切り戻しを一つの手順へ整理します。現状調査から安全な変更計画まで相談できます。
個別開発を相談相談内容を確認したうえで対応可否と進め方をご案内します。特定レジストラやTLDの登録可否・規約判断は、各管理組織・契約事業者の最新情報をご確認ください。