https://kaminashi-developer.hatenablog.jp/entry/2025/05/21/domain-and-dns-records-management

こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。インターネットの根幹を支えるドメインと DNS の仕組みが好きです。

ところで、みなさんの会社ではドメインや DNS レコード（リソースレコード）をどのように管理されていますか？カミナシでは以下のような課題を抱えていました。

運用・管理面
- 複数のレジストラでドメインが取得されていたため、異なる管理画面の操作方法や請求書の連携で手間がかかっていた
- DNS レコードのほとんどが手作業で追加され、それらのレコードが登録された経緯や目的の記録が残されていないものが多数あった。加えて、棚卸しの実施が不十分で、必要性が不明確なレコードが多数存在していた
セキュリティ面
- 一部のレジストラにおいては、きめ細やかな権限管理機能が提供されておらず、ID とパスワードを共有せざるを得ない状況であった。結果として、CTO がこれらに関する依頼を一手に引き受ける状態になっていた
- プロダクトで使っている kaminashi.com のドメインは、最初に作られた「カミナシレポート」の本番用 AWS アカウント内の Route 53 で管理されていた。「カミナシレポート」には直接的に関係のないサブドメインの操作にもこのアカウントへのアクセスが必要になってしまったり、このアカウントへのアクセス権限を持つ者がこのドメインに対してクリティカルな設定変更ができうる状態にあったりと、信頼性や可用性にリスクが存在していた

これらの課題については数年前から認識していましたが、重要性は高いが緊急性は低いためなかなか着手できずにいました（スタートアップの限られた人員では、どうしてもプロダクト開発の優先順位が高くなりがちです）。

しかし、ドメインはインターネット全盛の現代においては会社のアイデンティティそのものであり、これが適切に管理できていないことは、インターネット世界における会社の信用毀損につながりかねません。

あるべき姿

解決方針を考える前に、あるべき姿を次のように定義しました。

カミナシが保有しているすべてのドメインと DNS レコードは…

いつ、誰によってそのレコードが登録/変更されたのか、用途は何かが明示されている
用途に応じて、ドメインの管理境界が明示的に分離されており、新たに追加したいときのフローが明確になっている
誰/どのチームが各レコードに責務を持つのかが明示されている
チーム異動や離職が発生しても、適切な形で権限管理が行える
定期的な監査によって、常に有効な DNS 設定状況であることが確認できている

これをすべて満たすような解決策を検討することにしました。

解決方針

ドメイン管理専用 AWS アカウントを新設してそこに集約する

前述したように、カミナシが利用していたレジストラではきめ細やかな権限管理ができないため、あるべき姿にある適切な形で権限管理を行うことが実現できません。

カミナシでは、Google Workspace と AWS Organizations を SSO で連携させる仕組みがすでに存在しており、その仕組みに乗っかることが最も低コストで済むと判断しました。ご存じのとおり、AWS にはリソースへのアクセスを安全に管理するための IAM という強力なサービスがあります。これを組み合わせれば、適切な権限管理とライフサイクルが実現できます。

そのため、Organizations 内にドメイン管理専用の AWS アカウントを新設し、既存のドメインをすべて Route 53 に移管することにしました。また、権威ネームサーバについてもこの AWS アカウントの Route 53 に集約することにしました。

Route 53 では一部のドメイン（日本のドメインの中では汎用 JP ドメイン以外が該当します）は取得・移管することができませんが、幸いなことにカミナシが保有するアクティブなドメインはすべてサポートされていました（旧社名時代に使っていた .co.jp ドメインをまだ保有していますが、このタイミングで廃止することにしたので元のレジストラに残しています）。

なお、Route 53 のドメイン価格は国内のレジストラと比べると相対的に高いですが、あるべき姿を実現するための投資として捉えれば、メリットが上回り十分にペイすると判断しました。

DNS レコードの変更を Pull request でレビューできるようにする

手作業での管理をやめるために、ドメイン管理専用 AWS アカウントに集約するタイミングですべての DNS レコードを IaC (Infrastructure as Code) 化することにしました。コードに落とし込むことですべての変更作業を Pull request を起点に始めることができ、またそのレコードが登録された経緯や目的を Git に記録することができます。 ¹

