OCI DNS Private Views (Private DNS)

解決する課題

• VCN 内のインスタンスやサービスを内部名（FQDN）で参照したいが、自前 DNS サーバーは運用したくない
• 内部ホスト名やプライベート IP をパブリック DNS に晒さず、VCN の中だけで解決したい
• オンプレミスの DNS や別 VCN の名前を、VCN 内のホストから条件付きで転送解決したい（ハイブリッド DNS）
• マルチ VCN 構成で、同じドメイン名を VCN ごとに別の宛先へ解決させたい

主要概念と用語

• プライベート DNS: VCN 内だけで完結する名前解決の仕組み。リゾルバ・ビュー・プライベートゾーン・エンドポイントで構成する
• リゾルバ（Resolver）: VCN に紐づく名前解決の中核。VCN を作成すると既定のプライベートリゾルバが自動で用意される。アタッチしたビューと転送ルールに従って応答する
• ビュー（Private View）: プライベートゾーンをまとめる入れ物。リゾルバにアタッチして名前解決のスコープを決める。VCN 作成時に既定ビューが1つ用意される
• プライベートゾーン（Private Zone）: ビューの中に置く権威ゾーン。A／AAAA／CNAME／TXT などのレコードを持ち、ビューにアタッチされたリゾルバからのみ解決される
• リスニング エンドポイント（Listening Endpoint）: オンプレや他 VCN からの問い合わせを受ける入口。リゾルバ内にプライベート IP を持つ
• フォワーディング エンドポイント（Forwarding Endpoint）: 外部 DNS（オンプレや別 VCN）へ問い合わせを送り出す出口
• 転送ルール（Forwarding Rule）: 「このドメイン宛は、この宛先 IP へ転送する」という条件付きフォワーディングの定義
• 解決順序: リゾルバはまずアタッチされたビューのプライベートゾーンを見て、なければ転送ルール、最後にインターネット権威 DNS（パブリック解決）へ進む

仕様・制限・クォータ

• リゾルバは VCN ごとに存在し、VCN 作成時に既定リゾルバと既定ビューが自動作成される
• 1つのリゾルバには複数のビューをアタッチでき、上から順に評価される。ビューの並び順が解決結果に影響する
• ビューとプライベートゾーンはリージョンリソース。パブリックの権威 DNS がグローバル Anycast なのに対し、プライベート解決はリージョン＋ VCN スコープに閉じる
• 同名のプライベートゾーンを別々のビューに置けるため、VCN ごとに同じ FQDN を別の値へ解決できる（スプリットホライズン）
• エンドポイント（リスニング／フォワーディング）はリゾルバ内のサブネットにプライベート IP を確保する。1リゾルバあたりのエンドポイント数などはサービス制限の枠内
• 転送先 DNS との疎通には、対象サブネットのセキュリティリスト／NSG で 53番ポート（UDP/TCP）を許可する必要がある
• リソースは IAM ポリシーとコンパートメントで権限分割する

内部の仕組み

VCN を作ると、その VCN 用のプライベートリゾルバと既定ビューが自動で立ち上がります。インスタンスからの DNS 問い合わせはこのリゾルバが受け取り、次の順で解決します。

• まず、リゾルバにアタッチされたビュー内のプライベートゾーンを照合する（内部名はここで解決）
• 一致するゾーンがなければ、転送ルールに従い該当ドメインを外部 DNS（オンプレ／別 VCN）へ条件付き転送する
• どれにも当てはまらなければ、インターネットの権威 DNS へ再帰的に解決する

ビューはプライベートゾーンの集合にすぎませんが、これが設計上の鍵になります。あるビューにだけ internal.example.com ゾーンを置けば、そのビューをアタッチした VCN からだけ内部名が見え、他からは見えません。さらに、同じゾーン名を別のビューに別の値で置くことで、同一 FQDN を VCN ごとに違う宛先へ解決させる「スプリットホライズン DNS」が実現できます。

