FQDN とサブドメイン・ホスト名の違いとネイキッドドメインの落とし穴

はじめに

Web サイトの構築や DNS の設定をしていると、「ホスト名」「ドメイン名」「FQDN」といった用語が頻繁に登場します。日常的に使われる用語ですが、厳密な定義や相互の関係を整理しておくと、DNS トラブル時の原因切り分けやクラウド環境の設計判断に役立ちます。

本記事では、これらの用語の違いを図解で整理し、近年採用が増えている「ネイキッドドメイン」の技術的制約と回避策についても解説します。

図解で整理: URL の構造と名称

架空の URL https://www.abcdef.mytech-blog.com を例に、それぞれの名称がどこを指しているのかを整理します。

以降、それぞれの用語を個別に解説します。

ドメイン名（Domain Name）

インターネット上の「住所」にあたります。本サイトであれば mytech-blog.com、Google であれば google.com が該当します。住所と同じく、世界中で重複しないように管理されています。

誰が管理しているのか（ICANN とレジストリ）

ドメインは、ICANN（アイキャン） を最上位とした階層構造で管理されています。

• ICANN: ドメイン全体を統括する国際的な非営利組織
• レジストリ: .com や .jp などのトップレベルドメイン（TLD）ごとの管理組織（例: .com は Verisign 社、.jp は JPRS）
• レジストラ: ユーザーとレジストリの間を取り次ぐ事業者（例: お名前.com、ムームードメインなど）

ユーザーがドメインを取得する際は、レジストラを通じて申し込む形になります。

サブドメイン名（Subdomain Name）

ドメイン名の前に追加して、用途別に区切ったものです。mytech-blog.com という住所の中に、以下のように「部屋」を作るイメージです。

• blog.mytech-blog.com（ブログ用）
• shop.mytech-blog.com（ショップ用）

1 つのドメインで複数のサイトを運用できるため、サービス単位や用途単位での分離に広く使われます。

SSL 証明書との関係

通常の SSL 証明書（シングルドメイン証明書）は FQDN 単位で発行されるため、サブドメインが増えるたびに別の証明書が必要になります。ただし、近年は選択肢が広がっており、以下のような方法で複数サブドメインを効率的にカバーできます。

Let’s Encrypt のような無料 SSL 証明書サービスでは、ワイルドカード証明書も無料で取得可能になっており、サブドメイン追加によるコスト負担は以前に比べて大幅に軽減されています。

補足: ワイルドカード証明書の制約
ワイルドカード証明書（*.example.com）は 1 レベル下のサブドメインのみをカバーします。api.example.com はカバーされますが、v1.api.example.com のような 2 階層以上のサブドメインは対象外です。また、ワイルドカード証明書はドメイン本体（example.com）をカバーしないケースもあるため、発行時に SAN として本体を含めるかを確認することが推奨されます。

ホスト名（Host Name）

ネットワーク上の「コンピューター（サーバー）の名前」です。Web サーバーなら www、メールサーバーなら mail と命名するのが慣例です。後述する「ネイキッドドメイン」の議論では、この「ホスト名があるかないか」が重要な論点になります。

FQDN（Fully Qualified Domain Name）

「完全修飾ドメイン名」と訳され、ホスト名からトップレベルドメインまですべてのラベルを省略せずに繋げた文字列を指します。www.mytech-blog.com のように、省略せずに書かれた「フルネーム」のことです。

参考: JPRS 用語辞典 – FQDN
“Fully Qualified Domain Name（完全修飾ドメイン名）の略称。トップレベルドメイン（TLD）までのすべてのラベルを含むドメイン名のことをいいます。”
https://jprs.jp/glossary/index.php?ID=0021

厳密な定義: 末尾のドットと絶対ドメイン名

DNS の仕様（RFC 1034）上、FQDN の厳密な表記は 末尾にドット（.）を付ける 形式です。この末尾のドットは DNS のルート（根）ノードを示しており、www.mytech-blog.com. のようにドット付きで表記されたものを絶対ドメイン名（Absolute Domain Name） と呼びます。

• www.mytech-blog.com（通常の FQDN 表記）
• www.mytech-blog.com.（末尾ドット付き・絶対ドメイン名）