IaC にあたっては Terraform を採用し、デプロイパイプラインは Terraform Cloud を利用しています。このあたりは社内で広く使われているものに揃えました。

Pull request テンプレートを用意することで、必要な情報が漏れなく記入されるように工夫しています。

## 📝 概要 / Summary
<!-- 追加・変更する DNS レコードの概要を記載してください -->

## 🎯 変更の目的 / Purpose
<!-- なぜこの DNS レコードが必要なのか、関連するシステムやプロジェクト、Issue などを記載してください -->

## 📅 有効期間 / Valid Until
<!-- この DNS レコードの有効期限がある場合は記載してください -->

## 🏉 担当チーム / Responsible Team
<!-- このレコードを必要とするチームを記載してください -->

## 👤 連絡先 / Point of Contact
<!-- このレコードについて社内の管理者が確認する際に連絡すべき社員名とメールアドレスを記載してください -->

## ✅ チェックリスト / Checklist

- [ ] `terraform fmt` を実行済み

## 📢 補足 / Notes
<!-- その他、レビュアーが知っておくべき情報があれば記載してください -->

また、GitHub のコードオーナーを設定することでドメインごとに誰に責務があるのかを明示し、DNS レコードの追加・変更・削除にオーナーシップを持ってもらうことを見据えています。

未使用のドメインは終活を行う

本題とは少しずれますが、未使用のドメインも過去の経緯がわからず自動更新され続けていました。これらについても、このタイミングで方針を決めました。

ドロップキャッチを防ぐために、プロダクト終了後も一定期間保有する
- 属性型 JP ドメインはドロップキャッチされる可能性がないので、旧社名時代の .co.jp は廃止する予定（.co.jp を取得するには登記が必要）
取得したけど一度も使っていないものは、自動更新せずに廃止する

安易なドメイン名の廃止はリスクを伴うので、数年をかけて廃止していくつもりです。このあたりの話は「ドメイン名の終活について」というスライドが非常に参考になりました（「終活」という言葉のチョイスは言い得て妙だなと感じました）。

マイグレーション

解決方針が決まったので、マイグレーションを進めていきます。

ドメインの移管

ドメインの移管については、基本的に手続きして待つだけです。

カミナシではレジストラのネームサーバを使っているドメインもあったため、それらについては先に Route 53 に権威ネームサーバを移行してからドメインの移管を進めました。

Route 53 は RFC に準拠したゾーンファイルをインポートすることができますが、移行元のレジストラはゾーンファイルをエクスポートすることができませんでした。そのため、以下の手順で移行することにしました。

手作業で Terraform のコードを書き起こす
apply して Route 53 のゾーンと DNS レコードを作成する
移行元と移行先の権威ネームサーバに名前解決を行い、DNS レコードの内容が一致しているかをチェックする（スクリプトを書きました）

権威ネームサーバを移行する前に NS レコードの TTL を一時的に短くしておくと移行を早く進めることができます。

カミナシには DNSSEC を有効にしているドメインがなかったので、特に気を使うステップはなく淡々と進めることができました。

プロダクトごとにゾーンを委任

カミナシではサービスチームにオーナーシップを持ってもらうことを大事にしています。そのため、各サービスチームのプロダクトが利用しているサブドメインについても、ゾーンを委任する形を取っています。

例えば、カミナシ全体の ID 管理を担う「カミナシ ID 管理」というプロダクトは、kaminashi.com ゾーンから id.kaminashi.com を委任されています。 id.kaminashi.com の権威ネームサーバはカミナシ ID 管理チームの AWS アカウント内にある Route 53 に向いています。

kaminashi.com.       172800  IN  NS  ns-320.awsdns-40.com.
kaminashi.com.      172800  IN  NS  ns-955.awsdns-55.net.
kaminashi.com.      172800  IN  NS  ns-1608.awsdns-09.co.uk.
kaminashi.com.      172800  IN  NS  ns-1396.awsdns-46.org.
;; Received 198 bytes from 192.35.51.30#53(f.gtld-servers.net) in 72 ms

id.kaminashi.com.   172800  IN  NS  ns-1329.awsdns-38.org.
id.kaminashi.com.   172800  IN  NS  ns-1807.awsdns-33.co.uk.
id.kaminashi.com.   172800  IN  NS  ns-372.awsdns-46.com.
id.kaminashi.com.   172800  IN  NS  ns-659.awsdns-18.net.
;; Received 182 bytes from 205.251.197.116#53(ns-1396.awsdns-46.org) in 9 ms

