FQDNとは｜ホスト名・ドメイン名・URLの違いと末尾ドットの意味

FQDN は「住所を都道府県から番地まで全部書いたもの」にあたります。DNS の名前は右から左へ、ルート→トップレベルドメイン→その下の名前、と木の形に並んでいます。

flowchart TD
    R[ルート .] --> T[test]
    T --> E[example.test]
    E --> W[www.example.test.]
    E --> C[corp.example.test]
    C --> H[web01.corp.example.test.]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、自分で作った ip netns（名前 t57）の中に dnsmasq 2.91 を 127.0.0.1:53 で起動し、example.test（テスト用に予約された名前）のレコードだけを答えるようにしました。外部の DNS には問い合わせていません。netns の中で専用の mount 名前空間を作り、自分で書いた resolv.conf と hosts をその中だけに重ねて、ホスト名も UTS 名前空間の中だけで変えています（ホストの /etc は変えていません）。名前解決は glibc 2.39 の getent、hostname 3.23（Ubuntu の hostname パッケージ）、dig・nslookup・host 9.18.39、通信の中身は tcpdump 4.99.4、文字数の制限は Python 3.13.18・curl 8.5.0・idn2 2.3.7・Node.js 22.23.4、証明書は OpenSSL 3.0.13、ゾーンファイルは named-checkzone 9.18.39 で確かめました。dnsmasq・dig・tcpdump などは apt-get download した .deb を作業場所に展開して使い、システムには入れていません。Windows と Mac は動かせないため、Microsoft Learn と Apple の公式資料で確かめた範囲だけを書いています。用語の定義は RFC 9499・RFC 1035・RFC 1123、証明書は AWS Certificate Manager のドキュメントで確かめました。図は mermaid 11.16.0 で描画を確かめています（確認日 2026年10月29日）。

FQDNとは（意味・読み方・例）

この節では、FQDN の意味と読み方、どの部分がホスト名でどの部分がドメイン名なのかが分かります。

FQDN（エフキューディーエヌ）は Fully Qualified Domain Name の略で、日本語では「完全修飾ドメイン名」と呼びます。「完全修飾」は、途中を省かずに上の階層まですべて書いた、という意味です。

DNS の用語をまとめた RFC 9499 は、厳密には FQDN はルートを表す長さ0のラベルまで含み、www.example.net. のように末尾にドットを付けて書く、と説明しています。そのうえで、実際には www.example.net のようにドットを省いて書いたものも「FQDN」と呼ばれている、とも書いています。この記事でも、普段の書き方はドットなし、厳密な話をするときはドットありで書きます。

FQDNの例

最後の行のように、example.com そのものにも A レコードを付けて Web サイトを置くことができます。この場合は名前全体がドメイン名であり、そのまま FQDN でもあります。AWS Certificate Manager のドキュメントは、このような example.com を「apex domain（頂点のドメイン）」と呼び、www のような左側の名前を「subdomain」と呼んでいます。どこまでをホスト名と呼ぶかは文脈で変わりますが、「右端のトップレベルドメインまで全部書いてあるか」で FQDN かどうかが決まります。

ホスト名・ドメイン名・FQDN・URLの違い（一覧表）

この節では、混同しやすい4つの言葉の違いと、1つの URL のどこが何にあたるのかが分かります。

URL から「https://」・ポート番号・パスを取り除いた残りが FQDN です。 FQDN の最初のラベルがホスト名、残りがドメイン名です。

https://www.example.co.jp:8443/news/index.html?page=2
└─┬──┘   └─┬┘└─────┬────┘ └─┬┘└───────┬───────┘
スキーム  ホスト名 ドメイン名  ポート   パス・クエリ
         └──────┬───────┘
              FQDN

プログラムで URL から FQDN を取り出すと、次のようになりました。Python も Node.js も、大文字を小文字にそろえ、末尾のドットは残しました。

$ python3 -c '...urlsplit("https://WWW.Example.TEST.:8443/path/a.html?q=1#top")...'
scheme: https  hostname: www.example.test.  port: 8443  path: /path/a.html

$ node -e 'const u=new URL("https://WWW.Example.TEST.:8443/path/a.html?q=1#top"); console.log(u.hostname, u.host, u.port, u.pathname)'
www.example.test. www.example.test.:8443 8443 /path/a.html

「ホスト名」という言葉は、OS の設定では web01 のような1つのラベルを、DNS の文脈では FQDN 全体を指すことがあります。 RFC 9499 も、「ホスト名」は文脈によって意味が揺れる言葉だと書いています。設定ファイルの欄に「ホスト名」とあったら、短い名前と FQDN のどちらを求めているかをドキュメントで確かめます。

