DNS構成の設計判断 — 内部・外部の名前解決をどこで分けるか

サーバーやクラウド環境が増えるにつれ、DNS構成の「判断の遅れ」が後工程に波及するケースが増えています。内外の名前解決をどこで分離するか、権威DNSとキャッシュDNSをどのサービスに担わせるか——これらの設計判断を後回しにすると、10台規模では問題が見えないまま、50台・100台規模になったときに一気に整合性の崩壊が表面化します。本記事では、構築担当者が現場で直面する選択肢を整理し、「何を選び、何を捨てるか」の基準を解説します。

DNSを場当たりで組むと後で全体が揺れる構造

問題が潜在化しやすいパターン

小規模な環境からスタートしたプロジェクトでは、初期に「/etc/hostsでとりあえず解決する」「レジストラの管理画面に直接レコードを追加する」という判断が繰り返されることがあります。台数が5台以下のうちはこれが機能しますが、環境が20台・30台と増えていくにつれ、hostsファイルの更新漏れやレジストラ管理画面への属人的なアクセスが問題になります。現場では「誰が最後にレコードを変更したか分からない」という声をよく聞きます。変更履歴がどこにも残らない構成は、担当者が交代した瞬間に負債化します。

命名規則の崩壊と影響範囲

場当たり的なDNS構成で最初に崩れるのは命名規則です。チームの担当者が変わるたびに「db01.internal」「database-prod」「prod-db-01.company.com」といった異なるフォーマットのレコードが混在し始め、サービスディスカバリが機能しなくなります。特にマイクロサービス構成では、サービス間の依存が名前ベースで連鎖しているため、命名の揺れが障害時の特定を困難にします。修正対象が30〜50レコードに及ぶと、整理作業だけで1週間以上を要したという話も珍しくありません。命名の問題は最初は小さく見えるため、「後で直せばいい」と先送りされがちです。

リファクタリングのコストが後から増大する理由

DNS構成のリファクタリングが難しい根本的な理由は、変更の影響範囲が見えにくい点にあります。あるレコードを修正した結果、それを参照していた別サービスの名前解決が失敗する——この連鎖的な影響は、構成図が整備されていなければ事前に把握できません。加えて、TTLの設定が長い場合（例: 3600秒以上）、変更が全クライアントに伝播するまでに時間がかかり、その間の動作不整合を監視で拾い続けなければなりません。設計初期に2〜3日かけて整理しておけば済む判断が、後になると数週間の作業に膨らむ構造がここにあります。

権威DNSとキャッシュDNSの役割をどこで分けるか

2種類のDNSが担う機能の違い

権威DNSはゾーンファイルを保持し、外部からの問い合わせに対して「正式な回答」を返す役割を担います。一方キャッシュDNS（フルサービスリゾルバ）は、クライアントからの問い合わせを受け取り、権威DNSへの再帰的解決を代行し、結果をTTLの間だけ保持します。この2つは機能的に独立しており、同一サーバーで動かすことも技術的には可能ですが、それぞれのトラフィックパターンと可用性要件が根本的に異なります。設計上は最初から別物として扱う判断が、後々の分離コストを下げます。

役割を混在させると起きる問題

権威とキャッシュを同一プロセスで動かす構成の典型的な落とし穴は、キャッシュポイズニングのリスク増大と、負荷の性質が異なる2種類のトラフィックを同じリソースで処理することによる応答劣化です。外部からのランダムなサブドメインクエリ（NXDOMAINフラッド）が権威DNSに届いた場合、キャッシュ機能も同時に影響を受け、内部クライアントの名前解決に遅延が生じます。この問題は小規模環境では見えにくく、外部公開トラフィックが増えた段階で初めて顕在化するため、後から分離する判断が遅れがちです。

分離する判断基準

権威とキャッシュを分離するタイミングの目安は、外部公開ドメインを持つ本番環境であれば原則として初期から分離することです。内部専用のラボ環境や開発環境であれば、管理コストを下げるために統合構成も現実的な選択肢になります。クラウド環境では、Route 53やCloud DNSのような権威DNS専用サービスと、VPC内のリゾルバ（Route 53 Resolver、Cloud DNS私有ゾーン）を組み合わせることで、この分離を比較的低コストで実現できます。「外部公開があるか否か」を最初の分岐点として判断すると、構成の整理がしやすくなります。

内部名前解決と外部公開をどう分離するかの判断

スプリットホライズンの設計思想

スプリットホライズン（split-horizon DNS）は、同じドメイン名に対して内部クライアントと外部クライアントへ異なる回答を返す設計パターンです。たとえば「api.example.com」に対して、社内VPNからの問い合わせにはプライベートIPを返し、インターネットからの問い合わせにはパブリックIPを返す構成がこれにあたります。この設計を採用する際の判断ポイントは、「同じ名前で異なる経路が本当に必要かどうか」の確認です。必要がなければ導入することで管理の複雑度だけが増すため、動機が明確でない場合は避けたほうが無難です。

