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オクテットという上限があり、ホスト名として使える文字は英数字とハイフンに限られること。第三に、サーバーのホスト名設定・証明書の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の名前空間は、頂点にルートを置いた木構造です。RFC 2181の第11節は、長さゼロの名前がDNSツリーのルートを表し、通常は「.」と書かれると定義しています。これを明示すると www.example.co.jp. のように末尾へドットが1つ付き、この絶対表記が厳密な意味でのFQDNです。日常のブラウザ入力や設定では末尾ドットを省くのが通例ですが、DNSゾーンファイルなどでは末尾ドットの有無で意味が変わります。

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

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文字が上限とされます。長いサブドメインを何段も重ねると、この上限に近づく点に留意してください。ホスト名の側にも、RFC 1123の第2.1節が「ホストソフトウェアは63文字までのホスト名を扱わなければならず、255文字までを扱うべき」と要求しています。

使える文字は、英字・数字・ハイフンに限られます（いわゆるLDH規則）。ラベルの先頭と末尾にハイフンは置けず、アンダースコアは本来ホスト名としては許されません。ただしRFC 1123の同じ節は、RFC 952が課していた「先頭は英字」という制限を緩め、先頭に数字を置いてよいと明記しました。3com.example.co.jp のような数字始まりのラベルが通るのはこのためです。

DNSのラベル制約とホスト名のLDH規則・IDNのPunycode変換

ここで切り分けておきたいのが、LDH規則がDNSプロトコル自体の制約ではないという点です。RFC 2181の第11節は「DNSがラベルに課す制限は長さだけであり、それ以外は任意のバイナリ文字列をラベルに使える」と述べ、DNSの実装がラベルに制限を課してはならないとしています。実際、SRVレコードの _sip._tcp.example.co.jp やDKIMのセレクタなど、アンダースコアを含む名前がDNS上では正しく動いています。禁じているのはDNSではなく、ホスト名を扱うアプリケーション側の規則だと理解しておくと、証明書やメール周りの仕様を読むときに混乱しません。

日本語などの国際化ドメイン名（IDN）は、そのままでは解決できず、Punycodeという方式で xn-- で始まるASCII表記へ変換してからDNSへ渡されます。この変換と検証の枠組みを定めているのがRFC 5891（IDNA2008のプロトコル仕様）です。ブラウザは日本語ドメインを表示上そのまま見せますが、内部では変換後のFQDNで問い合わせが飛んでいます。証明書の発行やログの突き合わせでは変換後の xn-- 形式が現れるため、両方の表記を等価に扱えるようにしておくと調査が楽になります。

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

FQDNが実際の通信につながるのは、DNSがFQDNをIPアドレスへ変換するからです。ブラウザやOSは、まずキャッシュを確認し、無ければリゾルバへ問い合わせる仕組みです。リゾルバはルートDNSサーバー、jp や co.jp を管理する上位サーバー、そして example.co.jp の権威DNSサーバーへと、右のラベルから順にたどって最終的な答えを得ます。この一連の流れは名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認方法を実装者向けに解説で全体像を追えます。

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

コマンドでFQDNを確認・設定する手順とLinux・Windowsでの実行例

ここからは概念ではなく、手元のサーバーやPCでFQDNを確認・設定する具体的な操作に踏み込みます。指定のずれは、通信不達や証明書エラーとして表面化します。

LinuxのhostnameコマンドとhostnamectlでFQDNを設定する手順

サーバー自身のFQDNは、コマンドで確認できます。Linuxでは hostname -f がFQDN、hostname が短いホスト名を返す仕組みです。systemd系では hostnamectl set-hostname にFQDN形式の名前を渡して設定します。hostnamectl(1) のマニュアルによれば、この操作は静的・一時的・整形済みの各ホスト名をまとめて扱うため、設定ファイルを直接編集するより取りこぼしが起きにくくなっています。