末尾のドット（.）とPQDN（絶対名と相対名）

この節では、FQDN の末尾にドットを付ける意味と、ドットの無い名前（PQDN）がどう扱われるのかが分かります。

末尾にドットがある名前は「これで全部」という絶対名で、補完されません。ドットが無い短い名前は相対名（PQDN：Partially Qualified Domain Name）で、足りない部分を周りの設定が補います。 AWS Certificate Manager のドキュメントも、完全修飾でない名前を PQDN と呼び、ルートまでが決まらないためあいまいだ、と説明しています。

同じ「www」でも、どの検索ドメインが補われるかで、まったく別のサーバー（192.0.2.30）に着きました。 手元の curl では、http://www:8080/ が 192.0.2.30 に向かい、そこで何も待ち受けていないため接続に失敗しました。

$ curl -v http://www:8080/
*   Trying 192.0.2.30:8080...
* Failed to connect to www port 8080 after 0 ms: Couldn't connect to server
curl: (7) Failed to connect to www port 8080 after 0 ms: Couldn't connect to server

末尾のドットが必要な場所・付けない場所

• 必要：DNS のゾーンファイル（BIND 形式）のレコードの右側。付け忘れるとゾーン名が後ろに足されます（後の節で実物を示します）。
• あってもよい：dig・nslookup の引数、resolv.conf の検索を使わせたくないときの名前。dig は表示でも必ず末尾にドットを付けます。
• 普段は付けない：ブラウザの URL、証明書の申請、メールアドレス、アプリの設定。ドット付きは別の名前として扱われることがあります（証明書の節で実物を示します）。

検索ドメインの補完をtcpdumpで見る（resolv.confのsearchとndots）

この節では、短い名前が FQDN に補われる仕組みを、DNS サーバーに実際に届いた問い合わせで確かめられます。

Linux では、/etc/resolv.conf の search に書いたドメインが、短い名前の後ろに順に足されて問い合わせられます。 netns の中だけで、次の resolv.conf を使いました。

search corp.example.test example.test
nameserver 127.0.0.1

flowchart TD
    N[名前を引く] --> D{末尾に . ?}
    D -->|ある| A[そのまま]
    D -->|ない| K{ドット数が<br>ndots 以上?}
    K -->|はい| A2[そのまま→<br>search 付き]
    K -->|いいえ| S[search 付き→<br>そのまま]

dnsmasq を置いた netns の lo を tcpdump で見ながら、getent ahostsv4 で名前を引きました（送信元のポート番号は client、DNS サーバーは dns に置き換えています）。

##### getent ahostsv4 www
192.0.2.30      STREAM www.corp.example.test
client > dns: 6371+ A? www.corp.example.test. (39)
dns > client: 6371* 1/0/0 A 192.0.2.30 (55)

##### getent ahostsv4 www.
client > dns: 10064+ A? www. (21)
dns > client: 10064 NXDomain 0/0/0 (21)

##### getent ahostsv4 www.example.test
192.0.2.10      STREAM www.example.test
client > dns: 2622+ A? www.example.test. (34)
dns > client: 2622* 1/0/0 A 192.0.2.10 (50)

見つからない名前では、検索ドメインを順に試し、最後にそのままの名前を試していました（dnsmasq のログ）。

query[A] app99.corp.example.test from 127.0.0.1
config app99.corp.example.test is NXDOMAIN
query[A] app99.example.test from 127.0.0.1
config app99.example.test is NXDOMAIN
query[A] app99 from 127.0.0.1
config app99 is NXDOMAIN

ndots：ドットの数で順番が変わる

resolv.conf の man ページによると、options ndots:n の既定は1で、名前に1つでもドットがあれば、先にそのままの名前（絶対名）として試し、見つからなければ検索ドメインを足します。ドットの数が ndots より少ない名前は、検索ドメインを先に試します。ndots:5 にすると、ドットが2つの www.example.test でも検索ドメインが先に付きました。

##### ndots:5 getent ahostsv4 www.example.test
192.0.2.10      STREAM www.example.test
client > dns: 35019+ A? www.example.test.corp.example.test. (52)
dns > client: 35019 NXDomain 0/0/0 (52)
client > dns: 28715+ A? www.example.test.example.test. (47)
dns > client: 28715 NXDomain 0/0/0 (47)
client > dns: 57282+ A? www.example.test. (34)
dns > client: 57282* 1/0/0 A 192.0.2.10 (50)

##### ndots:5 getent ahostsv4 www.example.test.
client > dns: 30497+ A? www.example.test. (34)
dns > client: 30497* 1/0/0 A 192.0.2.10 (50)