DNS ゾーンファイルや BIND の設定では、この末尾ドットの有無で意味が変わる場面があるため、設計時は注意が必要です。

FQDN の長さと文字数制約

FQDN には RFC 仕様上の制約があります。

• ラベル（各ドットで区切られた部分）: 1〜63 文字
• FQDN 全体: 最大 253 文字
• 使用可能な文字: 英字（A〜Z、大文字小文字区別なし）、数字（0〜9）、ハイフン（-）
• ラベルの先頭と末尾: 英字または数字（ハイフンで始めたり終えたりすることはできない）

長い FQDN を設計する場合や、多階層のサブドメインを構築する場合は、これらの上限を意識することが推奨されます。

ネイキッドドメインとは？

定義と別名（Zone Apex）

ネイキッドドメイン（Naked Domain） とは、www などのホスト名が付かない、ドメイン名だけの状態を指します。専門用語では 「Zone Apex（ゾーンエイペックス）」 や 「Apex Domain」 と呼ばれます。

• 通常の URL: https://www.mytech-blog.com
• ネイキッド: https://mytech-blog.com

近年のトレンドとメリット

近年では、X（x.com）や Facebook（facebook.com）をはじめ、多くの主要サービスがネイキッドドメインで運用されています。本ブログもネイキッドドメインで運用しています。

• URL が短くシンプル: 覚えやすく、入力・共有しやすい
• ブランディング: サイト名と URL が一致することで、直感的に伝わりやすい
• モバイル対応: 画面の狭いスマートフォンでも URL が見切れにくい

ネイキッドドメインの注意点

採用が広がっているネイキッドドメインですが、DNS 設定において 「CNAME レコードが使えない」 という重要な技術的制約があります。

AWS（ELB / CloudFront）や Heroku、Netlify などのクラウドサービスでは「CNAME でドメインを向けてください」と案内されることが多いものの、ネイキッドドメインではそのままでは CNAME を設定できません。

技術的制約: CNAME レコードが使えない

DNS の基本仕様を定める RFC において、「CNAME レコードは他のいかなるレコードとも共存できない」 と定義されています。一方でゾーンの頂点（Zone Apex）には SOA レコードと NS レコードが必須であるため、ゾーン頂点に CNAME を置くこと自体が仕様上許されません。

参考: RFC 1912 – Common DNS Operational and Configuration Errors（Section 2.4）
“A CNAME record is not allowed to coexist with any other data.”
（CNAME レコードは、他のいかなるデータとも共存することは許可されていません）
https://www.ietf.org/rfc/rfc1912.txt

参考: 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; this ensures that the data for a canonical name and its aliases cannot be different.”
（ノードに CNAME レコードが存在する場合、他のデータは存在してはなりません。これにより、正規名とそのエイリアスのデータが異なることが防がれます）
https://www.rfc-editor.org/rfc/rfc1034

具体的なトラブル: メール（MX）が届かなくなる

ネイキッドドメイン（mytech-blog.com）に対して無理に CNAME を設定しようとすると、以下のようなトラブルが発生します。

mytech-blog.com.   CNAME   xxx.elb.amazon.com.   <-- これを設定すると...
mytech-blog.com.   MX      mail.conoha.ne.jp.    <-- こちらが無視される
mytech-blog.com.   NS      ns-a1.conoha.io.      <-- こちらも無視される

CNAME は「別名（エイリアス）」を示すレコードで、CNAME が設定されたノードに対する問い合わせは、すべて参照先（この例では xxx.elb.amazon.com）の情報で解決されます。結果として、本来の MX レコードや NS レコードは参照されず、本来のメールサーバー（ConoHa など）にメールが届かなくなるという問題が発生します。

「Web サイトを表示させたい」意図で CNAME を設定した結果、「Web は閲覧できるようになったがメールが受信できなくなった」というトラブルは、ネイキッドドメイン運用で頻繁に発生する典型例です。

解決策: Alias 機能や CNAME Flattening の活用

ネイキッドドメインで CNAME 相当の動作を実現するには、以下 2 つの方向性があります。

方法 1: A レコードを使う（IP アドレス指定）

Web サーバーの IP アドレスが固定（不変）である場合は、CNAME ではなく A レコードを使えば問題ありません。A レコードは他のレコード（MX・NS など）と共存できます。

