FQDN とサブドメイン・ホスト名の違い｜ネイキッドドメインの注意点

はじめに

DNS の設定や TLS 証明書の申請では、「FQDN」「サブドメイン」「ホスト名」「ドメイン名」といった用語が頻繁に登場します。これらは名前を部分ごとに切り分けて呼ぶ用語だと理解されがちですが、実際には同じ名前を異なる観点で説明していることが多く、用語同士は排他的ではありません。

この関係を整理しておくと、DNS 管理画面の入力欄、証明書に含める名前、www を付けないネイキッドドメインの設計で判断を誤りにくくなります。本記事では、具体的な名前を例に各用語の範囲を整理し、実務で確認すべき点を一次情報に基づいて解説します。

FQDN は名前を省略せずに表しているか、サブドメインは親ドメインとの階層関係、ホスト名は機器やサービスを指す名前としての呼び方を表す用語です。そのため、www.abcdef.example.com は example.com のサブドメインであり、FQDN でもあり、文脈によってはホスト名とも呼ばれます。ネイキッドドメインで Web サイトを公開する場合は、Zone Apex に通常の CNAME を置けないことを前提に、DNS サービスの機能と正規 URL の設計を決めます。

FQDN・サブドメイン・ホスト名の違いを具体例で整理

架空の名前 www.abcdef.example.com を例に、各用語がどの範囲を指すかを整理します。ここでは、example.com をレジストラ経由で登録したドメイン名とします。

abcdef は 1 つのラベルであり、それだけでは名前として完結しません。abcdef.example.com が example.com のサブドメインであり、さらに 1 階層下の www.abcdef.example.com も example.com のサブドメインです。

FQDN とサブドメインは同じ名前を別の観点で見た呼び方

DNS の用語を整理した RFC 9499 では、ドメイン名を「1 つ以上のラベルの順序付きリスト」と定義しています。つまり、DNS における「ドメイン名」は登録ドメインだけを指す用語ではなく、www.abcdef.example.com も com もドメイン名です。

サブドメインは、ある名前が別の名前の配下に含まれるかという関係を表します。判定はラベル単位で行うため、ooo.example.com は oo.example.com のサブドメインではありません。

参考: RFC 9499 – DNS Terminology（Section 2）
“both “mmm.example.com” and “nnn.mmm.example.com” are subdomains of “example.com””
（”mmm.example.com” と “nnn.mmm.example.com” は、どちらも “example.com” のサブドメインです）
https://www.rfc-editor.org/rfc/rfc9499.html#section-2

一方、FQDN は名前をルートまで省略せずに表しているかという観点の用語です。www などの追加ラベルは要件ではなく、example.com 自体も、完全な名前として示されていれば FQDN に該当します。RFC 9499 は、厳密には末尾にルートを表すドットを付けて表記するものの、末尾ドットを省いた表記も一般に FQDN と呼ばれると説明しています。

サブドメインとホスト名の違い

サブドメインが名前同士の階層関係を表すのに対し、ホスト名は機器やサービスを指す名前として使うときの呼び方です。RFC 9499 によると、ホスト名は DNS の基本仕様（RFC 1034 / RFC 1035 など）では定義されておらず、使われ方が変化してきた用語です。同 RFC では、主に次の使われ方が紹介されています。

• printer.admin.example.com の printer のように、左端のラベルだけをホスト名と呼ぶ場合
• 各ラベルが英字・数字・ハイフンで構成された完全な名前をホスト名と呼ぶ場合
• 機器を指す名前全般をホスト名と呼ぶ場合

このため、「ホスト名は左端のラベルだけ」と覚えていると、完全な名前の入力を求めるツールや資料と食い違います。設定画面や資料では、短い名前と完全な名前のどちらを求めているかを確認することをおすすめします。

また、DNS の名前と物理サーバーは一対一とは限りません。ロードバランサーや CDN の配下では 1 つの名前が複数のサーバーに対応し、1 台のサーバーが複数の名前で Web サイトを提供することもあります。www は Web サイトに慣例的に使われるラベルであり、特定のサーバー個体の名前とは限りません。

URL と FQDN の違い