Kubernetes の公式ドキュメントでは、Pod の resolv.conf は search <namespace>.svc.cluster.local svc.cluster.local cluster.local と options ndots:5 の形になっています。この設定の Pod から外部の名前を引くと、手元の実験と同じように、検索ドメインを付けた問い合わせが先に何回か出ます。

dig・nslookup・host は補完の動きが違う

dig は既定で検索ドメインを使いません。nslookup と host は使います。 同じ「www」を引いた結果です。

$ dig www
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35015
;; QUESTION SECTION:
;www.				IN	A

$ dig +search www +noall +question +answer
;www.corp.example.test.		IN	A
www.corp.example.test.	0	IN	A	192.0.2.30

$ nslookup www
Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	www.corp.example.test
Address: 192.0.2.30

$ host www
www.corp.example.test has address 192.0.2.30

$ nslookup www.
** server can't find www: NXDOMAIN

「アプリからは繋がるのに dig では見つからない」ときは、短い名前を dig に渡していないかを見ます。dig +search を付けるか、FQDN で引くと、アプリと同じ結果になります。nslookup の使い方は、関連記事「nslookupの使い方｜逆引き・DNS指定・MX・エラーの意味を実例で」で扱っています。

FQDNの長さ制限（63文字・253文字）を超えたときのエラー

この節では、FQDN とラベルの長さの上限と、上限を超えたときに各ツールが出すエラーの原文が分かります。

RFC 1035 はラベルを63オクテット以下、名前全体を255オクテット以下と決めています。この255は DNS の通信の形（ワイヤー形式）での数で、文字で書くと253文字が上限になります。 ワイヤー形式では、各ラベルの前に「長さ」を表す1バイトが付き、最後にルートを表す0が1バイト付くためです。

www.example.test  → 03 www 07 example 04 test 00
                  → 1+3 + 1+7 + 1+4 + 1 = 18 オクテット（文字では16）

$ python3 -c '... 63文字.63文字.63文字.61文字 の長さを数える ...'
text 253 wire 255

tcpdump でも確かめられます。問い合わせの大きさは「ヘッダー12＋名前＋4」で、www.example.test. は 12＋18＋4＝34 でした。253文字の名前は 12＋255＋4＝271 で、上限ちょうどの問い合わせが送られていました。

client > dns: 2622+ A? www.example.test. (34)
client > dns: 16230+ A? aaa…(63).bbb…(63).ccc…(63).ddd…(61). (271)

上限を超えたときの各ツールのエラー

63文字のラベルと253文字の名前には dnsmasq でレコードを作り、64文字・254文字（末尾ドットなし）と比べました。

$ dig aaaa…(64文字).example.test
dig: 'aaaa…(64文字).example.test' is not a legal name (label too long)

$ dig aaa…(63).bbb…(63).ccc…(63).ddd…(61)e
dig: 'aaa…(63).bbb…(63).ccc…(63).ddd…(61)e' is not a legal name (ran out of space)

$ python3 -c 'socket.getaddrinfo("aaaa…(64文字).example.test", 80)'
UnicodeEncodeError 'idna' codec can't encode characters in position 0-63: label too long

$ python3 -c 'socket.getaddrinfo("…254文字…", 80)'
gaierror [Errno -2] Name or service not known

$ curl http://aaaa…(64文字).example.test/
curl: (6) Could not resolve host: aaaa…(64文字).example.test

上限を超えた名前は、DNS サーバーに届く前に手元で止められていました。 tcpdump には、64文字のラベルと254文字の名前の問い合わせが1つも出ていません。Python や curl のエラーは「見つからない」と同じ文言なので、DNS サーバーのログに何も無いときは、名前の長さを数えてみます。

ホスト名そのものの長さ

OS のホスト名（短い名前）には、DNS とは別の上限があります。systemd の hostname(5) は、Linux カーネルの上限に合わせて64文字までとし、ドットを含まない1つのラベルにすることを強く勧めています。手元で65文字のホスト名を設定すると、次のエラーになりました。

$ hostname xxxxx…(65文字)
hostname: name too long

Windows では、コンピューター名（NetBIOS 名）は15文字までです。Microsoft Learn の命名規則のページは、DNS のホスト名はラベル63バイト・FQDN 255バイトまでとしたうえで、15文字を超えるコンピューター名は Windows では設定できないと説明しています。

FQDNに使える文字（英数字・ハイフン・アンダースコア・日本語ドメイン）

この節では、FQDN（ホスト名として使う名前）に使える文字と、アンダースコアや日本語を使ったときに何が起きるかが分かります。

