FQDNとは

FQDNを読むときの前提

FQDN（Fully Qualified Domain Name）は、ホスト名からドメイン名までを省略せずに表した完全修飾ドメイン名です。例として、単なるserverではなくserver.example.comのように、どのドメイン配下の名前かを一意に示します。

実務では、DNSレコード、証明書SAN、監視対象、FW申請、URL、メール設定、SaaSの所有確認でFQDNを扱います。短縮名や検索サフィックスに頼ると、環境によって別の名前へ解決されることがあります。

証跡には、対象FQDN、末尾ドットの有無、問い合わせ元、解決結果、CNAME先、証明書SAN、利用用途、確認時刻を残します。

短縮名と検索サフィックスを分ける

社内端末では、serverのような短縮名がDNS suffix search listによりserver.example.localなどへ補完されます。利用者端末では通るのに監視サーバーでは通らない場合、FQDNではなく短縮名の補完差が原因になることがあります。

障害調査では、入力した名前、実際に問い合わせたFQDN、返ったIPを分けます。pingやcurlの結果だけでは、どの名前を見ていたかが残りません。

• 短縮名ではなくFQDNで再確認する。
• 検索サフィックスと実問い合わせ名を保存する。
• 端末、監視サーバー、社内DNSの差を確認する。

証明書とFQDNを突合する

HTTPSやTLSでは、接続先FQDNが証明書SANに含まれている必要があります。DNSで正しいIPへ向いていても、証明書が別名向けならブラウザやクライアントで警告や接続失敗になります。

CNAMEでCDNやSaaSへ向ける場合も、利用者がアクセスするFQDNをサービス側が受け付け、証明書を提示できる必要があります。DNSだけでなく、アプリやLB側のHost名設定も確認します。

• FQDNと証明書SANの一致を確認する。
• CNAME先サービスのホスト名登録を確認する。
• DNS、TLS、HTTP Hostを同じ証跡に残す。

所有者と用途を明確にする

FQDNは人が読む名前なので、用途や所有者が曖昧なまま増えやすいです。検証用、移行用、一時回避用の名前が残ると、証明書更新、監視、FW許可、SaaS連携の棚卸しで問題になります。

命名では、環境、システム、用途、リージョン、公開/内部の区別を設計します。名前だけで機密情報や顧客名を露出しない配慮も必要です。

• FQDNの所有者、用途、期限を台帳へ残す。
• 検証用や一時名には削除条件を付ける。
• 公開DNSへ載せてよい名前か確認する。

変更証跡と引き継ぎ

FQDN変更では、DNS、証明書、監視、FW、ブックマーク、アプリ設定、外部連携が同時に影響します。名前を変えただけに見えても、実際には利用者導線や認証連携が壊れることがあります。

引き継ぎでは、正規FQDN、別名、CNAME先、証明書、管理者、関連語としてDNS、CNAME、TTL、SAN、証明書を残すと確認しやすくなります。

• 正規名と別名を分けて記録する。
• 監視、証明書、FW申請の参照名を更新する。
• 旧FQDNの廃止日とリダイレクト方針を残す。

関連語

同じ主要カテゴリの用語

DNS・名前解決の学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能