FQDN は URL の一部であり、URL 全体ではありません。https://www.abcdef.example.com:8443/docs/index.html の場合、FQDN に該当するのは www.abcdef.example.com だけです。スキームの https://、ポート番号の :8443、パスの /docs/index.html は FQDN に含まれません。

補足: 登録ドメイン名を管理する仕組み

登録ドメイン名は、ゾーンへの登録を管理するレジストリ、登録者とレジストリの間を取り次ぐレジストラ、名前を登録する登録者という役割分担で管理されています。ルートゾーンの運用方針は、ICANN に集まるコミュニティーで決められています。どこまでを登録の単位とするかは TLD のポリシーによって異なり、co.jp のように 2 階層目の下で登録を受け付ける例もあります。

DNS 設定で入力する名前と末尾ドットの注意点

DNS のレコードを登録するときは、入力欄が相対名と完全な名前のどちらを求めているかを最初に確認します。同じ文字列でも、入力欄の仕様によって登録される名前が変わるためです。

「名前 / ホスト名」欄の扱いはサービスごとに異なる

DNS 管理画面の「名前」「ホスト名」「Name」といった欄は、サービスによって受け付ける形式が異なります。代表的な形式は次のとおりです。

相対名（www など）

ゾーン名（例: example.com）を補い、www.example.com として登録する形式です。

FQDN（www.example.com など）

完全な名前を入力する形式です。相対名を前提とする欄かどうかを確認してから入力します。

@

ゾーンの頂点（この例では example.com）を表す記号として使う形式です。Cloudflare の公式資料では、Zone Apex のレコードを Name が @ のレコードとして説明しています。

空欄

名前欄を空欄にして、ゾーンの頂点のレコードを登録する形式です。

ある画面で www と入力した方法が、別のサービスでも同じ意味になるとは限りません。各サービスのマニュアルや、保存前の画面に表示される完全な名前を確認してから登録することをおすすめします。

末尾ドットの意味: プレゼンテーション形式と通常表示

RFC 9499 は、DNS の名前の形式を次の 3 つに分けています。末尾ドットの有無は、どの形式で書いているかによって意味が変わります。

ブラウザーのアドレスバーや文章で末尾ドットを付けなくても、その名前が FQDN でなくなるわけではありません。末尾ドットが意味を持つのは、主にゾーンファイルのように相対名と絶対名を区別する書式です。

ゾーンファイルで相対名と絶対名の意味が変わる例

BIND などで使うゾーンファイル（マスターファイル）では、末尾ドットのない名前は相対名として扱われ、$ORIGIN で指定した名前が後ろに補われます。RFC 9499 でも、$ORIGIN が example.org. のとき、www は www.example.org. を表すと説明されています。次の 3 行は、同じ意図で書いた記述の違いを比較するための例です。

$ORIGIN example.com.
@    3600  IN  MX  10  mail                ; mail.example.com. として扱われる
@    3600  IN  MX  10  mail.example.com    ; mail.example.com.example.com. として扱われる
@    3600  IN  MX  10  mail.example.com.   ; mail.example.com. として扱われる

@ は $ORIGIN の名前（この例では example.com.）を表します。2 行目は、末尾ドットを付け忘れたために意図しない名前が登録される例です。ゾーンファイルを直接編集する場合は、完全な名前の末尾にドットを付けることが、この誤りの防止につながります。ただし、DNS サービスの管理画面や API では末尾ドットの扱いが異なる場合があるため、ゾーンファイルと同じ挙動を前提にしないでください。

名前の長さと使える文字

長さの上限は、どの形式で数えるかによって表現が変わります。RFC 9499 では、ラベル 1 つは 63 オクテット以下、名前全体はワイヤー形式で 255 オクテット以下と定義されています。ワイヤー形式では各ラベルの前に長さを表す 1 オクテットが付き、ルートも 1 オクテットとして数えるため、ASCII だけの名前を末尾ドットなしで表示した場合の上限は 253 文字になります。

使える文字も、DNS の名前全般とホスト名で区別が必要です。DNS のラベル自体は任意のオクテットを含められ、_dmarc.example.com のようにアンダースコアで始まるラベルも使われています。一方、ホスト名として扱う名前は、各ラベルを英字・数字・ハイフンで構成する構文（RFC 1034 の preferred name syntax に、数字で始まるラベルを認める RFC 1123 の変更を加えたもの）に従うのが一般的です。日本語などを含む国際化ドメイン名は、DNS 上では xn-- で始まる A ラベルに変換して扱われます。