ホスト名として使う名前は、各ラベルを英字・数字・ハイフンだけで作り、先頭と末尾にハイフンを置きません。大文字と小文字は区別されません。 RFC 9499 は、これを RFC 1034 の「preferred name syntax」に、RFC 1123 の「数字で始まってもよい」という変更を加えたもの、と説明しています。

$ hostname web_01
hostname: the specified hostname is invalid
$ hostname -- -bad
hostname: the specified hostname is invalid

$ dig TXT _dmarc.example.test +short
"v=DMARC1; p=none"

アンダースコアは「ホスト名」には使えませんが、DNS の名前としては使われます。 _dmarc のような TXT レコードや SRV レコードはその例で、手元の dnsmasq でも普通に引けました。Microsoft Learn の命名規則のページも、アンダースコアは SRV レコードでは RFC で認められている一方、コンピューター名には使えない文字に挙げています。公開の証明書でもアンダースコアの入った名前は使えない、と SSL.com の解説は書いています。

日本語ドメイン名（国際化ドメイン名）

日本語のラベルは、DNS では xn-- で始まる英数字（Punycode）に変換して扱います。

$ idn2 '日本語.example.test'
xn--wgv71a119e.example.test
$ idn2 -d 'xn--wgv71a119e.example.test'
日本語.example.test
$ idn2 'ＷＷＷ.Example.test'
www.example.test

$ node -e 'console.log(new URL("http://日本語.example.test/").hostname)'
xn--wgv71a119e.example.test

curl は Punycode に変換してから問い合わせ、Node.js の URL も Punycode の形に変換しました。一方、getent（glibc の既定の動き）は日本語のまま渡すと問い合わせを出さずに失敗し、手元の dig は UTF-8 のバイトのまま問い合わせを送りました。設定ファイルや証明書に日本語ドメインを書くときは、Punycode の形（xn--…）で書くと、ツールの違いで結果が変わりません。

自分のFQDNを確認する方法（Linux・Windows・Mac）

この節では、いま使っているコンピューターの FQDN を、OS ごとに確かめる方法が分かります。

Linux：hostname -f と /etc/hosts

Linux では hostname -f が FQDN、hostname -s が短い名前、hostname -d がドメイン名を表示します。 /etc/hosts に 127.0.1.1 web01.corp.example.test web01 と書いた状態での結果です。

$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 web01.corp.example.test web01

$ hostname
web01
$ hostname -f
web01.corp.example.test
$ hostname -s
web01
$ hostname -d
corp.example.test
$ dnsdomainname
corp.example.test
$ python3 -c 'import socket; print(socket.gethostname(), socket.getfqdn())'
web01 web01.corp.example.test

Ubuntu の hostname(1) は、FQDN を「ホスト名を resolver で引いたときに返ってくる名前」と定め、ホスト名を FQDN の別名にする書き方として 127.0.1.1 ursula.example.com ursula の例を挙げています。そのうえで、hostname コマンドで FQDN を直接変えることはできない、とも書いています。

1. 1短いホスト名を読むgethostname()。/etc/hostname や hostnamectl で設定した値（例：web01）
2. 2/etc/hosts を探す/etc/nsswitch.conf が hosts: files dns なら先に hosts。その行の最初の名前が正式名
3. 3DNS に問い合わせるhosts に無ければ search を足して DNS で引く（web01.corp.example.test）
4. 4返ってきた正式名が FQDNどこにも無ければ Name or service not known のエラー

ホスト名を変えるときは hostnamectl set-hostname web01 のように短い名前を設定し、FQDN は /etc/hosts か DNS で決めます。systemd の hostname(5) も、ホスト名はドットを含まない1つのラベルにすることを強く勧めています。

Windows：hostname・ipconfig /all・PowerShell

Windows は手元で動かせないため、Microsoft Learn で確かめた範囲です。

• hostname：フル コンピューター名のうち、ホスト名の部分を表示します（Microsoft Learn「hostname」）。echo %COMPUTERNAME% でも、通常は同じ文字列が大文字で出ます。
• ipconfig /all：すべてのアダプターの完全な TCP/IP 構成を表示します。先頭の全体の欄のホスト名と、プライマリ DNS サフィックスを「.」でつないだものが、そのコンピューターの FQDN です。Microsoft Learn「Configure the primary DNS suffix for a client computer」は、プライマリ DNS サフィックスを「FQDN を作るときにコンピューター名に足す DNS サフィックス」と説明しています。
• PowerShell：Get-DnsClientGlobalSetting の SuffixSearchList に、短い名前に足す DNS サフィックスの一覧が入ります。Microsoft Learn によると、プライマリ DNS サフィックスが設定されていれば、それが一覧の最初に入ります。

hostname
Get-DnsClientGlobalSetting
[System.Net.NetworkInformation.IPGlobalProperties]::GetIPGlobalProperties() | Select-Object HostName, DomainName