内部専用ゾーンをどこに持つか

内部名前解決のゾーンをどこで管理するかは、インフラ全体のアーキテクチャに依存します。オンプレミス主体の環境ではBINDやUnboundをVM上で動かす構成が多く、クラウド主体であればRoute 53 Private Hosted ZoneやCloud DNS私有ゾーンが候補になります。ハイブリッド環境（オンプレ＋クラウド）では、どちらが「権威」を持つかを明確にしないと、ゾーンの二重管理や更新漏れが発生します。現場でよく見られる失敗パターンは、オンプレのBINDとクラウドの私有ゾーンの両方に同名レコードが存在し、更新時にどちらかが古い状態になるケースです。

境界の引き方と典型的な誤り

内外分離の境界を「どこに」引くかは、VPC・サブネット・VPN終端のどこでDNSを切り替えるかという問いに直結します。典型的な誤りは、VPN外からのトラフィックが意図せず内部リゾルバへ到達できる構成になっているケースです。フォワーダーの設定ミスや、セキュリティグループ・ファイアウォールルールでUDP/TCP 53番ポートの制限が不完全な場合に発生します。境界の定義は「どの通信経路がどのリゾルバを使うか」をネットワーク図上で明示し、DNS設定だけでなくネットワークアクセス制御と合わせて検証することが重要です。

比較表: 自前DNS / マネージドDNS / レジストラDNSの向き不向き

3つの選択肢が想定する環境規模と特性

権威DNSの実装選択肢は大きく3つに分類できます。自前DNS（BIND・PowerDNS等を自己運用）、マネージドDNS（Route 53・Cloud DNS・Cloudflare DNS等）、レジストラDNS（ドメイン購入先が提供する管理画面ベースのDNS）です。それぞれの特性と向き不向きは以下の比較表のとおりです。費用感は規模や構成によって大きく異なるため、判断材料としての傾向のみ示します。

選択肢	向いている環境・用途	向いていない環境・用途	主な管理コスト
自前DNS（BIND / PowerDNS）	オンプレ中心・完全カスタムゾーン・内部専用解決・プライバシー要件が厳しい環境	運用担当者が少ない環境（1〜2名）・外部トラフィックが多い高可用性要件	HA構成・OS / パッケージ更新・バックアップ・ゾーンファイル管理
マネージドDNS（Route 53等）	クラウド主体・外部公開ドメイン・フェイルオーバーやヘルスチェックが必要・IaC連携	完全オフライン環境・コスト最小化が最優先の小規模ラボ	API / Terraform連携設計・ゾーン間の整合管理・クエリ費用の監視
レジストラDNS	個人・小規模サイト・外部公開のみ・更新頻度が低い静的構成	自動化・IaC管理・大量レコード・フェイルオーバー・内部名前解決	管理画面の手作業・API有無の確認・機能制限の把握

ハイブリッド構成での使い分け

実際の本番環境では、単一の選択肢に統一するよりも役割ごとに使い分ける構成が多くなっています。外部公開ドメインはRoute 53やCloudflare DNSで管理し、内部名前解決はVPC内の私有ゾーンやオンプレBINDに任せるという分担です。この構成での判断ポイントは「フォワーダーの向き」です。内部リゾルバが外部ドメインをどのように解決するか、逆にクラウド内リゾルバが内部ドメインをどう扱うかを明確にしておかないと、障害時に「どこで行き詰まっているか」の切り分けに時間がかかります。

ゾーン分割とレコード管理をIaCで宣言する境界

IaCでDNSを管理することの意味

TerraformやPulumiでDNSレコードを管理することの本質的な価値は、「変更履歴がGitに残る」「レビュープロセスを通せる」「ドリフト検知ができる」の3点です。特にドリフト検知は重要で、管理画面から誰かが手動でレコードを追加した場合、次回のplan実行で差分として検出されます。DNS変更は影響範囲が広いため、PRベースのレビューとapplyを必須にすることで、意図しない変更がサービスに届くリスクを大幅に下げられます。「気づいたら増えていたレコード」を構成管理の枠組みで可視化することが、運用品質の底上げにつながります。

ゾーンをどの単位で分割するか

ゾーン分割の粒度は「変更頻度」と「責任境界」の2軸で考えます。たとえば「prod.example.com」「staging.example.com」「internal.example.com」のように環境ごとにゾーンを分けると、本番への誤ったレコード追加を権限設定で防ぎやすくなります。一方、サービス単位で細かくゾーンを分割しすぎると、フォワーダー設定が複雑になり管理コストが増大します。判断の目安として、変更頻度が週1回以上あるゾーンは独立させ、半年に1回程度の静的ゾーンは統合しておくとバランスが取れます。

GitOpsフローへの組み込みと注意点

