IPアドレスを直接入力する社内URLを名前へ変えるには、利用中のDNS名前空間にホストレコードを追加し、Webサーバーの証明書とバーチャルホストもその名前へ対応させます。DNSのAレコードを作るだけではHTTPS証明書エラーは直りません。新しく`CMS.local`のような独立ゾーンを作る方法は、mDNSで予約された`.local`と競合するため、2026年の新規設計では避け、組織が所有するドメインの内部サブドメインを使うのが安全です。
名前解決、証明書、Webサーバー、アプリ設定、リダイレクト、監視を一つの変更として扱います。DNSだけ先に切り替えず、旧IP直打ち経路を一定期間残して段階移行します。
新しい名前を決める
たとえば組織が`example.jp`を所有しているなら、`cms.intra.example.jp`のような管理されたサブドメインを候補にします。外部DNSと内部DNSで同じゾーンを異なる内容にするスプリットDNSは可能ですが、運用担当、委任、証明書検証、VPN外からの挙動を設計します。既存Active DirectoryのDNSゾーンへホストを追加できるなら、新規ゾーンは不要な場合があります。
RFC 6762では`.local.`はMulticast DNS用に特別扱いされます。Windows DNSへ同名ゾーンを作ると、macOS、Linux、プリンター、会議機器などの名前解決が環境依存になる可能性があります。すでに`.local`のADドメインを使っている環境を直ちに改名するという意味ではなく、新しいアプリ名に追加採用しないという判断です。
変更前の調査
- 現在のIP、ポート、URL、利用者、ショートカット、ブックマーク、連携API
- DNSサーバー、ゾーン種別、複製範囲、動的更新、エージング、TTL
- Webサーバーのホスト名設定、TLS証明書のSAN、SNI、HTTPからHTTPSへの転送
- アプリ内の絶対URL、Cookieドメイン、認証コールバック、CORS、プロキシ
- 監視、バックアップ、ファイアウォール、ロードバランサー、ログ収集の登録値
DNSゾーンとレコードをエクスポートし、現行Web設定と証明書をバックアップします。変更対象のIPを別機器が使っていないかIPAMやDHCPで確認します。TTLを短くする場合は、既存TTLより前に変更し、十分な時間を置いてから切替日を迎えます。極端に短いTTLを恒久運用するとDNS負荷が増えるため、安定後に戻します。
DNS ManagerでAレコードを作る
- 管理対象DNSサーバーへ承認された管理端末から接続し、正しい前方参照ゾーンを選びます。
- ゾーン内で「New Host (A or AAAA)」を開き、短いホスト名とIPv4アドレスを入力します。IPv6を使うならAAAAを別途設計します。
- 逆引きが必要で、対応する逆引きゾーンが管理されている場合だけPTR作成を選びます。
- 追加後にDNS Managerを更新し、レコード名、IP、TTL、タイムスタンプを確認します。
- 権威DNSを明示した問い合わせと、利用者端末からの問い合わせを実施し、期待したアドレスだけが返るか確認します。
Microsoft公式資料では、Aレコード作成にはFQDNとIPv4アドレスが必要で、DNS ManagerまたはDnsServer PowerShellモジュールを利用できます。手作業と自動化を混在させる場合は、IPAMや構成管理を正とし、重複レコードを作らないようにします。
新しいゾーンが必要な場合
既存名前空間に置けない場合は、所有ドメイン配下の内部サブドメインをDNSチームから委任してもらいます。Active Directory統合ゾーンなら、複製範囲をフォレスト全体、ドメイン全体、指定パーティションのどこにするかを到達範囲と障害設計から選びます。「最上位が推奨」と一律に決めず、他ドメインから利用するか、DNSサーバーがどこにあるかを確認します。
動的更新はサーバーの固定レコードに必須ではありません。安全な動的更新を使う場合も、誰が更新できるかと所有者を確認します。ゾーン転送、通知、セカンダリDNSを設定するなら送信先を限定し、外部へ内部ホスト一覧が漏れないようにします。
HTTPS証明書とWebサーバー
ブラウザーで`https://新しい名前/`を開くには、証明書のSANにそのFQDNが含まれ、信頼されたCAから発行されている必要があります。IP向け証明書を名前へ流用したり、警告を無視する手順を利用者へ案内したりしません。内部PKIを使う場合は、管理端末へルート証明書が正しく配布され、失効確認ができることを確認します。
IIS、Apache、Nginx、アプライアンスなどでHostヘッダーまたはSNIに応じたサイト設定を追加します。既存サイトと同じIPを共有する場合、誤った証明書や別サイトが表示されないか確認します。アプリのベースURL、CookieのSecure属性、SameSite、認証コールバックも更新します。
検証と段階切替
- 権威DNS、社内端末、VPN端末、別拠点から同じFQDNが正しいIPを返す
- IPv4/IPv6、プロキシ有無、DNSキャッシュ後も結果が一貫する
- 証明書の名前・有効期限・チェーンに警告がない
- ログイン、画面遷移、アップロード、帳票、API、メール内リンクが新URLで動く
- 旧IP URLから新URLへの案内または転送が要件どおりで循環しない
- 監視、バックアップ、WAF、アクセスログが新ホスト名を認識する
障害時とロールバック
名前解決できない場合は、端末キャッシュを無闇に全消去する前に、どのDNSサーバーへ問い合わせたか、権威応答、NXDOMAIN、VPNのDNS設定、レコードTTLを確認します。違うIPが返る場合は、重複ゾーン、条件付きフォワーダー、hostsファイル、プロキシを分けて調べます。
重大障害なら、新レコードを変更前の状態へ戻し、保存したゾーン構成とWeb設定を復元します。DNSキャッシュが残る時間を考慮し、旧IPと旧URLを保守時間中は利用可能にします。復旧後に証明書とアプリ設定も旧値へ戻ったことを確認します。利用者へはIP直打ちを恒久的な回避策として配布せず、障害窓口と復旧時刻を通知します。
CNAMEを選ぶ場合とAレコードを選ぶ場合
Webサービス名を別の正規ホスト名へ追従させたい場合はCNAMEが候補ですが、ゾーン頂点では制約があり、Kerberos、証明書、アプリのホスト名検証、メール等では別設計が必要です。AレコードはIPを直接保持するため単純ですが、IP変更時に更新箇所が増えます。ロードバランサーやクラスタの正式な名前を基準に選びます。
CNAMEを使っても、ブラウザーのURLとTLS証明書は利用者が入力した別名に対応する必要があります。DNSの別名があるだけでWebサーバーがそのHostヘッダーを受け入れるとは限りません。認証でSPNを使う場合は、重複登録を避け、サービス所有者とActive Directory管理者が検証します。
変更後の監視
DNSクエリ成功だけでなく、Webサーバーの4xx/5xx、証明書エラー、認証失敗、旧IPへの直接アクセス数を監視します。旧リンク利用者が多い場合は、部門別に案内し、ショートカット、ポータル、文書テンプレートを更新します。アクセスログには個人情報が含まれるため、保持期間と閲覧権限を定めます。
TTLを通常値へ戻した後、セカンダリDNSと各拠点で同じシリアルとレコードが返るか確認します。災害復旧サイトへ切り替える設計なら、訓練で新FQDNが代替IPへ変わり、証明書とアプリが継続することまで試します。DNSは単なる見た目変更ではなく可用性構成の一部です。
コメント