Resolve-DnsName で入力した名前と応答を確認する

登録した名前が意図どおりかは、Windows PowerShell の Resolve-DnsName で確認できます。-Name に確認したい名前、-Type にレコードタイプを指定します。-Type を省略した場合は、A と AAAA の両方が問い合わせられます。次のコマンドの名前は説明用の例です。自身が登録した実在する名前へ置き換えて実行してください。

Resolve-DnsName -Name www.abcdef.example.com -Type A
Resolve-DnsName -Name example.com -Type MX

確認は次の順序で行います。

1. DNS 管理画面やゾーンファイルで、保存された完全な名前を確認します。意図した名前を問い合わせても、誤って登録された別の名前は応答に表示されないため、この確認を先に行います。
2. 確認した名前を Resolve-DnsName で問い合わせ、応答の Name・Type・値（IP アドレスや参照先の名前）が意図どおりかを確認します。
3. CNAME が介在する場合は、CNAME レコードと参照先の A レコードなどが続けて返されます。そのため、すべての行の Type が問い合わせたタイプと一致するとは限りません。

-Server パラメーターを使うと、問い合わせ先の DNS サーバーを指定できます。登録直後の確認では、権威サーバーへ直接問い合わせると、キャッシュの影響を切り分けやすくなります。ほかのレコードタイプの意味や nslookup・dig での確認方法は、関連記事『DNS レコードの種類と役割｜A と CNAME の違いと使い分けの早見表』で解説しています。

DNS の名前の設計から権威サーバーの設定、動作確認まで体系的に学びたい方には、『DNSがよくわかる教科書 第2版』が参考になります。ドメイン名の設計や DNS の設定・運用を扱う関連書籍です。
（広告）Kindle 版（Amazon） / 単行本（Amazon）

ネイキッドドメインと Zone Apex の関係

ネイキッドドメインと Zone Apex は同じ意味で使われることがありますが、着目している観点が異なります。

ネイキッドドメイン

登録ドメイン名を、www などのラベルを付けずに Web サイトで使う場合の呼び方です。https://example.com/ のような URL が該当します。DNS の仕様で定義された用語ではなく、Apex ドメインなどと呼ばれることもあります。「ルートドメイン」という呼び方は DNS のルート（.）と紛らわしいため、本記事では使いません。

Zone Apex

Zone Apex は SOA レコードと権威を持つ NS レコードが置かれる名前です。ゾーンファイルの $ORIGIN は相対名を補完する基準であり、必ず Zone Apex と一致するとは限りません（RFC 9499 Section 7）

委任されたサブドメインも、そのゾーンの Zone Apex になります。たとえば abcdef.example.com を別のゾーンとして委任した場合、abcdef.example.com は委任先ゾーンの Zone Apex です。Route 53 のドキュメントでも、Apex に CNAME レコードを作成できない制約は、example.com のようなドメイン名のホストゾーンにも、サブドメインのホストゾーンにも当てはまると説明されています。

ネイキッドドメインは URL の見た目に着目した呼び方、Zone Apex は DNS ゾーンの構造に着目した用語です。CNAME の制約を判断するときは、その名前が Zone Apex かどうかを確認します。

Zone Apex で CNAME を使えない理由と対応方法

クラウドサービスや CDN では、接続先を CNAME で指定するよう案内されることがあります。しかし、Zone Apex には通常の CNAME を置けないため、DNS サービスが提供する機能や接続先サービスの仕様に合わせた方法を選びます。

CNAME は同じ名前の他のレコードと共存できない

CNAME レコードは、その名前が別名であり、正規名は別にあることを示すレコードです。RFC 1034 は、CNAME がある名前にはほかのデータを置かないと定めています。RFC 2181 Section 10.1 も、DNSSEC 関連のレコードを除き、別名にはほかのデータを持たせられないと明確化しています。

