完全修飾ドメイン名はDNS名を省略せずに指定します

完全修飾ドメイン名（FQDN）は、ルートまで含む完全なDNS名を指定します。DNSの明示的な表記形式では、www.example.com. の末尾にドットが付きます。日常的な表記では末尾のドットを省略し、www.example.com もFQDNと呼びます。RFC 9499は両方の慣行を説明しています。

実務上の誤りは、末尾にドットがない名前をすべてのプログラムが同じように解釈すると考えることです。ローカルの検索リストやゾーンファイルのオリジンによって、最終的な名前が変わります。ブラウザーのアドレスには、アプリケーション側の規則も関わります。

本記事では、ツールが実際に使用する名前の確認方法を説明します。例では、例示用に予約されたドメイン配下の仮の設定を使います。診断コマンドはDNS情報を読み取り、レコードを変更しません。

完全なDNS名はルートラベルを含みます

DNSは名前を階層的に管理します。www.example.com. を右から左へ読むと、ルート、com、example、www の順に階層をたどれます。ルートは空のラベルなので、文字で表した名前の末尾に区切りのドットが現れます。RFC 1034の3.1節が構造を定義しています。

末尾のドットは、句読点の名前を持つ別のサーバーを追加しません。末尾のドットは、名前の終点を明示します。設定を確認するときは、入力欄が完全な名前を含むのか、補完のための情報を必要とする名前を含むのかを調べます。

仮の問い合わせに api とだけ書いてある場合を考えます。問い合わせだけでは、サービスが api.example.com. と api.example.net. のどちらを使うのか分かりません。両方の名前は同じ最初のラベルを含みます。どちらかの接続先を調査する前に、サービスの担当者へ完全な名前を確認してください。

FQDNは www で始まる必要もありません。example.com. と mail.example.com. は両方ともルートを含みます。サブドメインは別のドメインの下に階層を追加しますが、ラベルの数が増えても修飾の完全性は上がりません。完全性を決めるのは、ラベルの数ではなく省略の有無です。

ルートゾーン（ルートサーバー）はDNS階層の最上位に関わる概念です。名前の末尾のドットはルートラベルを表します。DNSの図を読むときや、支援を依頼するときは、ルートゾーンと名前の表記を区別してください。

現在の用語規定は、厳密な表記形式と一般的な表示形式を区別しています。したがって、通常の会話で example.com をFQDNと呼ぶこと自体は、必ずしも技術的な誤りではありません。RFC 9499は両者の違いを説明しています。

曖昧さが問題になる場面では、明示的な表記を使ってください。調査記録には、意図した問い合わせ名を api.example.com. と書き、実際の入力を正確に残します。空白、句読点、サフィックスの設定は別々に保存します。入力欄の画像も役立ちますが、コピーした値があると比較しやすくなります。

名前が「完全」であることは、サービスが利用できる証拠にはなりません。完全な名前は問い合わせ先を指定します。サービスが必要なデータを公開し、意図した接続を受け付けるかは、別に確認する必要があります。

たとえば、導入時の確認記録には、意図したホスト名、必要なレコードタイプ、期待するサービス、担当チームを書きます。後の調査担当者は、確認記録を実際の設定と比較できます。「FQDNを設定する」という指示だけでは、重要な判断事項が分かりません。

ローカルの検索リストは問い合わせ前に名前を補完できます

DNSリゾルバー（再帰的リゾルバー）は、アプリケーションのためにDNS情報を取得します。ローカルのソフトウェアは、設定済みの検索リストを使って相対名を解釈する場合があります。RFC 1034は、利用者向けの入力に対する解釈が実装によって異なることを明示しています。同規格は検索リストと固定のオリジンを区別しています。

仮に、クライアントの検索サフィックスを office.example.com とします。利用者が printer と入力すると、検索処理は候補名 printer.office.example.com. を作れます。printer. だけを調べるテストは、別の名前を問い合わせます。回答を比較する前に、問い合わせ候補を比較してください。

ドットを含む名前にも注意が必要です。一部の実装は、検索処理を適用する順番を ndots の値で決めます。BINDの資料は、名前検索ツールにおける設定を説明しています。同じ資料によると、dig は既定では検索リストを使いません。dig のオプション説明を確認してください。

既定の動作の違いは、調査の見落としにつながります。技術者が通常の dig コマンドで期待した回答を得ても、アプリケーションの失敗が続く場合があります。コマンドがアプリケーションと同じ名前の解釈を再現したとは限りません。結果が矛盾すると判断する前に、各テストが確認した内容を記録してください。