3行目の IPGlobalProperties は .NET のクラスで、DomainName は「コンピューターが登録されているドメイン」を返し、ドメインに属していなければ空になります（Microsoft Learn）。ipconfig の詳しい使い方は、関連記事「ipconfigの使い方とMTUとは｜/all・/flushdnsとMTUの実例」で扱っています。

Mac：hostname・scutil・システム設定

• ターミナルで hostname を実行すると、gethostname の名前が出ます。
• Apple が公開している scutil の man ページによると、scutil --get ComputerName（画面に出る名前）、scutil --get LocalHostName（Bonjour 用の名前）、scutil --get HostName（hostname と gethostname が使う名前）の3つを別々に持っています。
• Apple サポート「Macでコンピュータの名前またはローカルホスト名を変更する」によると、ローカルホスト名はコンピュータ名の末尾に「.local」を付けたもので、「システム設定」＞「一般」＞「共有」の下で変更できます。My-Computer.local は同じネットワークの中で使う名前で、インターネットの DNS の FQDN とは別物です。

hostname -f が短い名前を返す・エラーになる原因（/etc/hostsの順番）

この節では、hostname -f が FQDN を返さないときの原因を、/etc/hosts と DNS の状態を変えた実物で切り分けられます。

/etc/hosts の行で、FQDN を短い名前より前に書かないと、hostname -f は短い名前を返します。 同じホスト名 web01 で、/etc/hosts と DNS の状態だけを変えた結果です。

$ getent hosts web01        # 正しい順番
127.0.1.1       web01.corp.example.test web01
$ getent hosts web01        # 逆順
127.0.1.1       web01 web01.corp.example.test

$ hostname -f               # DNS にも無いとき
hostname: Name or service not known
$ hostname -f               # DNS サーバーに届かないとき
hostname: Temporary failure in name resolution

逆順のとき、hostname -f と Python の socket.getfqdn() で答えが分かれました。 Python のドキュメントによると、getfqdn() は正式名と別名を順に見て、「ドットを含む最初の名前」を選びます。hostname -f は行の最初の名前（正式名）をそのまま返すため、web01 になりました。プログラムによって FQDN が違って見えるときは、/etc/hosts の順番を疑います。

Ubuntu の hostname(1) は、インターフェースやアドレスが複数ある機械では FQDN が複数あったり無かったりするため、hostname --fqdn よりも hostname --all-fqdns（-A）を使うように勧めています。-A は、すべてのアドレスを逆引きして見つかった名前を並べます。

相手のFQDNを調べる方法（URLから取り出す・dig・nslookup・逆引き）

この節では、URL や IP アドレスから相手の FQDN を調べる方法と、その結果の読み方が分かります。

URL が分かっていれば、「https://」とポート・パスを除いた部分が FQDN です。 その FQDN が何のレコードを持っているかは dig で確かめます。

$ dig www.example.test +noall +question +answer
;www.example.test.		IN	A
www.example.test.	0	IN	A	192.0.2.10

$ dig blog.example.test +noall +answer
blog.example.test.	0	IN	CNAME	www.example.test.
www.example.test.	0	IN	A	192.0.2.10

$ dig MX example.test +noall +answer
example.test.		0	IN	MX	10 mail.example.test.

$ host -t MX example.test
example.test mail is handled by 10 mail.example.test.

• CNAME：blog.example.test は別名で、正式な FQDN は www.example.test です。証明書や設定には、利用者が開く名前（blog の方）を書きます。
• MX：メールの受け取り先として、FQDN（mail.example.test.）を書きます。IP アドレスは書けません。
• dig の出力では、名前は必ず末尾のドット付き（絶対名）で表示されます。

IPアドレスから逆引きする

$ dig -x 192.0.2.10 +noall +answer
10.2.0.192.in-addr.arpa. 0	IN	PTR	www.example.test.

$ dig -x 192.0.2.21 +short
web01.corp.example.test.

逆引き（PTR レコード）で分かるのは、そのアドレスの持ち主が登録した名前だけです。 1つのアドレスに複数のサイトが同居していることも、PTR が登録されていないことも多く、逆引きの名前と、ブラウザで開いている FQDN が一致するとは限りません。レコードの種類ごとの役割は、関連記事「DNSレコードの種類一覧｜digの実出力で役割と設定ミスを確認」で扱っています。

ゾーンファイルの末尾ドット忘れ（MX・CNAMEが別の名前になる）

この節では、DNS のゾーンファイルで末尾のドットを付け忘れたときに何が起き、どう見つけるのかが分かります。