参考: RFC 1034 – Domain Names – Concepts and Facilities（Section 3.6.2）
“If a CNAME RR is present at a node, no other data should be present”
（あるノードに CNAME レコードが存在する場合、ほかのデータは存在すべきではありません）
https://www.rfc-editor.org/rfc/rfc1034#section-3.6.2

Zone Apex には SOA レコードと NS レコードが必要なため、同じ名前に通常の CNAME を置くと、この共存制約に反します。MX や TXT を登録しているかどうかにかかわらず、Apex に通常の CNAME を置けない理由はここにあります。

Apex に CNAME を設定しようとした場合

DNS サービスによっては、この制約に反する設定を受け付けません。たとえば Route 53 は、ホストゾーンと同じ名前の CNAME レコードは作成できないと明記しています。ゾーンファイルを直接編集する環境では、次のような記述は不正なゾーンとして扱われ、検査や読み込みでエラーになる可能性があります。

; 不正な例: Zone Apex に SOA / NS と CNAME が同居している
$ORIGIN example.com.
@    3600  IN  SOA    ns1.example.net. hostmaster.example.com. ( 2026100101 7200 3600 1209600 3600 )
@    3600  IN  NS     ns1.example.net.
@    3600  IN  NS     ns2.example.net.
@    3600  IN  MX     10 mail.example.com.
@    3600  IN  CNAME  lb.provider.example.

このような設定を試みた場合の結果は、DNS サービスや DNS サーバーソフトウェアの実装によって異なります。特定の症状を前提にするのではなく、Apex に通常の CNAME を置かない設計にすることをおすすめします。

Apex を外部サービスへ向ける方法の選び方

Apex をクラウドサービスや CDN へ向ける方法は、利用する DNS サービスと接続先サービスが提供する機能で決まります。各社の機能は名前が似ていても、対象や応答の形式が異なります。

Route 53 の Alias レコードは、Route 53 が AWS リソースの IP アドレスの変化を検知して応答する機能です。Cloudflare の CNAME Flattening は、Cloudflare が CNAME の参照先をたどって解決し、CNAME の代わりに IP アドレスを返す機能です。返る IP アドレスはプロキシの状態で異なり、DNS-only のレコードでは参照先の最終的な IP アドレス、Proxied のレコードでは通常 Cloudflare の Anycast IP アドレスになります。Proxied で設定した直後の DNS 応答が参照先の IP アドレスと異なっていても、それだけで異常とは判断できません。管理画面上は CNAME に似た設定でも、実装と応答の形式は同じではありません。DNS サービスを移行するときは、移行先で同等の機能が使えるかを事前に確認します。

参考: Amazon Route 53 Developer Guide – Choosing between alias and non-alias records
“An alias record can only redirect queries to selected AWS resources”
（Alias レコードがクエリを向けられるのは、対象として選ばれた AWS リソースに限られます）
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html

参考: Cloudflare DNS docs – CNAME flattening
“Cloudflare then returns the final IP address instead of a CNAME record”
（その後、Cloudflare は CNAME レコードの代わりに最終的な IP アドレスを返します）
https://developers.cloudflare.com/dns/cname-flattening/

www の有無で確認する証明書・Cookie・リダイレクト

www ありと www なしのどちらを正規 URL にするかは、URL の見た目だけでなく、DNS、証明書、Cookie、リダイレクトの設計を合わせて判断します。www の有無そのものが検索順位を左右するという根拠は確認できないため、本記事では SEO 上の優劣ではなく、正規 URL を 1 つに統一する運用を重視します。判断材料は次のとおりです。

DNS

Apex を接続先サービスへ向ける機能（Alias や CNAME Flattening など）が使えるか。使えない場合は、www を正規ホストにする構成のほうが扱いやすくなります。

証明書

正規ホストとリダイレクト元の両方の名前を、証明書に含められるか。

Cookie

アプリケーションや CDN が発行する Cookie の Domain 属性を、どの範囲のホストへ送る設計にするか。

既存の URL

公開済みのサイトでは、現在の正規 URL を変更する必要があるか。

証明書は SAN に含まれる名前で判断する

TLS 証明書で接続を検証できる名前は、証明書の SAN（subjectAltName）に含まれる DNS 名で判断します。RFC 9525 では、ワイルドカード * は左端のラベル全体としてのみ使え、1 つのラベルにだけ一致すると定めています。

