FQDNって結局なんなんだよ【名前の構造を厳しく解説】

はじめに

FQDN（Fully Qualified Domain Name）、名前だけ聞くと難しそうですが、やっていることは単純です。

FQDNとは「どこまで省略せずに書いたか」という"名前の完全性"の話です。

「example.com」「www.example.com」「mail.example.com」——これらはすべてドメイン名ですが、FQDNかどうかは"書き方"で決まります。

この記事では、以下を厳しく・実務的に解説します:

• FQDNの正確な定義
• なぜ最後に「.（ドット）」が付くのか
• ホスト名／ドメイン名との違い
• DNS・設定・実務で何が変わるのか

記事の内容はRFC（Request for Comments）をベースにしています。

FQDNの定義（曖昧にしない）

FQDN（Fully Qualified Domain Name）とは:

DNSのルート（.）まで含めて、完全に修飾されたドメイン名

FQDNとは「DNSが誤解しない唯一の名前表記」です。 「完全性」とは、人間向けではなく機械向けに曖昧さがゼロであるという意味です。

RFC的に言えば:

• 省略なし
• 解釈の余地なし
• ルートまで明示されている

これが「Fully Qualified（完全に修飾された）」の意味です。

FQDNの定義は RFC 1034 / RFC 1035 に基づいています。

これはFQDNではない

次の名前は、見た目がそれっぽくてもFQDNではありません。

• example.com
• www.example.com
• mail.google.com

理由は単純です。

末尾のルート（.）が書かれていないからです。

これらは多くの環境で「自動的にFQDNとして扱われる」ため、普段は意識しなくても動作します。しかし、DNS仕様上は明確に区別されます。

FQDNの話になると「そんな細かいこと気にする？」と言われがちですが、
DNSの事故ログは、だいたいその「細かいこと」で埋まっています。

DNSは都合よく解釈してくれません。
人間の意図ではなく、設定された文字列だけを見ています。

FQDNの構造

FQDNはラベルの集合です。

www.example.com.

これを分解すると:

部分	役割
www	ホスト名（ラベル）
example	セカンドレベルドメイン
com	トップレベルドメイン（TLD）
.	ルートドメイン

階層構造の可視化

この図は、FQDNが必ずルート（.）から辿れる名前であることを可視化しています。

この階層は「上から下に辿れる」のではなく、必ずルート（.）から始まります。

重要ポイント

• 最後のドット . はルートを表す
• DNS上ではすべての名前は必ずルートにぶら下がる
• 人間向け表記では省略されがちだが、DNS内部では省略されない

FQDNと「ドメイン名」「ホスト名」の違い

混同されがちなので、ここは切り分けます。

用語	意味	例
ホスト名	1ラベル（最左端）	www
ドメイン名	階層構造を持つ名前	example.com
FQDN	ルートまで含めた完全な名前	www.example.com.

FQDNは新しい名前の種類ではありません。

同じ名前でも「省略されているか」「されていないか」でFQDNになったり、ならなかったりします。

• www.example.com ← ドットなし（厳密にはFQDNではない）
• www.example.com. ← ドットあり（FQDN）

※ 多くの実装では「暗黙的にルートが補完される」ため、実用上はFQDNとして扱われますが、DNS仕様上は「絶対名（ドット付き）」と区別されます。

なぜ最後のドットを省略しても動くのか

多くの人が疑問に思うポイントです。

理由

• DNSリゾルバやアプリケーションが自動で補完している
• www.example.com は内部的に www.example.com. と解釈される

しかし注意点

すべての文脈で自動補完されるわけではありません。

特に、DNSゾーンファイルや設定ファイルでは、ドットの有無が致命的な違いを生みます。

絶対名と相対名

DNSでは名前は2種類に分かれます。

種類	例	説明
絶対名	www.example.com.	FQDN。どこから見ても同じ
相対名	www	どのゾーンに属するか文脈依存

ゾーンファイルでの挙動

$ORIGIN example.com.
www     A   203.0.113.10

これは内部的に以下として扱われます:

www.example.com.   A   203.0.113.10

相対名 www に $ORIGIN の値が自動で付加されるため、www.example.com. になります。

絶対名を使う場合

$ORIGIN example.com.
www.example.com.     A   203.0.113.10
api.example.net.     A   203.0.113.20

最後にドットがあれば、$ORIGIN は付加されません。

相対名の危険性: Search Domain

OSや環境によっては、相対名にsearch domainが自動付加されることがあります。

例えば、/etc/resolv.conf に以下の設定がある場合:

search example.local

www という相対名を問い合わせると、以下のように解釈される可能性があります:

www.example.local

その結果、意図しない名前が問い合わせられ、名前解決に失敗することがあります。

これが、DNS設定では絶対名（FQDN）を使うべき理由の一つです。

FQDNを間違えると起きる事故

実務でよくある失敗例を紹介します。

1. CNAMEの向き先ミス

間違った設定:

www.example.com.   CNAME   api

これは以下を指します:

api.example.com.

もし api.example.net を指したかったなら、これは意図と違う結果になります。

正しい設定:

www.example.com.   CNAME   api.example.net.

末尾のドットを付けることで、絶対名として解釈され、意図通りに動作します。

2. MXレコードでメールが届かない

間違った設定:

example.com.   MX   10 mail

これは以下を指します:

mail.example.com.

もし外部メールサービス（例: mail.emailprovider.com）を使っている場合、この設定ではメールが届きません。

正しい設定:

example.com.   MX   10 mail.emailprovider.com.

外部サービスを指す場合はFQDN必須です。

3. SRVレコードでの指定ミス