BIND 形式のゾーンファイルでは、末尾にドットの無い名前は相対名として扱われ、後ろに $ORIGIN（ゾーンの名前）が足されます。 わざとドットを付け忘れたゾーンファイルを、named-checkzone で確かめました。

$ORIGIN example.test.
$TTL 300
@       IN SOA ns1.example.test. admin.example.test. ( 1 3600 600 86400 300 )
@       IN NS  ns1.example.test.
ns1     IN A   192.0.2.53
www     IN A   192.0.2.10
mail    IN A   192.0.2.25
@       IN MX  10 mail.example.test
blog    IN CNAME www.example.test
shop    IN CNAME www

$ named-checkzone example.test example.test.zone
zone example.test/IN: example.test/MX 'mail.example.test.example.test' has no address records (A or AAAA)
zone example.test/IN: loaded serial 1
OK

$ named-checkzone -D -o - example.test example.test.zone | grep -E 'MX|CNAME'
example.test.          300 IN MX     10 mail.example.test.example.test.
blog.example.test.     300 IN CNAME  www.example.test.example.test.
shop.example.test.     300 IN CNAME  www.example.test.

• named-checkzone は結果を「OK」と出しました。 MX は「アドレスが無い」と警告が出ましたが、CNAME のドット忘れには警告がありませんでした。-D で展開後の名前を出して確かめるのが確実です。
• shop IN CNAME www は、相対名として www.example.test. になり、意図どおりです。相対名で書くか、末尾ドット付きの FQDN で書くかを、ファイルの中でそろえると間違えにくくなります。

SSL/TLS証明書・メール（HELO/EHLO）とFQDN

この節では、証明書の CN・SAN に書く FQDN と、ワイルドカード・末尾ドットの扱い、メールの HELO/EHLO で名乗る FQDN が分かります。

サーバー証明書は FQDN に対して発行し、ブラウザは「開いた FQDN が証明書の SAN（Subject Alternative Name）に入っているか」で検証します。 SAN に www.example.test と *.example.test を入れた自己署名証明書を作り、openssl x509 -checkhost で確かめました。

$ openssl x509 -in c.pem -noout -subject -ext subjectAltName
subject=CN = www.example.test
X509v3 Subject Alternative Name:
    DNS:www.example.test, DNS:*.example.test

$ openssl x509 -in c.pem -noout -checkhost www.example.test
Hostname www.example.test does match certificate
$ openssl x509 -in c.pem -noout -checkhost www.example.test.
Hostname www.example.test. does NOT match certificate
$ openssl x509 -in c.pem -noout -checkhost a.b.example.test
Hostname a.b.example.test does NOT match certificate
$ openssl x509 -in c.pem -noout -checkhost example.test
Hostname example.test does NOT match certificate

AWS Certificate Manager のドキュメントも、*.example.com は1階層のサブドメインだけを守り、example.com そのものや test.login.example.com は含まない、と説明しています。example.com と www.example.com の両方で開かれるサイトは、両方を SAN に入れます。 ACM での申請と DNS 検証は、関連記事「ACM証明書のDNS検証｜発行手順と保留中から進まない原因」で扱っています。

末尾ドット付きで HTTPS を開くと、クライアントで結果が分かれた

netns の中で 192.0.2.10 に HTTPS のサーバーを立て、届いた Host ヘッダーと SNI（TLS で最初に送る接続先の名前）を返すようにしました。

$ curl --cacert c.pem https://www.example.test:8443/
Host header: www.example.test:8443
SNI: 'www.example.test'

$ curl --cacert c.pem https://www.example.test.:8443/
Host header: www.example.test.:8443
SNI: 'www.example.test'

# Python 3.13 の urllib（同じ証明書を信頼）
https://www.example.test:8443/  -> Host header: www.example.test:8443 | SNI: 'www.example.test'
https://www.example.test.:8443/ -> URLError <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Hostname mismatch, certificate is not valid for 'www.example.test.'. (_ssl.c:1035)>

curl は末尾のドットを外して SNI と証明書の検証を行い、成功しました。Python は末尾ドット付きの名前のまま検証して失敗しました。 どちらも Host ヘッダーにはドットが残っていたため、Web サーバーのバーチャルホストの設定によっては、別のサイトとして扱われることもあります。URL や API の接続先には、末尾のドットを付けずに書くのが無難です。 openssl での証明書の確かめ方は、関連記事「opensslコマンドの使い方｜目的別一覧と実行結果・エラー対処【3系】」で扱っています。

メールの HELO/EHLO で名乗る FQDN