*.example.com だけでは、Apex の example.com は対象になりません。Apex でも HTTPS の接続を受ける場合は、example.com が別の SAN として含まれているかを、証明書の詳細で確認します。

参考: RFC 9525 – Service Identity in TLS（Section 6.3）
“A wildcard in a presented identifier can only match one label”
（提示された識別子のワイルドカードは、1 つのラベルにのみ一致します）
https://www.rfc-editor.org/rfc/rfc9525.html#section-6.3

証明書の種類による違いは、関連記事『SSL 証明書 DV・OV・EV の違いと選び方｜2026 年の 47 日化まで解説』で解説しています。

CNAME と HTTP リダイレクトは役割が異なる

CNAME は DNS で名前の別名を定義するレコードであり、CNAME だけではブラウザーのアドレスバーに表示される URL は切り替わりません。www.example.com を CNAME で CDN の名前へ向けても、ブラウザーは www.example.com に接続しているものとして通信します。表示する URL を切り替えたい場合は、Web サーバーや CDN で HTTP リダイレクトを設定します。

証明書の照合も、CNAME の参照先ではなく、利用者がアクセスした名前で行われます。RFC 9525 は、DNS の名前解決の途中で現れる名前を、照合に使う参照識別子として扱ってはならないと定めています。

HTTPS のリダイレクト元にも、その名前に対応する証明書が必要です。https://example.com/ から https://www.example.com/ へリダイレクトする場合、ブラウザーはリダイレクトの応答を受け取る前に、example.com との TLS 接続を確立するためです。

Cookie の送信範囲は Domain 属性で決まる

Cookie がどのホストへ送られるかは、www の有無ではなく、Set-Cookie ヘッダーの Domain 属性で決まります。RFC 6265 の動作を整理すると次のとおりです。

参考: RFC 6265 – HTTP State Management Mechanism（Section 4.1.2.3）
“the user agent will return the cookie only to the origin server”
（［Domain 属性を省略した場合］ユーザーエージェントは、Cookie をオリジンサーバーにのみ返します）
https://www.rfc-editor.org/rfc/rfc6265.html#section-4.1.2.3

ネイキッドドメインで設定した Cookie でも、Domain 属性を省略すればサブドメインへは送られません。反対に、www を正規ホストにしても、アプリケーションが Domain=example.com を指定すればサブドメイン全体へ送られます。なお、RFC 6265 には、Domain 属性のない Cookie をサブドメインへ送ってしまう既存の実装があったという注意書きもあります。www の有無を選ぶ前に、発行される Cookie の Domain 属性を確認することをおすすめします。

正規 URL を 1 つに決めて統一する

Google 検索セントラルは、重複する URL を正規化する方法として、リダイレクト、rel="canonical"、サイトマップを挙げ、リダイレクトを強いシグナルと位置付けています。www ありとなしのどちらを選ぶ場合も、次の順で統一することをおすすめします。

参考: Google 検索セントラル – How to specify a canonical URL with rel=”canonical” and other methods
“A strong signal that the target of the redirect should become canonical”
（［リダイレクトは］リダイレクト先を正規 URL にすべきことを示す強いシグナルです）
https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

まとめ

FQDN・サブドメイン・ホスト名は、同じ名前を異なる観点で説明する用語であり、互いに排他的ではありません。ネイキッドドメインを使う場合は、Zone Apex の CNAME 制約に加えて、証明書、Cookie、リダイレクトを正規 URL の設計としてまとめて確認することが重要です。

• FQDN は名前を省略せずに表したもので、example.com 自体も該当する。
• www.abcdef.example.com も example.com のサブドメインである。
• ホスト名は短い名前にも完全な名前にも使われ、文脈で範囲が変わる。
• DNS の名前欄が相対名と FQDN のどちらを求めるかはサービスで異なる。
• Zone Apex には SOA と NS が必要なため、通常の CNAME を置けない。
• Route 53 の Alias と Cloudflare の CNAME Flattening は対象と動作が異なる。
• 証明書の範囲は SAN で、Cookie の送信範囲は Domain 属性で判断する。

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