FQDN（Fully Qualified Domain Name／完全修飾ドメイン名）とは、ホスト名からトップレベルドメインまでを一切省略せずにつないだ、ネットワーク上で機器やサービスを一意に指し示す完全な名前です。www.example.comのような形式がこれにあたります。用語としては単純ですが、実務では「hostname -fが短い名前しか返さない」「証明書に指定したFQDNと実際のアクセス先がずれている」といった形でつまずきます。この記事ではUbuntu 24.04で実際に実行した出力を並べながら、FQDNの定義・書き方・確認方法・トラブル対処までを整理します。
hostname -fweb01.example.internalまずはこのコマンドを自分のサーバーで実行してみてください。ドメイン部分まで表示されればFQDNが正しく設定されており、短い名前だけが返るなら設定が足りていません。その理由も後半で実例つきで解説します。
FQDNとは｜ホスト名とドメイン名をすべてつないだ完全な名前
FQDNは Fully Qualified Domain Name の略で、日本語では「完全修飾ドメイン名」と訳されます。「完全修飾（fully qualified）」とは、DNSの階層を上まですべて書き切っていて、どこから見ても解釈が一通りに定まるという意味です。
DNSの名前空間は、右端のルートを頂点にした木構造になっています。www.example.comを右から読むと、次のように階層をたどれます。
| 位置 | ラベル | 呼び方 | 意味 |
|---|---|---|---|
| 4 | （空文字） | ルート | DNS階層の頂点。表記上は末尾のドットで表す |
| 3 | com | トップレベルドメイン（TLD） | ドメインの分類 |
| 2 | example | セカンドレベルドメイン | 登録者が取得した部分 |
| 1 | www | ホスト名（サブドメイン） | そのドメイン内の個別のホスト・サービス |
この4段すべてを省略せずに並べたものがFQDNです。逆に、wwwだけ、web01だけといった途中までの名前はPQDN（Partially Qualified Domain Name／部分修飾ドメイン名）と呼ばれ、それ単体では宛先が確定しません。同じweb01でも、社内Aネットワークと社内Bネットワークで別のサーバーを指すことがあり得るからです。
末尾のドット（ルートドット）が意味するもの
厳密な意味でのFQDNは、ルートを表す末尾のドットまで含めたwww.example.com.です。digの出力を見ると、DNSの内部では常にこの表記が使われていることが分かります。
dig www.iana.org A +noall +question +answer;www.iana.org. IN A
www.iana.org. 1851 IN CNAME www.iana.org.cdn.cloudflare.net.
www.iana.org.cdn.cloudflare.net. 300 IN A 104.18.24.232
www.iana.org.cdn.cloudflare.net. 300 IN A 104.18.25.232質問行も回答行も、すべて末尾がドットで終わっています。ただし日常の会話や設定ファイルでは末尾のドットを省くのが一般的で、www.example.comと書いてもFQDNと呼んで差し支えありません。ドットを明示的に付けるかどうかが実際の動作に効いてくるのは、DNSの検索ドメイン（search）が設定されている環境です。これは後述の「短い名前がFQDNに補完される仕組み」で実演します。
FQDNとドメイン名・ホスト名・URL・IPアドレスの違い
混同しやすい用語を、https://www.example.com/blog/というURLを例に並べて整理します。
| 用語 | 例 | 説明 |
|---|---|---|
| ホスト名 | www | ドメイン内の個別のホストに付けた名前。単体では宛先が定まらない |
| ドメイン名 | example.com | 登録・管理の単位。TLDを含む |
| FQDN | www.example.com | ホスト名＋ドメイン名。名前解決の対象になる完全な名前 |
| URL | https://www.example.com/blog/ | FQDNにスキーム・ポート・パスなどを加えた「資源の場所」 |
| IPアドレス | 104.20.23.154 | 実際の通信の宛先。FQDNをDNSで引くと得られる |
要点は3つです。URLからスキームとパスを取り除いた「ホスト部」がFQDNであること、FQDNは名前でありIPアドレスは番号であること、そしてホスト名だけではFQDNにならないことです。
example.com はFQDNなのか
よくある疑問ですが、wwwが付いていないexample.comもFQDNです。ルートまでの階層が省略なく書かれていれば、ホスト名部分の有無は問いません。このwwwなしの形はネイキッドドメイン（apexドメイン、ゾーンapex）と呼ばれます。
そして実務上重要なのは、example.comとwww.example.comは別々のFQDNであり、DNS上も別レコードだという点です。片方だけ設定して、もう片方でアクセスできないという事故は非常によく起こります。両方を確認する習慣をつけてください。
for n in example.com www.example.com; do
printf '%-20s %s\n' "$n" "$(dig +short "$n" A | tr '\n' ' ')"
doneexample.com 172.66.147.243 104.20.23.154
www.example.com 104.20.23.154 172.66.147.243 どちらかで何も表示されなければ、そのFQDNのレコードが存在しません。
FQDNの書き方ルール｜使える文字と長さの制限
FQDNの構文はRFC 1035などで規定されており、次の制限があります。机上の知識に見えますが、digに渡すと実際にエラーで弾かれることが確認できます。
| 項目 | 制限 |
|---|---|
| 1ラベル（ドットで区切られた各要素）の長さ | 1〜63文字 |
| FQDN全体の長さ | 253文字まで（末尾ドットを含む表記で254文字、ワイヤ形式で255オクテット） |
| 使える文字 | 英数字とハイフン（-）、区切りのドット |
| ハイフンの位置 | ラベルの先頭・末尾には置けない |
| 大文字・小文字 | 区別しない（WWW.Example.COMとwww.example.comは同じ） |
ラベルを64文字にすると、DNSに問い合わせる前の時点で弾かれます。
dig +short "$(printf 'a%.0s' {1..64}).example.com" Adig: 'aaaaaaaa...aaaa.example.com' is not a legal name (label too long)全体長も同様です。63文字のラベル3つに末尾ラベルを足して長さを変えながら試すと、253文字までは通り、254文字で「ran out of space」になります。
a63=$(printf 'a%.0s' {1..63})
for last in 61 62; do
name="$a63.$a63.$a63.$(printf 'b%.0s' $(seq 1 $last))"
printf 'len=%s -> ' "${#name}"
dig +short "$name" A 2>&1 | head -1
echo
donelen=253 ->
len=254 -> dig: 'aaa...bbb' is not a legal name (ran out of space)アンダースコアと日本語ドメインの扱い
アンダースコア（_）はホスト名としては規格外ですが、DNSレコード名としては実際に使われています。SPF/DKIM/DMARCやSRVレコードがその代表です。
dig +short _dmarc.google.com TXT"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"ただしアンダースコア入りの名前にはSSL/TLS証明書を発行できません。Webサーバーのホスト名には使わないでください。
日本語ドメイン（IDN）は、DNS上ではPunycodeというxn--で始まるASCII表記に変換されて扱われます。変換結果はPythonで手早く確認できます。
python3 -c "print('総務省.jp'.encode('idna').decode())"xn--lhr645fjve.jp設定ファイルや証明書には、この変換後のPunycode表記を書くのが確実です。
LinuxでFQDNを確認する方法
ここからが実務の中心です。自サーバーのFQDNを確認する方法を、確実な順に見ていきます。
hostname -f が基本
FQDNが正しく設定されたホストでは、hostnameの各オプションが次のように使い分けられます。
hostname # 設定されているホスト名をそのまま表示
hostname -f # FQDN（--fqdn / --long と同じ）
hostname -s # ドメインを除いた短い名前（--short）
hostname -d # ドメイン部分だけ（--domain）FQDNをホスト名に設定したUbuntu 24.04で実行した結果です。
$ tail -1 /etc/hosts
172.17.0.2 web01.example.internal web01
$ hostname
web01.example.internal
$ hostname -f
web01.example.internal
$ hostname -s
web01
$ hostname -d
example.internal
$ uname -n
web01.example.internalなおhostnameコマンドは引数を取るとホスト名の設定になります。-fのハイフンを打ち忘れてhostname fと実行すると、ホスト名がfに変わってしまいます。root権限で作業しているときは特に注意してください。
hostname -f が短い名前しか返さない・エラーになる理由
ここが最大のつまずきポイントです。hostname -fはDNSに問い合わせているのではなく、現在のホスト名を名前解決してその「正式名（canonical name）」を返しているだけです。名前解決の経路は/etc/nsswitch.confで決まります。
grep ^hosts /etc/nsswitch.confhosts: files mdns4_minimal [NOTFOUND=return] dnsfilesが先頭にあるため、まず/etc/hostsが参照されます。つまり/etc/hostsの書き方がそのままhostname -fの結果を決めます。3パターンを実際に試すと違いがはっきりします。
パターン1：/etc/hostsに自ホストの行が無い
$ hostname -f
hostname: Name or service not known
$ echo $?
1パターン2：短い名前しか書かれていない
$ tail -1 /etc/hosts
172.17.0.2 web01
$ hostname -f
web01エラーは出ませんが、FQDNではなく短い名前が返ります。「hostname -fを実行したのにドメインが表示されない」というのはこの状態です。
パターン3：FQDNを先に書く（正しい書き方）
$ tail -1 /etc/hosts
172.17.0.2 web01.example.internal web01
$ hostname
web01
$ hostname -f
web01.example.internal
$ hostname -d
example.internalポイントはIPアドレスの直後にFQDNを書き、短い名前をその後ろに並べることです。この順序が逆だと、FQDNではなく短い名前が正式名として扱われます。パターン3ではホスト名自体はweb01のままですが、hostname -fはきちんとFQDNを返している点にも注目してください。
確認コマンド早見表
| 目的 | コマンド | 備考 |
|---|---|---|
| 自ホストのFQDN | hostname -f | /etc/hostsとnsswitch.confに依存 |
| 自ホストのFQDN（別経路） | uname -n | カーネルが保持するノード名をそのまま返す |
| ドメイン部分だけ | hostname -d / dnsdomainname | 未設定なら空行が返る |
| 設定の全体像 | hostnamectl | systemd環境。Static/Transientを区別できる |
| 全ネットワークIFのFQDN | hostname -A | 逆引きの結果に依存し、空になることも多い |
| 任意のFQDNのIP | dig +short <fqdn> | DNSのみを見る |
| OSと同じ経路で解決 | getent hosts <fqdn> | /etc/hostsも含めて確認できる |
hostnamectlや/etc/hostnameを含めたホスト名まわりの確認方法は、Linuxのホスト名を確認する方法まとめで詳しく扱っています。
FQDNからIPアドレスを引く｜dig・host・nslookup・getentの使い分け
「このFQDNはどこを指しているのか」を調べる方法は複数あり、見ている場所が違うため結果がずれることがあります。ここを理解しておくと切り分けが速くなります。
| コマンド | 参照先 | 向いている用途 |
|---|---|---|
dig | DNSサーバーのみ | DNSの登録内容そのものを確認する |
host | DNSサーバーのみ | 結果を短く読みたいとき |
nslookup | DNSサーバーのみ | Windowsと共通の手順で確認したいとき |
getent hosts | /etc/hosts＋DNS（nsswitch順） | アプリが実際にどう解決するかを再現する |
違いが最もはっきり出るのが、/etc/hostsだけに書かれたFQDNです。
$ echo "10.0.0.50 app01.example.internal app01" >> /etc/hosts
$ getent hosts app01.example.internal
10.0.0.50 app01.example.internal app01
$ dig +short app01.example.internal A
（何も表示されない）digで引けないのにアプリからは繋がる、あるいはその逆という現象は、たいていこれが原因です。「DNSに無いのに繋がる」なら/etc/hostsを疑い、「DNSにはあるのに繋がらない」なら/etc/hostsに古い行が残っていないかを確認してください。
getent hostsはIPv6アドレスを優先して返すことがあります。IPv4だけを見たい場合はgetent ahostsv4を使います。
$ getent hosts www.example.com
2606:4700:10::ac42:93f3 www.example.com
2606:4700:10::6814:179a www.example.com
$ getent ahostsv4 bashdo.com | head -1
183.90.183.141 STREAM bashdo.com存在しないFQDNの扱いにも差があります。getentとhostは失敗を終了ステータスで返しますが、dig +shortはNXDOMAIN（そのFQDNが存在しない）でも終了ステータス0を返します。スクリプトで判定するときは注意してください。
$ getent hosts zzz-not-exist-9x8y7z.jp; echo "exit=$?"
exit=2
$ host zzz-not-exist-9x8y7z.jp
Host zzz-not-exist-9x8y7z.jp not found: 3(NXDOMAIN)
$ dig +short zzz-not-exist-9x8y7z.jp A; echo "exit=$?"
exit=0FQDNが存在するかどうかを確実に判定したいときは、digのヘッダのstatusを見ます。
$ dig +noall +comments zzz-not-exist-9x8y7z.jp | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18331各コマンドの詳しいオプションは、digコマンド・hostコマンド・nslookupコマンドの記事にまとめています。
短い名前がFQDNに補完される仕組み（searchとndots）
社内サーバーでssh web01のように短い名前だけで繋がる環境があります。これは/etc/resolv.confのsearch（検索ドメイン）によって、名前解決の直前にFQDNへ補完されているためです。
$ grep -i search /etc/resolv.conf
search example.com
$ getent hosts www
2606:4700:10::ac42:93f3 www.example.com
2606:4700:10::6814:179a www.example.comwwwと入力しただけなのに、解決結果はwww.example.comになっています。digでも+domainオプションで同じ動きを再現でき、質問セクションを見れば補完後のFQDNが確認できます。
$ dig +domain=example.com +noall +question +answer www
;www.example.com. IN A
www.example.com. 5 IN A 172.66.147.243
www.example.com. 5 IN A 104.20.23.154補完するかどうかはoptions ndots:Nで制御されます。既定はndots:1で、入力した名前に含まれるドットがN個未満なら検索ドメインを付けて試すという挙動です。web01はドット0個なので補完対象、www.example.comはドット2個なのでそのまま問い合わせます。
この補完は便利な反面、意図しないFQDNに解決される事故のもとでもあります。example.comという検索ドメインが設定された環境でdig api.internalを実行すると、api.internal.example.comを先に引きに行くことがあります。補完を確実に止めたいときは、末尾にドットを付けて絶対表記にします。
# 補完される可能性がある
dig api.internal
# 補完されない（絶対FQDNとして問い合わせる）
dig api.internal.Kubernetesのクラスタ内でndots:5が設定されているために外部ドメインへの問い合わせが余計に発生する、というのもこの仕組みが原因です。設定ファイルにFQDNを書くときは末尾ドットを付けておくと、環境差による事故を避けられます。
LinuxでFQDNを設定する手順
自サーバーのFQDNを正しく設定するには、ホスト名の設定と/etc/hostsの設定を両方そろえる必要があります。片方だけではhostname -fが期待どおりに動きません。
systemd環境（Ubuntu 16.04以降、RHEL/CentOS 7以降）ではhostnamectlを使います。
# 1. ホスト名を設定（/etc/hostname に永続化される）
sudo hostnamectl set-hostname web01.example.internal
# 2. /etc/hosts にFQDNを先頭に書いた行を用意する
sudo sed -i 's/^127\.0\.1\.1.*/127.0.1.1\tweb01.example.internal web01/' /etc/hostsクラウド環境ではcloud-initが再起動のたびに/etc/hostsを書き戻すことがあります。その場合は/etc/cloud/cloud.cfgでpreserve_hostname: trueを設定するか、manage_etc_hostsのテンプレートを調整してください。
設定後は、次の3つがすべて期待どおりになっていることを確認します。
hostnamectl | head -3
hostname -f
getent hosts "$(hostname -f)"最後のgetentが空を返す場合、そのFQDNは自分自身からも解決できていません。メール送信やクラスタ参加でエラーになる典型的な状態です。
実務でFQDNを間違えやすい場面
SSL/TLS証明書は「FQDN単位」で発行される
証明書はドメイン単位ではなくFQDN単位で有効性が判定されます。ブラウザは接続先のFQDNが証明書のSAN（Subject Alternative Name）に含まれているかを見ており、含まれていなければ警告になります。実際の証明書はopensslで確認できます。
echo | openssl s_client -connect bashdo.com:443 -servername bashdo.com 2>/dev/null \
| openssl x509 -noout -subject -ext subjectAltNamesubject=CN = webmail.bashdo.com
X509v3 Subject Alternative Name:
DNS:bashdo.com, DNS:cpanel.bashdo.com, DNS:cpcalendars.bashdo.com, DNS:cpcontacts.bashdo.com, DNS:mail.bashdo.com, DNS:webdisk.bashdo.com, DNS:webmail.bashdo.com, DNS:www.bashdo.comこの証明書には8つのFQDNが列挙されています。ここに載っていないFQDNでアクセスすると証明書エラーになります。「wwwありでは繋がるが無しではエラー」という相談の多くは、SANに片方しか入っていないことが原因です。-servernameはSNI（接続したいFQDNをサーバーに伝える仕組み）の指定で、1つのIPで複数サイトを運用している環境では省略できません。
Webサーバー・メールサーバーの設定
| 場面 | FQDNを書く場所 | 間違えたときの症状 |
|---|---|---|
| Nginx | server_name | 別のserverブロックにマッチし、意図しないサイトが表示される |
| Apache | ServerName | 起動時にCould not reliably determine the server's fully qualified domain nameと警告 |
| Postfix | myhostname | HELO名が不正として受信側に拒否される |
| SSH | ~/.ssh/configのHostName | 短い名前が検索ドメインで別ホストに解決される |
| Let’s Encrypt | certbot -d <fqdn> | 指定し忘れたFQDNで証明書エラー |
SSHの接続先をFQDNで固定しておく方法はSSH configの書き方にまとめています。
DNS切り替え前にFQDN単位で動作確認する
サーバー移設でDNSを切り替える前に、新サーバーが正しく応答するかを確認したいことがあります。/etc/hostsを書き換えなくても、curl --resolveでFQDNとIPの組み合わせを一時的に上書きできます。
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' \
--resolve www.example.com:443:203.0.113.10 https://www.example.com/SNIとHostヘッダはFQDNのまま、接続先IPだけが差し替わるため、証明書とバーチャルホストの両方を本番と同じ条件で検証できます。
FQDNかどうかをシェルスクリプトで判定する
入力値がFQDNの形式になっているかを検証する関数です。末尾ドットを取り除いてから、長さ・ドットの有無・使用可能文字をまとめて判定します。
is_fqdn() {
local name="${1%.}" # 末尾のルートドットを除去
[ ${#name} -le 253 ] || return 1 # 全体長は253文字まで
case "$name" in *.*) ;; *) return 1 ;; esac # ドットが無ければPQDN
printf '%s' "$name" \
| grep -qE '^([a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z]{2,63}$'
}実行結果は次のとおりです。
OK : www.example.com
OK : example.com
OK : www.example.com.
NG : www
NG : localhost
NG : -bad.example.com
NG : a..b.com
OK : web01.example.internalこれはあくまで書式の検証で、そのFQDNが実在するかは別問題です。実在確認まで行うならgetentを組み合わせます。
if is_fqdn "$target" && getent hosts "$target" >/dev/null; then
echo "$target は書式も名前解決もOK"
else
echo "$target は不正、または解決できません" >&2
fi前述のとおりdig +shortは存在しない名前でも終了ステータス0を返すため、この用途にはgetentのほうが適しています。
Windows・macOSでFQDNを確認する
Windowsではコマンドプロンプトでipconfig /allを実行し、「ホスト名」と「プライマリ DNS サフィックス」を連結したものがFQDNです。PowerShellなら1行で取得できます。
[System.Net.Dns]::GetHostEntry($env:computerName).HostNamemacOSではhostname -fがLinuxと同様に使えるほか、scutil --get HostNameで設定値を確認できます。任意のFQDNのIPを調べるnslookupは、Windows・macOS・Linuxのいずれでも同じ書式で使えます。
nslookup www.example.comよくある質問
Q. FQDNとドメイン名の違いは何ですか？
ドメイン名はexample.comのような登録・管理の単位を指し、FQDNはそこにホスト名を含めたwww.example.comのような完全な名前を指します。ただしexample.com自体も階層を省略していないためFQDNです。「ドメイン名の一部を切り出した名前はFQDNではない」と考えると分かりやすくなります。
Q. 末尾のドットは付けるべきですか？
普段の記述では不要です。付ける価値があるのは、検索ドメイン（search）が設定された環境で補完を確実に止めたい場合と、DNSゾーンファイルにFQDNを書く場合です。ゾーンファイルでは末尾ドットを忘れるとゾーン名が自動で付加され、www.example.com.example.comのような誤りになります。
Q. hostname -f が「Name or service not known」になります
現在のホスト名が/etc/hostsにもDNSにも登録されていない状態です。/etc/hostsにIPアドレス・FQDN・短い名前の順で1行追加すれば解消します。
127.0.1.1 web01.example.internal web01Q. hostname -f はDNSを見ていますか？
/etc/nsswitch.confのhosts行の順序次第です。既定のUbuntuではfilesが先なので、/etc/hostsに一致があればDNSは参照されません。DNS側の登録内容を確認したい場合はdigを使ってください。
Q. FQDNは何文字まで使えますか？
ドットで区切られた各ラベルが63文字まで、全体で253文字までです。254文字にするとdigの時点で「ran out of space」として弾かれます。
Q. www.example.com と example.com は同じ扱いですか？
別のFQDNです。DNSレコードも証明書のSANも別々に用意する必要があります。Webサイトではどちらか一方に301リダイレクトで寄せるのが一般的ですが、その場合もリダイレクト元のFQDNに対するDNSレコードと証明書は必要です。
Q. IPアドレスならアクセスできるのにFQDNだと繋がりません
通信経路ではなく名前解決の問題です。まずgetent hosts <fqdn>で解決できるかを確認し、解決できなければdig <fqdn>のstatusを見ます。NXDOMAINならレコードが存在せず、SERVFAILならDNSサーバー側の問題です。手順はDNS_PROBE_FINISHED_NXDOMAINの原因と直し方で詳しく解説しています。
Q. FQDNの所有者や登録情報を調べたいのですが
whoisコマンドを使います。ただしwhoisが扱うのは登録単位であるドメイン名なので、www.example.comではなくexample.comを渡してください。
まとめ
- FQDNは、ホスト名からTLDまでを省略せずにつないだ完全な名前。
wwwが無いexample.comもFQDN - URLからスキームとパスを除いたホスト部がFQDN。IPアドレスは名前解決した結果の番号
- 各ラベルは63文字、全体は253文字まで。制限を超えると
digが問い合わせる前に弾く - 自ホストのFQDNは
hostname -f。返ってくる値は/etc/hostsの書き方で決まる。IPの直後にFQDN、その後ろに短い名前 digはDNSだけ、getent hostsは/etc/hostsも含めて見る。結果が食い違ったら/etc/hostsを疑う- 短い名前は
searchとndotsで補完される。止めたいときは末尾にドットを付けて絶対表記にする - SSL/TLS証明書はFQDN単位。
openssl x509 -ext subjectAltNameで対象FQDNを一覧できる
用語として覚えるより、手元のサーバーでhostname -fとgetent hosts $(hostname -f)を実行して、期待どおりの値が返るか確かめるのが近道です。
関連記事
- Linuxのホスト名を確認する方法まとめ｜hostname・hostnamectl・/etc/hostnameの使い方
- DNSサーバーとは？仕組み・種類・確認方法をコマンドで解説
- dig – DNS情報を問い合わせるコマンド
- host – シンプルなDNS問い合わせコマンド
- nslookup – Linuxで使うDNS問い合わせコマンドの使い方
- whois – ドメインやIPアドレスの登録情報を取得するコマンド
- DNS_PROBE_FINISHED_NXDOMAINの原因と直し方｜digで切り分ける
- LinuxでIPアドレスを確認する方法｜ip・hostname・nmcliコマンド
- SSH configの書き方｜~/.ssh/configで接続設定をまとめる方法
- Linuxトラブルシューティング総合ハブ
コメント