Kubernetesは、名前の文脈が重要になる具体例です。Podの設定はDNS検索ドメインとリゾルバーのオプションを含められます。公式資料は生成されたリゾルバー設定を示し、Windowsノードでの違いも説明しています。KubernetesのPod DNS設定の説明を参照してください。

Pod内で実行する仮のアプリケーションを調べる場合は、問題が起きるコンテナー内の設定を確認します。開発者のノートパソコンで名前を解決できても、コンテナーの設定は確認できません。アプリケーションの入力、コンテナーの設定、最終的な問い合わせ名を別々に比較してください。

障害調査では、次の表を使って確認項目を整理できます。表は確認事項を示しており、すべてのリゾルバーが同じ順番で問い合わせることを保証しません。

障害記録には、最初に期待する名前を書きます。次に、失敗したアプリケーションの入力名を記録します。さらに、名前検索処理が実際に問い合わせた名前の証拠を集めます。期待した動作と観測した動作は、別の文で記述してください。

名前が異なる場合は、権威DNSレコードを変更する前に設定を調べます。意図しない補完名にレコードを追加すると、元の誤りを隠す場合があります。アプリケーションが対応する設定形式に従い、意図する接続先を明示する修正を選んでください。

ゾーンファイルはオリジンを使って相対名を補完します

DNSゾーンファイルは、名前を補完する明確な規則を持ちます。ドットで終わる名前は絶対名です。末尾にドットがない名前は、現在のオリジンに対する相対名です。RFC 1035の5.1節が規則を定義しています。

仮のゾーンファイルで $ORIGIN example.com. を設定した場合を考えます。所有者名 www は www.example.com. を表します。所有者名 www.example.com. も、同じ名前を直接指定します。一方、相対的な所有者名 www.example.com は www.example.com.example.com. に展開します。

次の仮のゾーンファイル抜粋は、所有者名とターゲットの規則を並べて示します。レコードは名前の展開を説明する例であり、そのまま運用するゾーンではありません。

$ORIGIN example.com.
www 300 IN CNAME app.example.net.
mail 300 IN CNAME app.example.net

両方のターゲットが複数のラベルを含んでいても、末尾のドットの欠落は2番目のターゲットを変えます。オリジンの規則は、所有者名とレコードデータ内のドメイン名の両方に当てはまります。RFC 1035の5.1節が展開を規定しています。

レコードデータにもドメイン名が現れます。仮のCNAME行 www IN CNAME app.example.net. は、絶対名のターゲットを指定します。末尾のドットを省略すると、例のオリジンではターゲットが app.example.net.example.com. になります。規則の対象はドメイン名のフィールドであり、任意のテキストやアドレスのフィールドではありません。RFC 1035はマスターファイルのドメイン名とCNAMEデータを説明しています。

所有者名とターゲットを区別すると、確認しやすくなります。所有者名はレコードを持つ名前を指定します。ターゲットはレコードデータ内の別の名前を指定します。値を調べる前に、両方のフィールドを特定してください。DNSレコードタイプ（A、AAAA、CNAME、MX、TXT）は、各レコードの役割を説明しています。

ホスティング型DNSの入力フォームは、生のゾーンファイルと異なる形式を使う場合があります。ゾーンファイルの表記をコピーする前に、対象フィールドの提供元の説明を読んでください。フォームの処理後に、保存した完全な名前を確認します。入力した文字を画面がすべて保持すると仮定せず、プレビューやエクスポートを証拠として確認してください。

たとえば、仮のフォームが example.com 配下のレコード名を求める場合、フォームが www、www.example.com、または別の形式を要求するかを確認します。「常にドットを付ける」という一般則では、製品固有の入力形式は判断できません。

修正時には、編集前のレコードを保存してください。意図した所有者名とターゲットを完全な形で記録します。意図した設定と異なるフィールドだけを変更します。保存後のレコードを再確認し、意図した所有者名を問い合わせてください。

画面がサフィックスを重複させた場合は、同じ入力を繰り返さないでください。フィールドの説明を読み直し、表示されたゾーンの文脈を確認します。保存した名前が正しく見えるのに解決できない場合は、問い合わせの診断へ進みます。画面上の正しい表示だけでは、DNSの回答を確認したことになりません。

条件を固定した問い合わせは名前の誤りとアプリケーションの障害を区別します

BINDの dig が利用できる場合は、読み取り専用のDNSテストから始めます。dig example.com. A +nosearch を実行してください。調査中は出力全体を保存します。問い合わせ、応答ステータス、返されたデータ、応答したサーバーを記録します。例示用ドメインの期待アドレスを勝手に決めないでください。

