サブドメインは、接続先のサーバーを用意してからDNSを設定し、最後にHTTPSと公開内容を外部から確認します。DNSへrecruit.example.jpのような名前を追加するだけでは、Webサイトやメールが使える状態にはなりません。

作成時には、用途と担当者を決めておいた方が良いです。終了条件も同時に決めます。採用サービスやキャンペーンを終了したあと、接続先だけを解約してDNSが残ると、第三者に利用されるおそれがあります。作り方と廃止方法を一つの手順として管理します。

サブドメインにするか別ドメインにするかを先に決める

DNSの標準仕様では、名前空間は階層構造になっています。recruit.example.jpはexample.jpの下にあるサブドメインです。独立したWebサイトや外部サービスへ接続できますが、親ドメインと無関係な契約になるわけではありません。

会社のブランドを共通に見せ、同じドメイン契約の中で管理したい採用サイトや会員サイトなら、サブドメインを検討しやすいです。事業売却や管理組織の分離を予定し、登録者や更新責任まで独立させたい場合は、別ドメインの方が扱いやすいことがあります。

名前は短さだけで決めません。公開する業務と利用予定期間を先に決めます。担当部署と外部委託先も記録します。testやnewのように目的と終了時期が分からない名前は、数年後に削除してよいか判断しにくくなります。

DNSの前にサーバー側で受け入れ先を用意する

レンタルサーバーでは、対象のサブドメインをサイトとして追加し、公開ディレクトリやアプリケーションを割り当てます。外部サービスを使う場合は、そのサービス側へ独自ドメインを登録し、所有確認のための値を取得します。DNS事業者の画面とサーバーの画面は、役割が異なります。

接続先の準備がないままDNSを公開すると、初期画面や別サイトが表示される場合があります。エラーページだけが出ることもあります。本番情報を置く前に、サーバーがそのホスト名を受け入れることを確認します。共有サーバーでは、同じIPアドレスでもホスト名によって表示先が変わるためです。

検証環境を作る場合、検索エンジン向けのnoindexだけをアクセス制限にしません。URLを知る人は閲覧でき、設定や個人情報が見える可能性があります。パスワード認証や接続元制限など、利用者を限定する仕組みを用意します。アプリケーション側の権限も確認します。

DNSレコードは接続先の指定に合わせて選ぶ

サーバーがIPアドレスを指定するならAまたはAAAA、外部サービスが別のホスト名を指定するならCNAMEを使うのが一般的です。どの種別を使うかは、接続先サービスの公式手順を正にします。似た事例から値を推測せず、対象アカウントへ表示された名前と値を転記します。

CNAMEを設定する名前へ、ほかのレコードを同居させられないことがあります。メールや所有確認のTXTも同じ名前へ置く予定なら、接続先の仕様とDNS事業者の制約を確認します。部門へDNS管理を委ねるためNSでサブドメインを委任する方法もありますが、障害対応と変更権限が分かれるため、必要な場合だけ選びます。

ワイルドカードの*.example.jpを登録しても、任意のサブドメイン用サイトや証明書が自動で作られるわけではありません。意図しない名前も同じ接続先へ向くため、利用範囲を説明できないワイルドカードは避けた方が管理しやすいです。

SSL証明書と認証範囲は名前ごとに確認する

DNSが反映したら、サブドメインを対象にSSL/TLS証明書を発行または設定します。Let's Encryptの公式案内にあるDV証明書も、対象名の管理を確認して発行されます。親ドメインでHTTPSを使えていても、新しいサブドメインが既存証明書の対象とは限りません。

証明書の自動更新は、DNSやサーバー構成を変えたあとも成功するかを監視します。HTTPからHTTPSへの転送を設定し、証明書の名前と期限を外部回線から確認します。証明書チェーンも検査対象です。管理画面で「有効」と表示されることと、利用者のブラウザーで正しいサイトへつながることは分けて見ます。

ログインや会員情報を扱う場合は、親ドメインと共有するCookieの範囲も確認します。CORSとSSOの許可範囲も同様です。サブドメインだから自動的に安全な境界になるわけではありません。必要な名前だけを明示し、*.example.jpのような広い許可を安易に使わない方が良いです。

作成作業は公開前と公開後に分ける

設定の順序を固定すると、未完成の画面を公開したり、DNSだけが残ったりする状態を減らせます。実作業は次の流れで進めます。

  1. 用途、名前、担当者、接続先、公開日、終了条件を決める
  2. サーバーまたは外部サービスへ対象名と公開内容を用意する
  3. 変更前のDNSを保存し、公式手順どおりA・AAAA・CNAMEなどを追加する
  4. 外部DNSでレコードを確認し、サーバーが正しい内容を返すか試す
  5. SSL/TLS証明書とHTTPS転送を設定する
  6. パソコン、スマートフォン、社外回線で表示と主要機能を確認する
  7. DNS接続先、証明書、担当者、確認日を台帳へ記録する

フォームやログインがあるサイトは、画面表示だけで完了としません。送信と認証を実際に試します。通知メールとアクセス制限も確認対象です。外部サービスへ接続した場合は、契約アカウントの会社名義と解約時の手順も残します。

廃止するときは外部サービスよりDNSを先に片付ける

OWASPのサブドメイン乗っ取り対策では、廃止済みの外部資源を指すDNSが残る状態を問題にしています。第三者が同じ外部資源を取得できるサービスでは、自社サブドメインへ別の内容を表示される可能性があります。

終了時は、必要なら自社管理の案内ページへ一時的に向けます。その後、CNAMEやAなどを更新または削除し、少なくとも設定したTTLの期間を待ってから外部資源を解約します。外部サービスを先に削除し、DNSを後で片付ける順序にはしません。

台帳にはサブドメインとDNSの接続先を残します。担当者、証明書、外部契約も同じ行に記録します。公開日と終了予定が決まっていれば追記します。

まず現在のDNSから用途不明の名前を一つ選び、接続先が存在するか確認してみてください。社内の担当者が用途を答えられることも大切です。その一行を説明できる状態が、管理の出発点になります。