FQDNとは？ドメイン名・ホスト名との違いと書き方・確認方法を実装者向けに解説

FQDN（Fully Qualified Domain Name＝完全修飾ドメイン名）は、ホスト名とドメイン名をすべて省略せずにつなげ、インターネット上で機器やサービスを一意に指し示す完全な名前です。たとえば www.example.co.jp のように、どのドメインのどのホストかを最後まで書き切った形を指します。この記事では、FQDNとドメイン名・ホスト名・URL・IPアドレスの違い、厳密には末尾に付くルートのドットとPQDN（部分修飾ドメイン名）の区別、各ラベル63オクテット・全体255オクテットまでという構文ルール、FQDNをIPアドレスに変換するDNSの名前解決、そしてLinux／Windowsでの確認方法、SSL/TLS証明書やAWSでのFQDN設定まで、サーバーや基盤を構築する担当者の視点でまとめました。内部向けと外部向けでFQDNを分ける設計の判断基準も扱います。

まとめ：FQDNの意味と実装で押さえる要点

FQDNは、ホスト名（例：www）とドメイン名（例：example.co.jp）を連結し、末尾のトップレベルドメインまで省略せずに書いた「これ以上たどる先がない」完全な名前です。DNSの階層をルートから見ると、厳密には www.example.co.jp. のように末尾へルートを表すドットが付きますが、ブラウザや設定ファイルでは省略して書くのが通例です。ドメイン名が「組織の住所」、ホスト名が「その中の機器名」だとすると、FQDNは両者を合わせた「完全な宛名」にあたります。

実装で押さえる点は3つです。第一に、FQDNはDNSの名前解決でIPアドレスへ変換される起点であり、AレコードやCNAMEをたどって最終的なIPが決まること。第二に、構文にはラベルあたり63オクテット・全体255オクテットという上限があり、使える文字は英数字とハイフンに限られること。第三に、サーバーのホスト名設定・SSL証明書のSAN・クラウドのDNSレコードなど、実務でFQDNを正確に指定しないと通信や証明書検証が失敗すること。以降で、違いの整理から構文、名前解決、実際の設定・確認までを具体的に見ていきます。

FQDNの構成とドメイン名・ホスト名・URL・IPアドレスとの違い

FQDNを正しく扱う出発点は、似た用語との切り分けです。ドメイン名・ホスト名・URL・IPアドレスは、それぞれ指す範囲が違います。

ホスト名とドメイン名を連結した完全な名前としてのFQDNの定義

FQDNは、機器を指すホスト名と、組織を指すドメイン名を、区切りのドットでつないだ全体を指します。www.example.co.jp を例にすると、先頭の www がホスト名、後ろに続く example.co.jp がドメイン名です。ドメイン名はさらに、co.jp のようなトップレベル側から example という組織名へと、右から左へ階層をたどる構造になっています。

社内のネットワークでは、ホスト名の www や server01 だけで相手に届く場合があります。これはDNSサフィックス（例：example.co.jp）が自動で補われ、内部でFQDNに組み立て直されているためです。インターネット全体で一意に相手を特定するには、この補完に頼らず www.example.co.jp と最後まで書き切った形、つまりFQDNが必要になります。ホスト名が「部屋番号」なら、FQDNは「国名まで書いた完全な住所」に相当します。

末尾のルートドットとFQDN・PQDN（部分修飾ドメイン名）の区別

DNSの名前空間は、頂点にルートを置いた木構造です。ルートは名前を持たず「空のラベル」で表され、これを明示すると www.example.co.jp. のように末尾へドットが1つ付きます。この末尾のドットが付いた絶対表記が、厳密な意味でのFQDNです。日常のブラウザ入力や設定では末尾ドットを省くのが通例ですが、DNSゾーンファイルなどでは末尾ドットの有無で意味が変わります。

末尾までたどり切っていない中途半端な名前は、PQDN（Partially Qualified Domain Name＝部分修飾ドメイン名）と呼びます。www 単体や www.example のように、途中で止まった相対的な名前がPQDNの例です。PQDNは、DNSサフィックスが補われて初めてFQDNとして解決できます。設定ファイルにホスト名を書くときは、サフィックス補完に依存するPQDNではなく、末尾まで確定したFQDNで書くほうが、環境が変わっても解決先がぶれません。

FQDN・ドメイン名・ホスト名・URL・IPアドレスの対応と違いの整理

用語が指す範囲を、同じ例で並べると違いが見えます。https://www.example.co.jp/products/ というURLを分解して対応させると、次のようになります。

URLはFQDNを内側に含み、その前後にスキーム（https）やパス（/products/）を伴った、より広い表記です。FQDNはURLから通信先のホストだけを取り出した部分にあたります。そしてFQDNは人間が読むための名前、IPアドレスは機器が通信に使う数値の宛先であり、両者をつなぐのが次章のDNSです。

FQDNの書き方とラベル・文字数・使える文字などの構文ルール

FQDNは自由に長い文字列を並べてよいわけではありません。RFCが定める構文の上限と、IPアドレスへ変換される仕組みを押さえます。