メールを送る側は、SMTP の最初に EHLO（または HELO）で自分の名前を名乗ります。RFC 5321 の 2.3.5 は、EHLO に書く名前を、アドレスに解決できる主たるホスト名（primary host name）か、名前が無いときはアドレスの形（[192.0.2.1] のような形）にする（MUST）と決め、4.1.1.1 は FQDN があればそれを送る、としています。Python の smtplib は、名乗る名前を指定しなければ socket.getfqdn() の結果を使います（Python のドキュメント）。127.0.0.1 に立てた受信だけのモックで確かめました。

# /etc/hosts に FQDN があるとき
local_hostname: web01.corp.example.test
C: ehlo web01.corp.example.test

# FQDN が引けないとき（getfqdn() が web01 しか返さない）
local_hostname: [127.0.0.1]
C: ehlo [127.0.0.1]

FQDN が引けないと、smtplib は短い名前ではなくアドレスの形で名乗りました。メールサーバーによっては、EHLO の名前が FQDN でない・DNS で引けない送信元を受け付けない設定があります。送信サーバーの FQDN は、正引き（A）と逆引き（PTR）をそろえておきます。

よくあるエラー／つまずき（原文つき）

この節では、FQDN にまつわるエラーの原文から、原因と直し方を引けます。

つまずきやすい点

• 「ping は通るのにブラウザで証明書エラー」：短い名前（web01）で開いていて、証明書の SAN には FQDN しか無い。FQDN で開きます。
• 「社内の PC だけ別のサーバーに着く」：DHCP などで配られた検索ドメインが補われている。FQDN で書くか、search の順番を確かめます。
• 「Kubernetes の Pod から外部への名前解決で DNS の問い合わせが多い」：ndots:5 で、検索ドメイン付きの問い合わせが先に出ている。手元の実験では、末尾ドット付きの FQDN で1回に減りました。
• 「URL をそのまま DNS の欄に貼った」：https:// やパスを含めると登録できないか、別の名前になります。FQDN の部分だけを書きます。

FQDNと短い名前の使い分け（判断表）

この節では、設定や運用で FQDN・短い名前・末尾ドット付きのどれを書くべきかを、場面ごとに決められます。

• 1右端のトップレベルドメインまで書いたかweb01 や web01.corp で止まっていないか。search 頼みは環境ごとに結果が変わる
• 2スキーム・ポート・パスを含めていないかDNS の欄と証明書の欄は FQDN だけ
• 3末尾ドットの要・不要を場所で分けたかゾーンファイルは付ける。URL・証明書は付けない
• 4使える文字と長さを守ったか英数字とハイフン、ラベル63文字、全体253文字。日本語は xn-- の形
• 5正引きと逆引きがそろっているかメール送信サーバーや hostname -A を使う機械では特に

よくある質問

Q. FQDNとは何ですか？ A. ホスト名からトップレベルドメインまでを省略せずに書いた名前です。www.example.co.jp のように書き、DNS 上で1つの名前に決まります。厳密には末尾にルートを表すドットが付いた www.example.co.jp. が FQDN です。

Q. FQDNの読み方は？ A. エフキューディーエヌと読みます。Fully Qualified Domain Name の略で、日本語では「完全修飾ドメイン名」です。

Q. FQDNとURLの違いは何ですか？ A. URL は「https://」などのスキーム、ポート番号、パスやクエリまでを含みます。FQDN はそのうちのホスト部分（www.example.co.jp）だけです。

Q. ホスト名とドメイン名の違いは何ですか？ A. ホスト名は機械やサービス1つの名前（www・web01）、ドメイン名はそれが属する区画の名前（example.co.jp）です。2つを「.」でつないだものが FQDN です。ただし「ホスト名」は FQDN 全体を指して使われることもあります。

Q. 末尾のドットは付けたほうがよいですか？ A. ゾーンファイルでは付けます。ブラウザの URL・証明書・アプリの設定では、普通は付けません。手元では、末尾ドット付きの URL で curl は成功し、Python は証明書の検証で失敗しました。

Q. www の付かない example.com も FQDN ですか？ A. はい。トップレベルドメインまで書いてあり、DNS で引ける名前なので FQDN です。AWS のドキュメントでは apex domain（頂点のドメイン）と呼んでいます。

Q. FQDNの最大文字数は？ A. 1つのラベルが63文字、全体が253文字（末尾ドットを除く）です。RFC 1035 の上限は通信上の255オクテットで、長さを表すバイトとルートの分を引くと253文字になります。手元の dig は、254文字の名前を ran out of space で止めました。

Q. IPアドレスはFQDNの代わりになりますか？ A. 接続はできますが、証明書の検証やバーチャルホストは名前で行うため、Web サイトや API では FQDN を使います。IP アドレスが変わっても設定を変えずに済む点でも、FQDN が向いています。