回答を解釈する前に、QUESTION SECTION を確認してください。問い合わせは example.com.、クラス IN、タイプ A を含むはずです。別の所有者名の回答がエイリアスの参照に続く場合があるため、回答だけでは元の問い合わせを特定できません。BINDの資料はdigの問い合わせと回答の出力を説明しています。

次に、dig printer A +domain=office.example.com +showsearch で仮の検索サフィックスを明示的にテストします。+domain は検索サフィックスを1つ設定し、検索処理を有効にします。+showsearch は途中の結果を表示します。両方のオプションによって、マシンのリゾルバー設定を編集せずに候補名を確認できます。BINDは両方のオプションを説明しています。

例は printer.office.example.com. の存在を示しません。実際の環境で使う名前と、承認済みのサフィックスに置き換えてください。失敗した回答でも、ツールが試した名前を確認する手がかりになります。

検索を有効にしたテストを、dig printer.office.example.com. A +nosearch と比較します。両方のテストを同じ環境で実行してください。問い合わせタイプも固定します。比較の目的を明確にするため、入力は1つずつ変更してください。

2番目のコマンドを、アプリケーションの完全な再現として扱わないでください。コマンドはDNS名の解釈を切り分けます。アプリケーションの調査では、アプリケーション自身の設定と対応する診断方法も使います。テスト入力を変える前に、アプリケーションのエラーを記録してください。

復旧手順は、「アプリケーションが意図した名前を問い合わせたか」という具体的な確認から始めます。不明な場合は、名前検索の証拠を集めます。意図した名前と違う場合は、名前または対応する検索設定を修正します。意図した名前を使った場合は、返されたデータとサービスへの接続を調べます。

末尾のドットは名前の補完を明示するので、DNSの調査で役立ちます。ただし、DNSの規則はウェブアドレス全般の入力規則にはなりません。DNSの診断で example.com. を使ったという理由だけで、公開リンクを https://example.com./ に書き換えないでください。

TLSは、別の規則を確認する必要性を示します。Server Name Indication拡張は、末尾のドットを含まないDNSホスト名を規定しています。したがって、DNSの表記上の慣行を、すべてのアプリケーションの必須形式にはできません。RFC 6066の3節はSNIのホスト名表現を定義しています。

DNSが成功してHTTPSが失敗する場合は、意図した公開URLを保持し、アプリケーションの接続エラーを調べます。サービスが対応するホスト名設定を確認してください。名前の実験を成功に見せるために証明書の検証を無効にしないでください。DNS問い合わせの成功が確認するのは、調査のDNS部分だけです。

別の担当者も使えるようにテスト記録を残します。時刻、ネットワーク環境、コマンド、応答全体を含めてください。アプリケーションがローカル、コンテナー内、別のマシンのどこで動いたのかを書きます。問い合わせを省き、アドレスだけを記録する報告は避けてください。

障害を解決済みとする前に、利用者が最初に行った操作を繰り返します。条件を固定したDNSテストは名前の修正を確認でき、元の操作は意図した作業の成功を確認できます。両方の結果を記録し、未確認の環境についての証拠として扱わないでください。

障害記録の最後には、具体的な原因と修正を書きます。たとえば、相対名のゾーンファイルのターゲットにゾーンサフィックスが加わったことや、アプリケーションが未設定の検索サフィックスに依存したことを記述します。観測した名前と、修正後に成功した確認を含めます。具体的な情報は、「FQDNが間違っていた」という説明よりも原因を明確にします。

次の資料は名前の表記と診断方法を規定しています

• RFC 9499：DNS用語。2節のグローバルDNSの表記形式と完全修飾ドメイン名。取得日：2026-10-21。
• RFC 1034：ドメイン名の概念と機能。3.1節のラベル、絶対名、相対名の文脈。取得日：2026-10-21。
• RFC 1035：ドメイン名の実装と仕様。5.1節のマスターファイルのオリジンとドメイン名フィールド。CNAMEデータは3.3.1節も参照。取得日：2026-10-21。
• ISC BIND 9マニュアル：dig。+domain、+ndots、+search、+showsearch の各オプション。取得日：2026-10-21。
• Kubernetes：ServiceとPodのDNS。PodのDNS設定とWindowsノードの名前解決。取得日：2026-10-21。
• RFC 6066：TLS拡張の定義。3節のServer Name Indicationと HostName の表現。取得日：2026-10-21。