オンプレや他 VCN との連携は2種類のエンドポイントで成立します。リスニング エンドポイントは外から来る問い合わせを受ける入口、フォワーディング エンドポイントは外へ問い合わせを送り出す出口です。たとえばオンプレの社内ドメインだけをオンプレ DNS へ転送ルールで送り、それ以外は OCI 側で解決する、といったハイブリッド構成を組めます。

設計パターン / ベストプラクティス

• 内部名はプライベートゾーンに集約し、パブリックゾーンには絶対に置かない（内部構成の漏洩防止）
• スプリットホライズン: 本番・検証など環境ごとに別ビューを用意し、同じ FQDN を各 VCN で適切な宛先へ解決させる
• ハイブリッド DNS: オンプレ社内ドメインは転送ルールでオンプレ DNS へ、OCI 内部名はプライベートゾーンで、とドメインごとに経路を分ける
• ハブ＆スポーク: 共有サービス VCN（ハブ）にリスニング エンドポイントを置き、各スポーク VCN からの問い合わせを集約する設計と相性が良い
• ビューの評価順序を意識し、想定外のゾーンが先に一致しないようアタッチ順を管理する
• 転送先との経路は **DRG／ローカルピアリング（LPG）**などで確保し、53番ポートを NSG で最小許可する

運用・監視

• 切り分け順: 解決したいゾーンが対象ビューにあるか → そのビューがリゾルバにアタッチされ評価順は妥当か → 転送ルールの宛先と条件 → エンドポイント経路と 53番ポートの許可 → 最後にパブリック解決
• 名前解決の確認は VCN 内のホストから dig / nslookup を実行し、期待どおりのビューのレコードが返るかを検証する
• 転送が効かない場合は、フォワーディング エンドポイント側サブネットのルートと NSG／セキュリティリスト、および転送先 DNS の応答可否を確認する
• 操作・変更は Audit（監査ログ） で追跡し、ゾーンやビューの変更履歴を可視化する
• TTL を意識し、切り替え前は短めにしておくとキャッシュ起因の遅延を抑えられる

コスト

プライベート DNS の課金軸は、解決クエリ規模とエンドポイントに整理できます。具体的な単価は変動するため、ここでは考え方を示します。

セキュリティ

• 内部名の非公開: プライベートゾーンに置いた名前はビューをアタッチした VCN からしか解決されず、インターネットから見えない
• 最小公開の徹底: 内部ホスト名やプライベート IP をパブリックゾーンに登録しない。内部構成は DNS から推測できる攻撃の足がかりになる
• 経路の最小許可: リスニング／フォワーディング エンドポイントのサブネットでは、53番ポートを必要な相手にだけ NSG で許可する
• 権限分割: ビュー・ゾーン・リゾルバの変更権限を IAM ポリシーとコンパートメントで最小化する

関連サービス・比較

プライベート DNS は OCI DNS の一機能であり、外向きの権威 DNS とは責任範囲が分かれます。ここでは AWS の相当機能と対応づけます。

ハンズオン / CLI例

# VCN に紐づく既定リゾルバを確認（リゾルバ OCID を控える）
oci dns resolver list \
  --compartment-id ocid1.compartment.oc1..xxxx

# プライベートビューを作成
oci dns view create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name internal-view

# プライベートゾーンを作成し、上で作ったビューに所属させる
oci dns zone create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --name internal.example.com \
  --zone-type PRIMARY \
  --scope PRIVATE \
  --view-id ocid1.dnsview.oc1..xxxx

# 内部ホストの A レコードを投入
oci dns record rrset update \
  --zone-name-or-id internal.example.com \
  --domain app.internal.example.com \
  --rtype A \
  --scope PRIVATE \
  --view-id ocid1.dnsview.oc1..xxxx \
  --items '[{"domain":"app.internal.example.com","rtype":"A","rdata":"10.0.1.20","ttl":300}]'

# 作成したビューをリゾルバにアタッチ（評価対象に含める）
oci dns resolver update \
  --resolver-id ocid1.dnsresolver.oc1..xxxx \
  --attached-views '[{"viewId":"ocid1.dnsview.oc1..xxxx"}]'