■背景
- 前提知識
OCI VCNのプライベートリゾルバはVCN内のコンピュートなどからのDNS問い合わせを処理します。
hub VCNのリゾルバから別テナンシのspoke VCNが持っているプライベートビューを参照することができます。
参考Blog:https://blogs.oracle.com/ateam/post/oci-private-dns-cross-tenancy-private-views
- ユースケース
基本的にはDNS問い合わせをフォワーディングすることが推奨です。
しかしながら、多数のVCNがある場合やネットワーク構成が複雑になる場合、ピアリングやフォワーディングルールが膨大になり、運用面でネックになる場合があります。特にSaaS環境を提供するベンダーやISVの管理面でネックになる可能性があります。
1つのVCNリゾルバが複数のプライベートビューを参照できることで運用面でのメリットがある場合、このケースを参考にしてみてください。
■構成

・hubテナンシのhub VCNとspokeテナンシのspoke VCNがあります。
・hub VCNのインスタンスから、spoke VCNインスタンスの名前解決をしたい。(薄緑)
・hub VCNのプライベートリゾルバがspoke VCNにあるプライベートビューを参照します。(紺色)
・hubインスタンスがDNS問い合わせをしてリゾルバが別テナンシのプライベートビューを参照して名前解決を行います。(水色)
後々、OCIDが必要になるので以下の情報をメモしておく
- hubテナンシ
- hub グループ
- hub VCNリゾルバ
- spokeテナンシ
- spokeプライベートビュー
ポリシー設定
テナンシ間のリソースを扱う場合はポリシーの設定にお互いのリソースを扱う権限を記載する必要があります。
注意
・endoseポリシーなどのクロステナンシ・ステートメントはルートコンパートメントにしか記載できない
・今回はAdministoratorグループで検証
・今回はデフォルトドメインで検証
```
Define tenancy VIEW-TENANCY as ocid1.tenancy.oc1..<unique_spoketenancy_ID>
allow group Administrators to use dns-resolver in tenancy
endorse group Administrators to inspect dns-views in tenancy VIEW-TENANCY
endorse group Administrators to associate dns-views in tenancy VIEW-TENANCY with dns-resolver in tenancy
```
```
Define tenancy VCNTenancy as ocid1.tenancy.oc1..<unique_hubtenancy_ID>
Define group VCNTenancyAdmins as ocid1.group.oc1..<unique_hubgroup_ID>
admit group VCNTenancyAdmins of tenancy VCNTenancy to inspect dns-views in tenancy
admit group VCNTenancyAdmins of tenancy VCNTenancy to associate dns-resolver in tenancy VCNTenancy with dns-views in tenancy
```
■CLIでhub VCNリゾルバにspokeのプライベートビューを紐づける
- まずはOCIDを確認
・hub プライベートリゾルバ
・spoke プライベートビュー
hub側のクラウドシェルを使います。
oci dns resolver get --resolver-id ocid1.dnsresolver.oc1.ap-tokyo-1.<unique_hub_resolver>
{
"data": {
"-self": "https://dns.ap-tokyo-1.oci.oraclecloud.com/20180115/resolvers/ocid1.dnsresolver.oc1.ap-tokyo-1.<unique>",
"attached-vcn-id": "ocid1.vcn.oc1.ap-tokyo-1.<unique> ",
"attached-views": [], ★空であることを確認
"compartment-id": "ocid1.tenancy.oc1..<unique>",
"default-view-id": "ocid1.dnsview.oc1.ap-tokyo-1.<unique>",
"defined-tags": {
"Oracle-Tags": {
"CreatedBy": "default/<unique>",
"CreatedOn": "2025-09-07T14:54:11.459Z"
}
},
"display-name": "HUB_VCN",
"endpoints": [],
"freeform-tags": {
"undefined": "2025-09-07T14:53:52.144Z"
},
"id": "ocid1.dnsresolver.oc1.ap-tokyo-1.<unique>",
"is-protected": true,
"lifecycle-state": "ACTIVE",
"rules": [],
"time-created": "2025-09-07T14:54:12.738000+00:00",
"time-updated": "2025-09-07T14:54:12.738000+00:00"
},
"etag": "\"1#application/json--gzip\""
}
oci dns resolver update --resolver-id ocid1.dnsresolver.oc1.ap-tokyo-1.<unique_hub_resolver> --attached-views '[{"viewId": "ocid1.dnsview.oc1.ap-tokyo-1.<unique_spoke_privateview> "}]'
WARNING: Updates to freeform-tags and defined-tags and attached-views and rules will replace any existing values. Are you sure you want to continue? [y/N]: y
しばらく経って更新されているかを確認
oci dns resolver get --resolver-id ocid1.dnsresolver.oc1.ap-tokyo-1.amaaaaaatgpiivia6mdmrbucwf7ab3dxv5ppjrdfu4nqif77x4thnnjfsedq
{
"data": {
・・・
"attached-vcn-id": "ocid1.vcn.oc1.ap-tokyo-1.amaaaaaatgpiiviayxnqgmcku3nzger75cdqo5xs4jma47arlnhdw7jit3za",
"attached-views": [
{
"view-id": "ocid1.dnsview.oc1.ap-tokyo-1.<unique_spoke_privateview> " ★紐づけされてた
}
・・・
■検証
hub VCNのインスタンスからspokeテナンシのspoke VCNインスタンスに対する名前解決を行います。
・自分のIPアドレス確認
[opc@hub-ins ~]$ ifconfig
ens3: flags=4163 UP,BROADCAST,RUNNING,MULTICAST mtu 9000
inet 10.0.0.155 netmask 255.255.255.0 broadcast 10.0.0.255
・nslookupで名前解決をしてみる
[opc@hub-ins ~]$ nslookup spoke-ins.sub09071458490.spokevcn.oraclevcn.com
Server: 169.254.169.254
Address: 169.254.169.254#53
Non-authoritative answer:
Name: spoke-ins.sub09071458490.spokevcn.oraclevcn.com
Address: 192.168.0.173
名前解決できました。
※ピアリングをしていないので実際に通信を行う際にはDRGなどでピアリングが必要です。
hubリゾルバの関連付けられたプライベートビューを見ると、spokeプライベートビューのOCIDがあり、関連付けられていることが確認できます。