id.kaminashi.com.   60  IN  A   54.250.97.210
id.kaminashi.com.   60  IN  A   18.179.243.210
id.kaminashi.com.   60  IN  A   54.150.91.221
id.kaminashi.com.   172800  IN  NS  ns-1329.awsdns-38.org.
id.kaminashi.com.   172800  IN  NS  ns-1807.awsdns-33.co.uk.
id.kaminashi.com.   172800  IN  NS  ns-372.awsdns-46.com.
id.kaminashi.com.   172800  IN  NS  ns-659.awsdns-18.net.
;; Received 230 bytes from 205.251.199.15#53(ns-1807.awsdns-33.co.uk) in 13 ms

このように各チームが自分たちのゾーン（サブドメイン）を引き受ける設計になっているのですが、最初にリリースされた「カミナシレポート」はこの設計になっていませんでした。冒頭の文章を引用します。

プロダクトで使っている kaminashi.com のドメインは、最初に作られた「カミナシレポート」の本番用 AWS アカウント内の Route 53 で管理されていた。このアカウントへのログイン権限を持つ者はこのドメインに対してクリティカルな設定を変更できる状態にあり、信頼性や可用性にリスクが存在していた

カミナシが創業した当時は 1 つの AWS アカウント内でやりくりされていたため、kaminashi.com のゾーンがここにあるのは自然なことです。しかし、マルチプロダクトを提供する現在では「カミナシレポート」もゾーンを引き受ける形が自然です。

そこで、まずは同じアカウント内で「カミナシレポート」が使うサブドメインのゾーン分割を行なった上で、権威ネームサーバをドメイン管理専用 AWS アカウントに移行しました。

不要な DNS レコードの棚卸し

一連の移行を素早く進めるために、すでにある DNS レコードの棚卸しは後回しにしていました。ひと通りドメイン移管と権威ネームサーバの移行が完了したタイミングでこれらの棚卸しにも着手しました。

とはいえ、過去の経緯がわからないものばかりなので、

Slack や Notion を検索して過去のやり取りを探す
A レコードや CNAME レコードはブラウザからアクセスして今も使われているかどうか確認する
IP アドレスの逆引きや WHOIS の結果から利用しているサービス・ツールを推測して、関係しそうなチームに聞いて回る
業務で利用している SaaS の場合は管理画面を見せてもらって、どのレコードがどのチームで使われているかを把握する

といった地道な作業となりました。

結果的に数十個の DNS レコードを削除することができました。放置すればサブドメインの乗っ取り（いわゆる Subdomain Takeover）などの事故も起きかねない状況だったので、手間をかけてでも棚卸しした甲斐はありました。

社内での依頼フローの整備

最後に社内での依頼フローを整備しました。

エンジニアであれば上記で整備した GitHub リポジトリに Pull request を作ってもらえればいいのですが、エンジニア以外の方にそれをお願いするのは難しいです。そこで、Corporate IT に窓口になってもらい、作業内容のヒアリングから Pull request の作成を担ってもらうことにしました。こうすることで CTO 個人への依頼をチームで受け取れるようにしつつ、経緯や目的をしっかりと残せるようになります。

Corporate IT への依頼方法についてはすでに Slack ワークフローを使った仕組みが確立されているので、そこに乗っかる形で実現しました。

まとめ

ドメインや DNS の管理は普段あまり意識されない部分ですが、企業やプロダクトにとっては信用を左右する非常に重要な基盤です。これまで属人化や手作業に頼った運用が続いていたことで、セキュリティリスクやメンテナンスの難しさが表面化していました。

今回、専用の AWS アカウントを設けてすべてのドメインを集約し、Terraform によるコード管理を導入することで、安全性と運用の透明性を大きく改善することができました。

まだ完璧とは言えませんが、今後もフィードバックをもらいながら継続的に改善を重ねていきたいと思います。

カミナシでは、同じような背景から GitHub の権限管理は Terraform でコード管理を行なっています。詳しくは「Terraform で実現する効率的な GitHub 権限管理」をご覧ください。↩