もうDNS障害は起こさない。Pull RequestベースでDNS管理を安全にした話
はじめに：そのDNS変更、本当に安全ですか？
DNSレコードの変更作業、ヒヤヒヤしませんか？
「タイポ一つでサービスが止まる...」
「誰がいつ何を変更したのかわからない...」
「レビューなしで本番反映するの、怖い...」
そんな恐怖と隣り合わせのDNS運用をしていた私たちが、GitHubとYAMLだけで安全・透明・チーム全員が安心して変更できるDNS管理を実現した方法をお伝えします。
この記事でわかること
- 手動DNS管理の課題と、それがもたらすリスク
- Pull Requestベースでレビュー可能なDNS管理の実現方法
- 実際のリポジトリ構成、YAML定義、ワークフロー
- GitOps化で得られた5つの具体的なメリット
最初は大変そうに思えるかもしれませんが、特別なツールは不要。YAMLとGitHubだけで、今日から始められます。
悪夢のような手動管理時代：私たちが抱えていた4つの課題
課題1：変更履歴が追えない恐怖
お名前.comやRoute53の管理画面で直接DNS設定を変更していた過去。
「いつの間にかこのCNAMEレコード、変わってる...？」
誰が、いつ、なぜ変更したのか。その記録は一切残りません。
障害が発生しても、原因究明に時間がかかり、ロールバックも困難でした。
課題2：属人化とブラックボックス化
「このDNSレコード、なんで設定されてるんだっけ？」
「あの人に聞かないとわからない...」
DNS設定が特定の人の頭の中だけに存在している状態。
その人が休みだったり退職したりすると、誰も触れない聖域になってしまいます。
課題3：レビュー不在の恐怖
コードレビューは当たり前なのに、なぜかDNS変更はレビューなし。
タイポ一つ、ピリオド1つ忘れるだけでサービス全体が停止する可能性があるのに...
「本番反映ボタン」を押す瞬間の、あの緊張感。
誰もが経験したことがあるのではないでしょうか。
課題4：手作業によるヒューマンエラー
- コピペミスでIPアドレスを間違える
- TTLの単位を勘違いして86400秒（1日）のつもりが86400分に
- 本番用のレコードを削除するつもりが開発用を削除
- DKIMの長い文字列を途中で切れてしまう
手作業である以上、ミスは避けられません。
そして、そのミスは即座にサービス障害につながります。
目指した世界：Pull Requestが、私たちのDNS管理を救う
これらの課題を一気に解決する方法。それがGitOpsベースのDNS管理でした。
なぜGitOpsだったのか
開発者にとって、GitとPull Requestは日常の一部。
この馴染みのあるワークフローをDNS管理にも適用することで：
- 全ての変更がレビューされる - マージ前に必ず誰かがチェック
- 変更履歴が完全に追跡可能 - git logとgit blameで全てがわかる
- ドキュメントが自動的に最新 - YAMLファイルそのものが仕様書
- ロールバックが簡単 - git revertで即座に前の状態に戻せる
-
チーム全体で可視化 - 誰でも現在の設定を確認可能
「すべての変更がレビューされ、承認されたものだけが反映される世界」
これが私たちの目指した理想でした。
3ステップで実現！GitOps化への道のり
実際の実装を、ステップバイステップで解説します。
ステップ1：リポジトリの設計とYAMLの定義
ディレクトリ構造
まずは、シンプルな構造から始めました：
```
dns-management/
├── README.md # 運用ルールとワークフロー
├── zones/ # ドメインごとのDNS定義ファイル
│ └── 「ドメイン」.yaml
├── templates/ # 変更依頼用テンプレート
│ └── change-request.md
├── scripts/ # DNS検証スクリプト
│ └── verify_dns.sh
└── .github/ # GitHub設定ファイル
├── PULL_REQUEST_TEMPLATE.md
└── CODEOWNERS
```
重要なのは、シンプルに保つこと。
複雑な構造は採用の妨げになります。
実際のPull Requestワークフロー
-
ブランチ作成:
git checkout -b dns/add-new-service -
YAML編集:
zones/「ドメイン名」.yamlに新しいレコードを追加 -
コミット:
git commit -m "feat(dns): Add DNS records for new service" - PR作成: テンプレートに従って詳細を記載
- レビュー: インフラチームが内容を確認、フィードバック
- 承認: 問題なければApprove
- マージ: mainブランチへ統合
- 適用: インフラチームが実際のDNSサーバーへ反映
重要: マージ = 即座にDNS反映、ではありません。
YAMLファイルは「あるべき姿」を定義するもの。
実際の適用は、インフラチームが計画的に実施します。
メリット2：チーム全体の可視性向上
新メンバーが参加しても、READMEとYAMLファイルを読めば、
現在のDNS構成を完全に理解できます。
「あの人しか知らない」状態から、**「GitHubを見ればわかる」**状態へ。
属人化が完全に解消されました。
メリット3：レビューによる品質担保
実際にあったレビューでの指摘：
- 「このTTL、短すぎませんか？トラフィック増加が心配です」
- 「DKIMレコード、末尾の
;が抜けてますよ」 - 「このCNAME、本当にVercelのドメインで合ってますか？」
Pull Requestのディスカッションで、変更前に問題を発見。
マージ後の障害がゼロになりました。
さらに嬉しい変化として、DNS変更がチームのポジティブな活動になりました。
今では、新しいサービスのDNSレコード追加は、インフラチームと開発チームが
協力して進める楽しいイベントの一つです。PRでの建設的なディスカッションを通じて、
お互いの知識を共有し、チーム全体のスキルアップにつながっています。
メリット4：自動的なドキュメント化
以前は「DNS設定書」をExcelで管理していましたが、
更新を忘れて実際の設定と乖離していました。
GitOps化後は、YAMLファイルそのものが最新のドキュメント。
しかも各レコードにコメントがあるので、意図も明確です。
メリット5：インフラ as Code の実現
DNS設定もコードとして扱えるようになったことで、
開発チーム全体に「Infrastructure as Code」の文化が浸透しました。
次のステップとして、Terraform管理への移行も視野に入っています。
導入のハードルを下げる3つのコツ
コツ1：スモールスタートで始める
最初から全ドメインを移行する必要はありません。
-
まずは1つのサブドメインから -
dev.example.comなど影響範囲が小さいもの - チームで試してみる - 実際にPRを出して、レビューのフローを体験
- 問題なければ徐々に拡大 - 本番ドメインへと段階的に移行
私たちも、最初は開発環境のDNSだけをYAML化し、
3週間運用してから本番ドメインに適用しました。
コツ2：テンプレートはコピペOKに
この記事で紹介したYAML構造、PRテンプレート、CODEOWNERSは、
そのままコピー＆ペーストして使えます。
最初は完璧を目指さず、「まず動かす」ことを優先しましょう。
運用しながら改善していけばOKです。
コツ3：便利なツールを活用する
YAML編集を快適にするツールを紹介します：
構文チェック：
```bash
yamllint - YAMLの構文とスタイルをチェック
pip install yamllint
yamllint zones/[ドメイン名].yaml
```
整形ツール：
```bash
Prettier - YAML（とJSON、Markdown）の自動整形
npm install -g prettier
prettier --write zones/*.yaml
```
エディタプラグイン：
- VS Code: YAML Extension（Red Hat製）
- IntelliJ: 標準でYAMLサポート
- Vim: vim-yaml
これらのツールにより、インデントミスや構文エラーを書いている最中に検出できます。
こうした小さな失敗とその解決を、チーム内で共有することで、
次に同じ問題に遭遇する人の時間を節約できます。
まとめ：DNS変更の恐怖よ、さようなら
DNS管理のGitOps化は、決して難しくありません。
必要なもの：
- GitHubアカウント（GitLabでもOK）
- YAMLの基本的な知識
- チームの合意
不要なもの：
- 高価な専用ツール
- 複雑なCI/CDパイプライン（最初は）
- 膨大な初期工数
最初は大変そうに思えるかもしれませんが、
実際に始めてみると、1日で基本的な仕組みは構築できます。
そして一度GitOps化すれば：
- DNS変更のたびにヒヤヒヤすることがなくなる
- 「誰が変更したか」で揉めることがなくなる
- 新メンバーでも安心してDNS変更ができる
- 障害時の原因究明が劇的に早くなる
- チーム全体のインフラ理解度が向上する
この記事が、あなたのチームのDNS管理を改善する一歩となれば幸いです。
Discussion