mytech-blog.com.   A    100.64.1.1        <-- IP アドレス指定なら OK
mytech-blog.com.   MX   mail.example.jp.  <-- メールも届く

ただし、AWS ELB や CloudFront など、IP アドレスが動的に変わるクラウドサービスを利用する場合、この方法は使えません。

方法 2: DNS ホスティングの Alias 機能を使う

各 DNS サービスは「CNAME は Zone Apex で使えない」という制約を回避するため、Alias / ANAME / CNAME Flattening といった独自機能を提供しています。いずれも「管理画面上は CNAME のようにドメイン名を指定できるが、実際の応答では A レコード（IP アドレス）を返す」という仕組みです。

参考: Cloudflare DNS Documentation – CNAME flattening
“CNAME flattening speeds up CNAME resolution and allows you to use a CNAME record at your zone apex (example.com).”
（CNAME Flattening は CNAME の解決を高速化し、ゾーン頂点（example.com）での CNAME レコード使用を可能にします）
https://developers.cloudflare.com/dns/cname-flattening/

Alias 系機能を使う際の注意点

• RFC 非標準のプロバイダー固有機能である点に注意が必要です。DNS の国際標準には含まれないため、DNS サービスを移行する際には移行先が同等の機能を備えているかを事前に確認することが推奨されます
• 仕組み上、DNS サーバー側で再帰的な名前解決を行って A/AAAA に変換するため、通常の A レコードと比較して初回応答のレイテンシが増える場合があります（多くの実装ではキャッシュで緩和）

A レコードや CNAME レコードの基本的な仕組み、Alias レコードの詳細については、関連記事『DNS の代表的なレコードの種類（A・CNAME・MX など）と役割の違い』で図解付きで解説しています。

ネイキッドドメインと www ありドメインの比較

「ネイキッドドメイン（example.com）」と「www ありドメイン（www.example.com）」のどちらを採用すべきかは、設計時によく議論される選択です。それぞれの特性を整理します。

比較表

参考: Nexcess – Is There Any Reason To Use WWW In Your Domain?
“If a site uses cookies, cookies set for the naked domain will be sent to all subdomains, which isn’t usually what site owners want.”
（ネイキッドドメインに設定したクッキーは、すべてのサブドメインに送信されます。これは通常、サイト管理者が意図する動作ではありません）
https://www.nexcess.net/blog/is-there-any-reason-to-use-www-in-your-domain/

どちらを選ぶべきか

SEO の観点では、どちらを選んでも差はありません。 Google をはじめとする主要検索エンジンは、www の有無で順位に差をつけないことを明言しています。どちらかに統一し、もう一方からリダイレクト（301）を設定することが重要です。

選定の判断基準としては、以下を参考にしてください。

クラウドサービス（ELB / CloudFront / Netlify / Heroku 等）を利用する場合

www ありドメインのほうが CNAME が直接使えて設定が簡単。ネイキッドドメインを採用する場合は Alias 機能対応の DNS サービスが必要

スタティックコンテンツを別サブドメインで配信する場合

クッキーの漏れを防ぐため www ありが有利

URL の短さ・ブランドシンプルさを優先する場合

ネイキッドドメインを選択し、Alias 機能対応の DNS サービスと組み合わせる

まとめ

本記事では、混同されやすいドメイン周辺の用語と、ネイキッドドメインの技術的制約・回避策について解説しました。

• FQDN はホスト名からトップレベルドメインまでを省略せずに繋げた「絶対表記」で、厳密には末尾にドットを付けたものが絶対ドメイン名
• サブドメインはドメイン内の区分けで、SSL 証明書はワイルドカードや SAN の活用でコスト効率を改善可能
• ホスト名はサーバー単体の名前（www / mail など）で、ホスト名の有無が「ネイキッドドメイン」か否かを分ける
• ネイキッドドメインは URL がシンプルになる反面、RFC 仕様上 CNAME レコードが使えないという技術的制約がある
• ネイキッドドメインに CNAME を無理に設定すると、MX や NS が無視されてメールが届かなくなるトラブルにつながる
• 回避策としては「固定 IP での A レコード指定」または「各 DNS サービスが提供する Alias / CNAME Flattening 機能の利用」が選択肢となる

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