Q. 自分のPCのFQDNを調べるには？ A. Linux は hostname -f、Mac は hostname と scutil --get HostName、Windows は ipconfig /all のホスト名とプライマリ DNS サフィックスを見ます。Linux で短い名前しか出ないときは、/etc/hosts の行で FQDN が先に書いてあるかを確かめます。

Q. サブドメインとホスト名の違いは？ A. どちらも左側に付ける名前で、レジストラの管理画面では www を「サブドメイン」と呼ぶこともあります。その名前の下にさらに名前を作る区画ならサブドメイン（corp.example.test）、機械1台を指す名前ならホスト名（web01）と呼び分けると混乱しにくくなります。

まとめ

• FQDN は、ホスト名からトップレベルドメインまでを省略せずに書いた名前。URL のホスト部分にあたり、厳密には末尾にルートのドットが付く。
• 短い名前（PQDN）は resolv.conf の search が補う。手元では「www」が search の順番で別のサーバー（192.0.2.30）に着き、末尾ドット付きは補完されなかった。
• 長さはラベル63文字・全体253文字（通信上255オクテット）。超えた名前は DNS に問い合わせる前に手元で止まり、dig は label too long・ran out of space を出した。
• Linux の hostname -f は /etc/hosts の行の最初の名前を返す。FQDN を先に書かないと短い名前が返り、Python の getfqdn() とも答えが分かれた。
• 証明書の SAN には FQDN を書き、ワイルドカードは1階層だけ。ゾーンファイルでは末尾ドットを付け、URL や証明書では付けない。

次に読むとよい記事です。FQDN に付けるレコードの種類は関連記事「DNSレコードの種類一覧｜digの実出力で役割と設定ミスを確認」で、名前解決の確かめ方は関連記事「nslookupの使い方｜逆引き・DNS指定・MX・エラーの意味を実例で」で扱っています。

参考・出典

確認日はいずれも 2026年10月29日です。

• IETF「RFC 9499 DNS Terminology」2. Names：https://www.rfc-editor.org/rfc/rfc9499.html
• IETF「RFC 1035 Domain Names - Implementation and Specification」2.3.4 Size limits：https://www.rfc-editor.org/rfc/rfc1035
• IETF「RFC 1123 Requirements for Internet Hosts」2.1 Host Names and Numbers：https://www.rfc-editor.org/rfc/rfc1123
• IETF「RFC 6761 Special-Use Domain Names」（.test）：https://www.rfc-editor.org/rfc/rfc6761
• IETF「RFC 5321 Simple Mail Transfer Protocol」2.3.5・4.1.1.1：https://www.rfc-editor.org/rfc/rfc5321
• man7.org「resolv.conf(5)」：https://man7.org/linux/man-pages/man5/resolv.conf.5.html
• Ubuntu Manpage「hostname(1)」（noble）：https://manpages.ubuntu.com/manpages/noble/man1/hostname.1.html
• systemd「hostname(5)」：https://www.freedesktop.org/software/systemd/man/latest/hostname.html
• Python ドキュメント「socket.getfqdn」：https://docs.python.org/3/library/socket.html#socket.getfqdn
• Python ドキュメント「smtplib」：https://docs.python.org/3/library/smtplib.html
• Kubernetes「DNS for Services and Pods」：https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
• AWS「AWS Certificate Manager concepts」（Domain names・Wildcard）：https://docs.aws.amazon.com/acm/latest/userguide/acm-concepts.html
• Microsoft Learn「hostname」：https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/hostname
• Microsoft Learn「ipconfig」：https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/ipconfig
• Microsoft Learn「Get-DnsClientGlobalSetting」：https://learn.microsoft.com/en-us/powershell/module/dnsclient/get-dnsclientglobalsetting
• Microsoft Learn「Naming conventions in Active Directory for computers, domains, sites, and OUs」：https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/naming-conventions-for-computer-domain-site-ou
• Microsoft Learn「Configure the primary DNS suffix for a client computer」：https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc786695(v=ws.10)
• Microsoft Learn「IPGlobalProperties.DomainName」：https://learn.microsoft.com/en-us/dotnet/api/system.net.networkinformation.ipglobalproperties.domainname
• Apple サポート「Macでコンピュータの名前またはローカルホスト名を変更する」：https://support.apple.com/ja-jp/guide/mac-help/mchlp2322/mac
• Apple Open Source「scutil(8)」：https://opensource.apple.com/source/configd/configd-289/scutil.tproj/scutil.8.auto.html
• SSL.com「完全修飾ドメイン名（FQDN）とは何ですか？」：https://www.ssl.com/ja/よくある質問（FAQ）/完全修飾ドメイン名（FQDN）とは何か/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。