各ラベル63オクテット・全体255オクテットまでの長さ制限と使える文字

FQDNはドットで区切られた「ラベル」の連なりで、RFC 1035は1ラベルあたり最大63オクテット、名前全体で最大255オクテットと定めています。この255オクテットには各ラベルの長さを表すバイトや末尾ルートも含まれるため、実際に表示できる文字数はおおむね253文字が上限とされます。長いサブドメインを何段も重ねると、この上限に近づく点に留意してください。

使える文字は、英字・数字・ハイフンに限られます（いわゆるLDH規則）。ラベルの先頭と末尾にハイフンは置けず、アンダースコアは本来ホスト名としては許されません。日本語などの国際化ドメイン名（IDN）は、そのままでは解決できず、Punycodeという方式で xn-- で始まるASCII表記へ変換してからDNSへ渡されます。ブラウザは日本語ドメインを表示上そのまま見せますが、内部では変換後のFQDNで問い合わせが飛んでいます。

FQDNからIPアドレスを引くDNSの名前解決とAレコード・CNAMEの流れ

FQDNが実際の通信につながるのは、DNSがFQDNをIPアドレスへ変換するからです。ブラウザやOSは、まずキャッシュを確認し、無ければリゾルバへ問い合わせます。リゾルバはルートDNSサーバー、jp や co.jp を管理する上位サーバー、そして example.co.jp の権威DNSサーバーへと、右のラベルから順にたどって最終的な答えを得ます。

権威サーバーが返すレコードには種類があります。IPv4アドレスを直接返すのがAレコード、IPv6アドレスを返すのがAAAAレコード、別のFQDNへの転送を示すのがCNAME（別名）レコードです。たとえば www.example.co.jp をCNAMEで cdn.example.net へ向け、その先のAレコードで実IPを返す、という多段の解決も一般的です。こうして得られたIPアドレスが、どのネットワーク範囲に属するかを設計する話は、CIDRとは？表記の読み方からサブネット設計・AWS VPCでの使い方までで扱っています。名前（FQDN）側と、その解決先であるアドレス範囲側は、対で理解すると設計判断がつながります。

実務でFQDNを設定・確認する場面とサーバー・証明書・クラウドでの扱い

ここからは概念ではなく、サーバー構築や証明書、クラウドで実際にFQDNを設定・確認する場面に踏み込みます。指定のずれは、通信不達や証明書エラーとして表面化します。

LinuxのhostnameコマンドとWindowsでFQDNを確認・設定する方法

サーバー自身のFQDNは、コマンドで確認できます。Linuxでは hostname -f がFQDN、hostname が短いホスト名を返す仕組みです。systemd系では hostnamectl set-hostname server01.example.co.jp のようにFQDN形式で設定し、/etc/hosts と /etc/resolv.conf のサフィックス設定と食い違わないようそろえます。

Windowsでは、コマンドプロンプトで ipconfig を /all オプション付きで実行すると表示される「ホスト名」と「プライマリDNSサフィックス」を連結したものがFQDNにあたります。PowerShellなら [System.Net.Dns]::GetHostByName($env:COMPUTERNAME).HostName でFQDNを取得できます。ここで多いのが、ホスト名だけ設定してDNSサフィックスを空のままにし、FQDNが組み立たないミスです。メールサーバーやクラスタ構成では、FQDNが正しく引けないとホスト間の認証や証明書検証が失敗するため、設定後に必ず hostname -f 等で期待どおりのFQDNが返るか確認してください。

SSL/TLS証明書のコモンネーム・SANでFQDNを指定する際の注意

SSL/TLS証明書は、アクセスに使うFQDNと証明書に書かれた名前が一致して初めて有効です。かつては証明書のコモンネーム（CN）にFQDNを1つ書く方式でしたが、現在は多くのブラウザやツールがCNを参照せず、SAN（Subject Alternative Name）に列挙されたFQDNで一致を判定します。証明書を用意するときは、www.example.co.jp と example.co.jp のように、実際にアクセスされるFQDNをSANへ漏れなく含める必要があります。

複数のホストをまとめたい場合は、*.example.co.jp のようなワイルドカード証明書が使えます。ただしワイルドカードが受け持つのは1階層だけで、*.example.co.jp は www.example.co.jp には一致しますが、a.b.example.co.jp のように階層が深いFQDNや、example.co.jp そのものには一致しません。証明書エラーの多くは、アクセスしたFQDNがSANにもワイルドカードの範囲にも入っていないことが原因です。設計時に、対象となるFQDNを洗い出してからSANの構成を決めると取りこぼしを防げます。

AWSのRoute 53やロードバランサーでFQDNを扱うクラウド設計

クラウドでは、リソースにIPアドレスではなくFQDNが割り当てられる場面が中心です。AWSのApplication Load BalancerやCloudFrontは、固定IPではなく my-alb-123456.ap-northeast-1.elb.amazonaws.com のようなFQDNを払い出します。自社ドメインで見せるには、Route 53で www.example.co.jp をこのFQDNへ向けるエイリアス（またはCNAME）レコードを作成します。IPが変動するマネージドサービスを、FQDNを介して安定した名前で参照できるのがこの設計の要点です。