DNS管理をGitOpsに組み込む場合、最大の注意点はstateファイルと実際のDNSの同期タイミングです。CIパイプラインでapplyを自動化すると、マージ直後に本番のDNSが書き換わります。TTLが短い場合（例: 60秒）は影響の伝播も速く、問題があればロールバックしやすい一方で、TTLが長い場合はapply後しばらく古いレコードが残り続けます。事前にTTLを短縮してからapplyし、確認後にTTLを戻すという2段階の手順を標準化しておくと、変更時のリスクを抑えられます。手順そのものはセミナー・本体リソースで補うとして、「何をどの順番で判断するか」を先に固めておくことが重要です。

TTL・フェイルオーバーをどこまで設計に織り込むか

TTLは「変更速度の設計」

TTL（Time To Live）は単なるキャッシュ保持時間ではなく、「変更をどのくらいの速さで全クライアントに届けるか」という設計上の意思決定です。TTLを3600秒（1時間）に設定すると、レコードを変更した後、最大1時間は古い情報を参照するクライアントが存在し続けます。逆にTTLを60秒に設定すると変更の伝播は速くなりますが、権威DNSへのクエリ頻度が上がり、大規模環境ではクエリコストと権威DNSの負荷が増加します。変更予定がある場合には、作業の24〜48時間前にTTLを短縮しておくという運用を設計に盛り込むことが重要です。

フェイルオーバーDNSの設計判断

フェイルオーバーをDNSで実現する場合、「ヘルスチェックの応答遅延」と「TTLによる切り替わり遅延」の2つが重なる点に注意が必要です。たとえばRoute 53のヘルスチェックが障害を検知するまでに30〜60秒かかり、そこからTTLが30秒であれば、クライアントが新しいIPへ切り替わるまでに最大90秒かかる計算になります。この遅延がサービスの可用性要件（RTO）に収まるかどうかを事前に確認し、収まらない場合はDNSフェイルオーバーではなくロードバランサーやサービスメッシュでの対応を検討する判断が必要です。

ヘルスチェックと整合性の管理

フェイルオーバー設計でよく見落とされるのは、ヘルスチェックの対象と実際のサービスエンドポイントの整合性です。ヘルスチェックがTCPの80番ポート到達性だけを見ている場合、アプリケーション層での障害（DBコネクション枯渇・ミドルウェア応答不能）を検知できません。アプリケーション側でヘルスチェック専用のエンドポイントを設け、依存サービスの状態まで確認するHTTPレスポンスを返す設計にすることで、DNS切り替えの精度が上がります。ただし深すぎるヘルスチェックはフォルスポジティブのリスクもあるため、「何を確認し、何を確認しないか」を明示した設計ドキュメントと合わせて管理することが重要です。

DNS構成チェックリスト

設計・構築の各フェーズで確認すべき観点を以下にまとめます。「すべてを一度に整備する」ためのものではなく、判断の抜け漏れを確認するための基準点として活用してください。

1. 役割分離の確認: 権威DNSとキャッシュDNS（フルサービスリゾルバ）が別プロセス・別インスタンスで動いているか。同一サーバーで兼務させている場合、その判断に設計上の根拠があるか。
2. 内外分離の設計: スプリットホライズンを採用するかどうかを意思決定として記録しているか。採用する場合、内部ゾーンと外部ゾーンのレコードが別々に管理されているか。
3. 命名規則の統一: 環境（prod / staging / dev）・役割（web / db / app）・番号の組み合わせルールが1つのドキュメントに定義されているか。既存レコードがそのルールに従っているか。
4. TTLの設計根拠: 外部公開ゾーンのTTLが「変更予定時の短縮手順」とセットで設計されているか。静的なレコードと動的に変更するレコードで異なるTTLを設定しているか。
5. IaC管理の範囲: どのゾーン・レコードがTerraform等で管理されているか。管理外のレコードが存在する場合、その理由が記録されているか。ドリフト検知の仕組みがあるか。
6. フォワーダーの経路: 内部リゾルバが外部ドメインを解決する経路、クラウド内リゾルバが内部ドメインを解決する経路がそれぞれ意図どおりに設定されているか。フォワーダーのループや循環参照がないか。
7. フェイルオーバーの遅延計算: ヘルスチェック検知時間＋TTLの合計がRTO要件に収まるか検算しているか。収まらない場合の代替手段（LB・サービスメッシュ）が設計に含まれているか。
8. 権限とアクセス制御: 本番ゾーンへの変更権限が必要最小限のロール・人数に絞られているか。レジストラ管理画面への直接アクセスを制限し、IaCを通じた変更を標準フローとしているか。
9. 変更手順の標準化: TTL短縮→apply→確認→TTL戻しのフローが文書化されているか。緊急時のロールバック手順も含まれているか。
10. 監視・アラートの設定: 権威DNSのサービス異常・応答遅延を監視しているか。NXDOMAINの急増やキャッシュヒット率の異常を検知するメトリクスが存在するか。

初期構築時点では1〜5を確認し、運用フェーズに入ってから6〜10を順次固めていく段階的な適用が現実的です。各項目の具体的な実装手順は本体リソースで補うとして、まずはこの観点で設計の抜けがないかを確認するところから始めると、後からの大規模な手戻りを防ぐ土台になります。