# 現在の短いホスト名とFQDNを確認する
hostname
hostname -f

# FQDN形式でホスト名を設定する（systemd系）
sudo hostnamectl set-hostname web01.example.co.jp
hostnamectl status

# /etc/hosts に自ホストのFQDNと短縮名を併記しておく
127.0.1.1  web01.example.co.jp  web01

# 設定後に期待どおりのFQDNが返るか確認する
hostname -f

ここで多いのが、短いホスト名だけを設定し、/etc/hosts 側にFQDNを書き忘れるミスです。その状態だと hostname -f が短縮名しか返さず、メールサーバーやクラスタ構成でホスト間の認証や証明書検証が失敗します。設定後は必ず最後の一行を実行し、意図したFQDNが返るか確かめてください。

WindowsのipconfigとPowerShellでFQDNを確認する手順

Windowsでは、Microsoft Learn の ipconfig リファレンスにあるとおり、すべてのオプションを付けて実行すると詳細なTCP/IP構成が表示されます。そこに出る「ホスト名」と「プライマリDNSサフィックス」を連結したものがFQDNです。PowerShellなら、解決済みの正式名を1行で取得できます。

# ホスト名とプライマリDNSサフィックスを確認する
ipconfig /all

# 自ホストのFQDNを直接取得する
[System.Net.Dns]::GetHostEntry($env:COMPUTERNAME).HostName

# 任意のFQDNの解決結果を確認する
Resolve-DnsName -Name www.example.co.jp -Type A

ドメイン参加していない端末では、プライマリDNSサフィックスが空のままでFQDNが組み立たない場合があります。その場合はシステムのプロパティからサフィックスを設定するか、DHCPで配布される接続固有のDNSサフィックスを確認します。取得結果が短縮名のままなら、名前解決の設定側を疑うのが早道です。

digとnslookupでFQDNの名前解決を確認する手順とAレコードの読み方

任意のFQDNが実際にどのIPへ解決されるかは、dig や nslookup で確認します。末尾ドットを付けた絶対名で問い合わせると、サフィックス補完の影響を排除して素の解決結果を見られます。

# 正引き: FQDNからIPv4アドレスを引く
dig +short www.example.co.jp A

# CNAMEの連鎖と最終的なAレコードまで応答を見る
dig www.example.co.jp A +noall +answer

# 末尾ドットを付けた絶対名で問い合わせる（サフィックス補完を止める）
dig www.example.co.jp. A +short

# 参照する権威サーバーを指定して確認する
dig @ns1.example.co.jp www.example.co.jp A +noall +answer

# Windowsでも同じ確認ができる
nslookup -type=A www.example.co.jp

+noall +answer を付けると、応答セクションだけが残るので、CNAMEを何段たどって最後にどのAレコードへ着地したかが読み取れます。権威サーバーを直接指定した結果と、通常のリゾルバ経由の結果が食い違うときは、キャッシュのTTLが残っているか、内外で別の応答を返す構成になっていると判断できます。

SSL/TLS証明書とAWSのDNSでFQDNを指定する手順と注意点

FQDNの指定ミスがもっとも痛い形で表面化するのが、証明書とクラウドのDNSです。ここは名前が1文字違うだけで検証が通りません。

SSL/TLS証明書のSANにFQDNを列挙する手順とコモンネームの扱い

SSL/TLS証明書は、アクセスに使うFQDNと証明書に書かれた名前が一致して初めて有効になります。かつては証明書のコモンネーム（CN）にFQDNを1つ書く方式でしたが、RFC 9525（2023年11月・RFC 6125を廃止）は「コモンネームのRDNはサービスの識別に使ってはならない」と定め、SAN（Subject Alternative Name）に列挙されたFQDNで一致を判定する方式へ一本化しました。証明書を用意するときは、www.example.co.jp と example.co.jp のように、実際にアクセスされるFQDNをSANへ漏れなく含めてください。TLS自体の仕組みやバージョン選定はTLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説で整理しています。