証明書もFQDN単位で管理します。AWS Certificate Manager（ACM）では、保護するFQDNを指定して証明書を発行し、DNS検証用のレコードをRoute 53へ登録して所有を証明します。ここでFQDNの綴りやサフィックスを1文字でも誤ると、検証が完了せず発行に至りません。こうしたRoute 53のレコード設計やACMの証明書運用、ロードバランサーの構成を含めてクラウド基盤を外部に相談したい場合は、AWSのインフラ構築で設計段階からの支援を受けられます。名前設計の巧拙が、後の証明書更新や移行のしやすさを左右します。

FQDN設計で失敗する典型パターンと命名・分離設計の判断基準

最後に、独自の視点として、現場で繰り返されるFQDNの設計ミスと、そこから導ける判断基準を言い切っておきます。命名はあとから変えるコストが高く、初期の設計がそのまま運用の質になります。

内部向けと外部向けでFQDNを分ける設計と命名時の見送り基準

典型的な失敗は2方向にあります。1つは、内部専用のサーバーに社外と同じFQDNをそのまま使い、内外でDNSの応答が食い違う「スプリットブレイン」状態を管理しきれなくなるパターンです。判断基準はこうです。外部公開しないシステムには、内部専用のゾーン（例：internal.example.co.jp や .internal）を切り、外部向けFQDNと名前空間ごと分ける。内部向けの名前は、その解決先を特定のサブネットに閉じておくと、経路や公開範囲の管理が単純になります。範囲の切り方はサブネットマスクとは？仕組みと計算方法・CIDR表記との違いを実装者向けに解説で整理しています。

もう1つは、ホスト名に用途を詰め込みすぎるパターンです。web01-prod-tokyo-nginx-v2 のように情報を全部ラベルへ入れると、役割変更のたびに名前と実体がずれ、リネームの手戻りが生じます。FQDNは変えにくい前提で、頻繁に変わる属性（バージョン、担当）は名前へ入れず、タグや構成管理側で持つのが無難です。迷ったときの原則は、FQDNには「変わらない役割」だけを載せ、可変の情報は外に出すこと。内部/外部の分離と、変わらない命名という2点を最初に決めておけば、後からの作り直しを避けられます。

よくある質問

FQDNの実務でよく検索される疑問を、設定判断に直結する形で回答します。

FQDNとドメイン名の違いは何ですか？

ドメイン名は example.co.jp のような組織の名前空間を指し、FQDNはそこにホスト名を足して www.example.co.jp と機器まで特定した完全な名前を指します。ドメイン名が「組織の住所」、FQDNが「その中の特定の機器までを書いた完全な宛名」という関係です。ドメイン名だけでは、その組織のどのサーバーを指すかまでは決まりません。

FQDNの末尾のドットは付けるべきですか？

厳密なFQDNはDNSのルートを表す末尾のドットを含みますが、ブラウザ入力や一般的な設定では省略して問題ありません。省略しても、OSやリゾルバがルートまで補って解決します。ただしDNSゾーンファイルでは、末尾ドットの有無で「絶対名」か「サフィックスが補われる相対名」かが変わるため、ゾーン定義を書くときだけは意識して付け分けてください。

FQDNはどうやって確認しますか？

Linuxでは hostname -f でそのサーバーのFQDNを確認できます。Windowsで確認する場合は ipconfig を /all 付きで実行し、表示される「ホスト名」と「プライマリDNSサフィックス」を連結した形がFQDNです。任意のFQDNが引けるIPを調べたいときは、nslookup や dig にFQDNを渡すと、対応するAレコードのIPアドレスを確認できます。

FQDNに使える文字と長さの制限はありますか？

使える文字は英字・数字・ハイフンで、ラベルの先頭と末尾にハイフンは置けません。長さはRFC 1035で1ラベル最大63オクテット、名前全体で最大255オクテットと定められ、表示上はおおむね253文字が上限です。日本語ドメインはPunycodeで xn-- 形式のASCIIへ変換されてからDNSへ問い合わせられます。

URLとFQDNはどう違いますか？

URLは https://www.example.co.jp/products/ のように、スキームやパスを含む資源の所在全体を表します。FQDNはそのうち通信先のホストを示す www.example.co.jp の部分だけを取り出したものです。URLはFQDNを内側に含み、FQDNに前後の情報を付け足した、より広い表記だと考えると整理できます。

関連記事

• CIDRとは？表記の読み方からサブネット設計・AWS VPCでの使い方まで：FQDNの解決先であるIPアドレスの範囲設計を扱います。名前側の本記事と対で読むと理解が深まります。
• サブネットマスクとは？仕組みと計算方法・CIDR表記との違いを実装者向けに解説：内部向けFQDNの解決先を閉じ込めるサブネットの区切り方を解説しています。
• AWSのインフラ構築：Route 53のレコード設計やACMの証明書運用を含め、要件に合わせたクラウド基盤を相談できます。