FQDN（完全修飾ドメイン名）

概要

FQDN（完全修飾ドメイン名） は、DNS の名前空間においてルートから末端まで省略なく記述したドメイン名です。RFC 8499 では「DNS 名前空間のルートまでのすべてのラベルを含むドメイン名」と定義されています。具体的には www.example.com. のように末尾にドット（.）を付けた表記が FQDN であり、この末尾のドットがルート（DNS 階層の最上位）を表します。

日常的に使われる www.example.com（末尾ドットなし）は厳密には FQDN ではなく、コンテキストによってはルートが暗黙的に補完される場合があります。ブラウザーのアドレスバーや一般的なネットワークツールでは末尾ドットを省略しても正しく動作しますが、DNS ゾーンファイルや一部の設定ファイルでは FQDN と相対名の区別が動作に直接影響します。

仕組み

FQDN は DNS のツリー構造上で位置を一意に特定する絶対名であり、末尾のドットがルートラベルを表します。

DNS 名前空間の階層構造

DNS はツリー構造の名前空間を持ち、ルート（空文字列のラベル）を頂点として階層的に管理されています。www.example.com. を分解すると次のようになります。

.                 ← ルート（空ラベル）
├── com.          ← TLD（トップレベルドメイン）
│   └── example.  ← セカンドレベルドメイン
│       └── www.  ← サブドメイン（ホスト名）

FQDN はこのツリーの末端からルートまでのパスを、ドットで区切って左から右へ並べたものです。末尾のドットはルートラベルの区切りであり、「ここで名前が完結している」ことを示します。

FQDN と相対名の違い

DNS の名前表記には FQDN（絶対名）と相対名の 2 種類があります。

表記	種類	意味
www.example.com.	FQDN（絶対名）	ルートまで指定済み。曖昧さがない
www.example.com	文脈依存	ブラウザーや dig では FQDN として扱われる。ゾーンファイルでは相対名になる場合がある
www	相対名	現在のゾーンの $ORIGIN が補完される

ファイルシステムで例えると、FQDN は /home/user/docs/file.txt のような絶対パスに相当し、相対名は docs/file.txt のような相対パスに相当します。絶対パスは起点を明示しているため位置に依存しませんが、相対パスは「現在のディレクトリ」によって解釈が変わります。

$ORIGIN とゾーンファイルでの解釈

DNS ゾーンファイルでは $ORIGIN ディレクティブで基準ドメインを設定します。末尾にドットがない名前は相対名として扱われ、$ORIGIN が自動的に付加されます。

$ORIGIN example.com.

www        IN  A  203.0.113.1   ; → www.example.com. に展開される
mail       IN  A  203.0.113.2   ; → mail.example.com. に展開される

ここで www と書いた場合、DNS ソフトウェアは $ORIGIN を付加して www.example.com. として解釈します。これが相対名の仕組みです。

ブラウザーやツールでの扱い

ブラウザー、dig、curl などの一般的なツールは、末尾にドットがなくても入力されたドメイン名を FQDN として扱います。dig A example.com と dig A example.com. は同じ結果を返します。

ただし、OS のリゾルバースタブが「検索ドメイン（search domain）」を設定している環境では、末尾ドットなしの名前に検索ドメインが付加される場合があります。たとえば検索ドメインが corp.internal に設定されている企業ネットワークで server1 を解決しようとすると、先に server1.corp.internal が試行されます。FQDN（server1.）で指定すれば検索ドメインの付加は行われません。

設定例

ゾーンファイルでは FQDN（末尾ドット付き）と相対名の使い分けが DNS レコードの正しさに直結します。

ゾーンファイルでの FQDN と相対名

$ORIGIN example.com.

; FQDN（末尾ドットあり）
www.example.com.     IN  A      203.0.113.1
mail.example.com.    IN  A      203.0.113.2
example.com.         IN  MX  10 mail.example.com.

; 相対名（末尾ドットなし、$ORIGIN が補完される）
www                  IN  A      203.0.113.1
mail                 IN  A      203.0.113.2
@                    IN  MX  10 mail

上の 2 つのブロックは同じ結果を生みます。@ は $ORIGIN 自体（この場合 example.com.）を表す特殊記号です。

CNAME レコードでの FQDN 指定

CNAME レコードのターゲットは FQDN で指定する必要があります。

$ORIGIN example.com.

; 正しい: ターゲットが FQDN
cdn   IN  CNAME  d123456.cloudfront.net.

; 誤り: ターゲットが相対名として解釈される
cdn   IN  CNAME  d123456.cloudfront.net
; → d123456.cloudfront.net.example.com. に展開されてしまう