# 証明書に載っているFQDNの一覧（SAN）を確認する
openssl s_client -connect www.example.co.jp:443 -servername www.example.co.jp -showcerts -verify_return_error | openssl x509 -noout -ext subjectAltName

複数のホストをまとめたい場合は、*.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とACMで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へ向けるエイリアスレコードを作成してください。AWS公式のエイリアス／非エイリアスの選び方によれば、CNAMEはゾーンの頂点（example.co.jp そのもの）に作れないのに対し、エイリアスは頂点にも設定できます。AWSリソースへ向けたエイリアスの問い合わせは課金対象外で、CNAMEの問い合わせは課金される点も違いです。ホストゾーンの設計やルーティング方式はAmazon Route 53とは？DNS・ドメイン登録・ルーティング設計を実装者目線で解説にまとめています。

証明書の管理単位もFQDNです。AWS Certificate Manager（ACM）では、保護するFQDNを指定して証明書を発行し、DNS検証用のCNAMEレコードをホストゾーンへ登録して所有を証明します。ACMのDNS検証に関する公式ドキュメントは、証明書が使用中であり検証用のCNAMEレコードが残っている限り自動更新される一方、そのレコードを削除すると自動更新が止まる点を明記しています。FQDNの綴りやサフィックスを1文字でも誤ると検証が完了せず、発行に至りません。こうしたRoute 53のレコード設計やACMの証明書運用、ロードバランサーの構成を含めてクラウド基盤を外部に相談したい場合は、インフラ構築（AWS・Google Cloud・Azure）で設計段階からの支援を受けられます。名前設計の巧拙が、後の証明書更新や移行のしやすさを左右します。

FQDN設計で失敗する典型パターンと命名・内外分離の判断基準と見送り条件

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

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

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

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

よくある質問

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

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

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

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

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

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

Linuxでは hostname -f でそのサーバーのFQDNを確認できます。Windowsでは ipconfig をすべてのオプション付きで実行し、表示される「ホスト名」と「プライマリDNSサフィックス」を連結した形がFQDNです。PowerShellなら [System.Net.Dns]::GetHostEntry($env:COMPUTERNAME).HostName が正式名を直接返します。任意のFQDNが引けるIPを調べたいときは、dig +short www.example.co.jp A や nslookup にFQDNを渡してください。

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

ホスト名として使える文字は英字・数字・ハイフンで、ラベルの先頭と末尾にハイフンは置けません。長さはRFC 1035で1ラベル最大63オクテット、名前全体で最大255オクテットと定められ、表示上はおおむね253文字が上限です。なおRFC 2181はDNSプロトコル自体が課す制限を長さだけとしており、アンダースコアを含む _sip._tcp のような名前はDNS上では正当です。日本語ドメインはPunycodeで xn-- 形式のASCIIへ変換されてからDNSへ問い合わせられます。

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

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

関連記事

• 名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認方法を実装者向けに解説：FQDNが実際にIPアドレスへ変換される名前解決の全体像を確認できます。
• Amazon Route 53とは？DNS・ドメイン登録・ルーティング設計を実装者目線で解説：FQDNをAWS上のリソースへ向けるレコード設計とルーティング方式を扱います。
• プライベートDNSとは？内部名前解決の仕組み・Route 53プライベートホストゾーン・設計を実装者向けに解説：内部向けFQDNを外部と分けて解決させる構成を具体的に解説しています。
• CIDRとは？表記の読み方からサブネット設計・AWS VPCでの使い方まで：FQDNの解決先であるIPアドレスの範囲設計を扱います。名前側の本記事と対で読むと理解が深まります。
• サブネットマスクとは？仕組みと計算方法・CIDR表記との違いを実装者向けに解説：内部向けFQDNの解決先を閉じ込めるサブネットの区切り方を解説しています。