間違った設定:

_minecraft._tcp.example.com.   SRV   0 5 25565 mc

これは mc.example.com. を指します。

正しい設定:

_minecraft._tcp.example.com.   SRV   0 5 25565 mc.gameserver.net.

4. DNS管理画面での「勝手な補完」

DNS管理画面（CloudflareやRoute53など）によっては:

• mail と入力 → 自動で mail.example.com に補完
• mail. と入力 → そのままFQDN扱い

UI依存の挙動が事故を生みます。

設定前に必ず:

• プレビュー機能で確認
• 保存後に dig コマンドで検証

digで見るFQDNの正体

実際にDNS問い合わせをしてみましょう。

dig www.example.com

返ってくる回答:

;; ANSWER SECTION:
www.example.com.  3600  IN  A  93.184.216.34

必ずドット付きで返ります。

※ digは人間向けの省略を一切せず、DNS内部表現（FQDN）をそのまま表示します。 これが、DNSの世界での標準形です。

人間向けとDNS内部の違い

ブラウザやアプリケーションが自動でFQDNに変換してくれるため、普段は意識しなくても動作します。

digは嘘をつきません。
嘘をついているのは、大抵人間側の設定です。

FQDNが重要になる場面

特に重要な場面を挙げます。

絶対に気をつけるべき場面

1. DNSゾーンファイル編集

   • 相対名と絶対名の区別が必須

2. CNAME / MX / SRV のターゲット

   • 外部サービスを指す場合はFQDN必須

3. TLS/SSL証明書（SAN）

   • Subject Alternative Name にはFQDNで記載

4. メール設定（SPF/DKIM/DMARC）

   • ドメイン指定は厳密に

5. Kubernetes / Service Discovery

   • 内部DNSでの名前解決

6. 内部DNS（Split-Horizon DNS）

   • 内部と外部で異なる応答を返す設定

よくある誤解

FQDNが理解されない原因の多くは、次の誤解にあります。

❌ FQDN = 長いドメイン名

違います。

• com. ← これもFQDN（1ラベル+ルート）
• www.example.com ← ドットなしなので厳密にはFQDNではない

長さは関係ありません。

❌ FQDN = サブドメイン

違います。

• example.com. ← FQDN（サブドメインではない）
• www.example.com. ← FQDN（サブドメイン）

FQDNかどうかと、サブドメインかどうかは別の概念です。

⭕ FQDN = 省略されていない名前

正解です。

FQDNは「完全に修飾された」名前であり、曖昧さがゼロの状態を指します。

実例: FQDNの使い分け

実際のDNS設定で、FQDNをどう使い分けるか見てみましょう。

ゾーンファイルの例

$ORIGIN example.com.
$TTL 3600

; 相対名（$ORIGINが付加される）
@           IN  A       203.0.113.10
www         IN  A       203.0.113.10
mail        IN  A       203.0.113.20

; 絶対名（そのまま使われる）
@           IN  MX  10  mail.example.com.
www         IN  CNAME   example.com.

; 外部サービスを指す（絶対名必須）
@           IN  MX  20  backup-mail.emailprovider.com.
cdn         IN  CNAME   cdn.cloudprovider.net.

ポイント:

• 同じゾーン内を指す場合 → 相対名でOK（シンプル）
• 外部を指す場合 → 絶対名（FQDN）必須
• 「@」はFQDNではありません。これは $ORIGIN を指す省略記号です。

チェックリスト: FQDN設定での確認事項

DNS設定時に確認すべき項目:

• CNAME/MX/SRVのターゲット: 外部サービスを指す場合、末尾にドットがあるか？
• ゾーンファイル: 相対名と絶対名を意図通りに使い分けているか？
• DNS管理画面: 入力した名前がどう補完されるか確認したか？
• 保存後の確認: dig コマンドで実際の設定を検証したか？
• 証明書のSAN: FQDNで正しく記載されているか？

確認方法

# Aレコードの確認
dig www.example.com A

# CNAMEレコードの確認
dig cdn.example.com CNAME

# MXレコードの確認
dig example.com MX

# すべてのレコードを確認
dig example.com

まとめ: FQDNの本質

FQDNとは:

• DNSにおける完全な名前
• ルートまで含めた曖昧さゼロの指定
• 機械が解釈するための正式表記

覚えておく鉄則

1. 最後のドットは意味を持つ（ルートを表す）
2. FQDNは状態であって種類ではない（書き方の問題）
3. ゾーンファイルでは相対名が補完される（$ORIGINが付加）
4. 外部サービスを指すときはFQDN必須（ドット付き）
5. DNSは人に優しくない。優しいのはクライアント側の補完

補足: ゾーンファイルで使われる「@」はFQDNではありません。これは $ORIGIN を指すための省略記号です。

DNSレコード記事との関係

前回の記事「DNSレコードって結局なんなんだよ」と合わせると:

• DNSレコード → 何を返すか（A、CNAME、MXなど）
• FQDN → どの名前で聞くか（名前の指定方法）

この2つが揃って、DNSの理解が完成します。

---

DNSトラブルの多くは「名前の指定ミス」から始まります。

FQDNを意識することは、DNSを理解する第一歩であり、DNS事故を防ぐ最短ルートです。

DNSは厳密な仕様で動いています。FQDNを正しく理解することで、設定ミスや事故を大幅に減らせます。

DNSは「名前解決」の仕組みですが、実際に壊れる原因の大半は「名前の書き方」です。

設定を変える前には必ず確認し、保存後は検証する。 これがDNS運用の基本です。

この記事が、あなたのDNS運用の一助となれば幸いです。