外部ドメインを指す場合、末尾のドットを忘れると $ORIGIN が付加されて意図しない名前になります。

MX レコードでの FQDN 指定

MX レコードの交換先ホスト名も FQDN で指定します。

$ORIGIN example.com.

; 正しい: 交換先が FQDN
@   IN  MX  10  mail.example.com.
@   IN  MX  20  mail2.example.com.

; 外部サービスを使う場合も FQDN で指定
@   IN  MX  10  aspmx.l.google.com.

確認方法

dig コマンドの出力では、ANSWER SECTION のドメイン名が常に FQDN（末尾ドット付き）で表示されます。

dig A www.example.com

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

www.example.com. と末尾にドットが付いていることが確認できます。これは DNS プロトコルが内部的に常に FQDN で名前を扱っていることを反映しています。

末尾のドットを明示して問い合わせても結果は同じです。

dig A www.example.com.

外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/dns?domain=example.com&type=A"

{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "A": [
        { "address": "203.0.113.1", "ttl": 3600 }
      ]
    }
  },
  "error": null,
  "meta": { "responseTime": 45 }
}

レスポンスの data.domain フィールドにはクエリで渡したドメイン名がそのまま返ります。DNS API 内部では入力されたドメイン名を DNS over HTTPS で解決する際に FQDN として処理しています。

よくある問題

FQDN に関するトラブルの大半は、ゾーンファイルでの末尾ドットの付け忘れや、検索ドメインによる意図しない名前解決に起因します。

ゾーンファイルで末尾ドットを付け忘れて名前が二重になる

ゾーンファイルで最も頻繁に発生する問題です。外部ドメインを指す CNAME や MX のターゲットに末尾ドットを付け忘れると、$ORIGIN が付加されて d123456.cloudfront.net.example.com. のような存在しない名前が生成されます。

この場合、DNS 応答は NXDOMAIN（名前が存在しない）となり、ウェブサイトやメールが到達不能になります。原因がドットの有無だけであるため見落としやすく、ゾーンファイルの変更後は dig で実際の応答を確認することが重要です。

検索ドメインによる意図しない名前解決

企業ネットワークや VPN 環境では、OS に検索ドメイン（/etc/resolv.conf の search ディレクティブ）が設定されていることがあります。この場合、短いホスト名（server1 など）に検索ドメインが自動付加されます。

# /etc/resolv.conf
search corp.example.com
nameserver 10.0.0.53

この設定で server1 を解決すると server1.corp.example.com が先に試行されます。外部のドメインを意図しているのに内部の名前が解決されてしまうケースでは、FQDN（server1.example.com. のように末尾ドット付き）で指定することで検索ドメインの付加を回避できます。

SSL 証明書のドメイン名との不一致

SSL/TLS 証明書の Common Name（CN）や Subject Alternative Name（SAN）に記載されるドメイン名は末尾ドットを含みません。一方、DNS の内部処理では FQDN を使います。通常はブラウザーやライブラリが末尾ドットを除去してから証明書と照合するため問題になりませんが、カスタム実装で証明書検証を行う場合は、ドット有無の正規化処理が必要です。

DNS プロバイダーの管理画面での入力ルール

Cloudflare、AWS Route 53、Google Cloud DNS などのクラウド型 DNS サービスでは、管理画面上の入力ルールがサービスごとに異なります。Cloudflare はレコードのターゲットに末尾ドットを付けても付けなくても正しく処理しますが、Route 53 のゾーンファイルインポートでは末尾ドットが必要です。利用するサービスのドキュメントを確認してください。

FQDN の最大長と構造上の制約

RFC 1035 は FQDN の構造に対して次の制約を定めています。

• ドメイン名全体の最大長は 253 文字（DNS ワイヤフォーマットでは 255 オクテット。先頭の長さバイトとルートラベルの 2 オクテットを除いた表示形式で 253 文字）
• 各ラベルの最大長は 63 文字（ラベルはドットで区切られた各部分）
• ラベルには英字（a-z）、数字（0-9）、ハイフン（-）が使用可能。ラベルの先頭と末尾にハイフンは使えない

www.example.com.
^^^  ^^^^^^^  ^^^
 |      |      |
 |      |      └── ラベル3: "com"（3文字）
 |      └── ラベル2: "example"（7文字）
 └── ラベル1: "www"（3文字）

全体: 15文字（ドットを含む表示形式）

国際化ドメイン名（IDN）は Punycode に変換された後にこの制約が適用されます。たとえば 日本語.jp は xn--wgv71a309e.jp. に変換され、Punycode 形式のラベル長で判定されます。