この記事はBen WoltzによるCustom DNS for Oracle AI Database@Azureを日本語に翻訳したものです。
2026年05月05日
お客様は、さまざまなOracle AI Database@Azureデプロイメントにおいて、Domain Name System（DNS）に関する複数の選択肢を利用できます。このブログでは、お客様がカスタムDNSを使用するためのオプションを確認し、よくあるシナリオと関連するアーキテクチャについて説明します。
カスタムDNSの説明
Oracle AI Database@AzureのカスタムDNSの詳細に入る前に、まずデフォルトDNSオプションを理解する必要があります。これは完全管理DNSと呼ばれることもあります。
デフォルトDNS（完全管理）
デフォルトDNSオプションでは、プロビジョニングされるリソースはoraclevcn.com DNSドメインを使用し、Oracleによって完全に管理されます。このオプションでは、デプロイメント用にOracle DNSとAzure Private DNSの両方にDNSゾーンが作成されます。リソースの「A」レコードはOracle DNSゾーンに作成され、それらはAzure Private DNSゾーンにも「A」レコードとして自動的にレプリケートされます。デフォルトDNSオプションは、Exadata Database、Autonomous AI Database、Exascale Database、およびBase Databaseサービスで利用できます。
カスタムDNS
リソースにデフォルトのoraclevcn.comドメインを使用したくないお客様向けに、カスタムDNSオプションがあります。カスタムDNSでは、お客様はリソースに使用する任意のドメイン名、たとえばoradbazure.customer.comなどを指定できます。カスタムDNSオプションを使用する場合、お客様はVirtual Machine（VM）クラスタをデプロイする前に、OCI DNSでカスタム・ドメイン用のプライベート・ビューとプライベート・ゾーンを作成する必要があります。OCI DNSでプライベート・ビューとプライベート・ゾーンの作成が完了すると、AzureコンソールでVMクラスタをプロビジョニングする際に、「Use custom DNS」ドロップダウン・ボックスの選択肢として表示されるようになります。VMクラスタのプロビジョニング・プロセスでそれを選択すると、リソースの「A」レコードがOracle DNS内のカスタム・ゾーンに自動的に作成されます。カスタムDNSでは、デフォルトDNSのように、それらの「A」レコードがAzure Private DNS内のゾーンに自動的にレプリケートされることはありません。お客様は、それらのレコードをAzure Private DNSに手動で作成またはレプリケートするか、以下で説明するようにNetwork Anchorを使用した一元化DNSハブによりDNSフォワーディングとリスニングを設定する必要があります。カスタムDNSオプションは、Exadata Databaseサービスでのみ利用できます。
カスタムDNSの制限事項
- Exadataホスト名プレフィックスは最大23文字です。英字で始まる必要があり、使用できるのは英数字とハイフンのみで、localhostは使用できません。
- Exadataクラスタ名は最大11文字です。英字で始まる必要があり、使用できるのは英字、数字、ハイフンのみです。
- ExadataのホストおよびドメインURLは、ホスト名プレフィックスとドメイン名を合わせて最大112文字です。ドメイン名ではハイフンはサポートされません。
- カスタム・ドメインは、ホスト名を含めずに最大4つのドメイン階層までです。例: <subdomain2>.<subdomain1>.<domain>.<com>
シナリオ #1 – カスタムDNSを使用する単一のExadata VMクラスタ
以下の図は、単一のExadataインフラストラクチャとVMクラスタのみを使用し、カスタムDNSドメインとしてoradbazure.customer.comを使用する非常に基本的なシナリオを示しています。通常、この構成はお客様がProof of Concept（POC）を行う際によく見られます。
これを実現するための大まかな手順は以下のとおりです。詳細については、カスタムDNSドキュメントを参照してください。
- OCI DNSで
oradbazure.customer.com用のプライベート・ビューとプライベート・ゾーンを作成します。 - AzureポータルでVMクラスタをプロビジョニングし、「Use custom DNS」ボックスを選択した後、ステップ1で作成したプライベート・ビューを選択します。
インバウンドDNS（OCI -> Azure）
このシナリオではDNSフォワーディング・エンドポイントやリスニング・エンドポイントを使用しないため、お客様は、VMクラスタが名前解決する必要のある各Fully Qualified Domain Name（FQDN）について、OCI DNSに新しいプライベート・ゾーンと関連する「A」レコードを作成する必要があります。このプライベート・ゾーンは、上記ステップ1でoradbazure.customer.com用に作成したものと同じプライベート・ビュー内に作成できます。たとえば、お客様はcustomer.com用のプライベート・ゾーンを作成し、<host_1>.customer.com、<host_2>.customer.comなどの「A」レコードを作成することで、VMクラスタがそれらのFQDNを解決できるようにします。
アウトバウンドDNS（Azure -> OCI）
VMクラスタがプロビジョニングされると、そのデプロイメント用のDNS「A」レコードが、OCI DNS内のoradbazure.customer.comプライベート・ゾーンに自動的に作成されます。お客様がオンプレミスまたはAzure DNSからそれらのFQDNを解決できるようにするには、それらの「A」レコードをAzure Private DNSまたはオンプレミスDNSサーバーに手動で作成またはレプリケートする必要があります。
シナリオ #2 – Network AnchorをDNSハブとして使用する、カスタムDNSの複数Database@Azure環境
以下の図は、Database@Azure向けのよりスケーラブルで堅牢なカスタムDNSソリューションを示しています。
OCIコンポーネント
- 本番用と非本番用の2つのExadata環境。それぞれが独自のVirtual Cloud Network（VCN）内に存在します。
- 各環境用のOCI DNSのカスタム・プライベート・ビューとプライベート・ゾーン
- Network Anchorを使用した、DNSリスナーおよびフォワーディング・エンドポイントを備える一元化DNSハブVCN
- 2つのExadata VCNを中央DNSハブVCNにピアリングするためのLocal Peering Gateway（LPG）
- Exadata VCN内のDNSフォワーディング・エンドポイント
- VCNルート表
- DNSフォワーディング・エンドポイント用のNetwork Security Group（NSG）
Azureコンポーネント
- 本番用と非本番用の2つのExadata VNet。それぞれに委任サブネットがあります。
- Network Anchorを使用するDNSハブ用の委任サブネットを持つVNet
- Azure Private DNSのフォワーディング・エンドポイントおよびリスニング・エンドポイント
Network Anchor
このソリューションでは、Oracle Database@Azure製品内のNetwork Anchor機能を活用します。Network Anchorは、AzureとOCIの間のネットワーキング・ブリッジであり、さらにお客様がDNSフォワーディング・エンドポイントおよびリスニング・エンドポイントを使用して、双方向のDNS解決をシームレスに有効化するためのオプションも提供します。
Network Anchorは、Autonomous Database@AzureまたはExadata Database@Azure用にプロビジョニングされるVCNおよび委任サブネット付きVNetではサポートされていません。そのため、お客様はそれらのVCN内にDNSフォワーディング・エンドポイントおよびリスニング・エンドポイントを直接作成できません。AutonomousおよびExadataのお客様がDNSエンドポイントでNetwork Anchorを利用するには、エンドポイント用の一元化DNSハブとして使用するために、委任サブネットを持つ別のVNetをプロビジョニングする必要があります。
LPG
LPGは、VCN間のトラフィックをルーティングするために1対1のピアリングを提供するOracle VCNピアリング・ゲートウェイです。この設計では、インバウンドDNS（OCI -> Azure）解決を可能にするためにLPGが必要です。OCIで稼働するデータベース・インスタンスからAzure宛てに発信されるトラフィックでは、Azure DNS名の名前解決が必要になります。このVCNはExadata Database@Azure用であるため、Network AnchorおよびDNSクエリをAzure Private DNSへ直接フォワードする機能はサポートされていません。その代わりに、それらのDNSクエリを一元化ハブVCN内のDNSリスナーに転送する必要があり、Exadata VCNと一元化DNSハブVCNの間にLPGピアリングが必要になります。LPGは1対1のピアリングであるため、このシナリオでは、本番VCNとDNSハブVCNの間にLPGのペアが必要であり、非本番VCNとDNSハブVCNの間にも別のLPGのペアが必要です。
インバウンドDNS（OCI -> Azure）
データベース・インスタンスがAzure内のFQDN宛てにトラフィックを開始する必要がある場合、Exadata VCNには、AzureドメインをDNSハブVCN内のDNSリスナーに向けるフォワーディング・ルールを持つフォワーディング・エンドポイントが必要です。このシナリオでは、Exadata VCN内のフォワーディング・ルールは*.customer.com forward to 10.44.0.175になります。同様に、DNSハブVCNにも、AzureドメインをAzureネットワーク内のDNSリスナーへ向けるフォワーディング・ルールを持つフォワーディング・エンドポイントが必要です。このシナリオでは、DNSハブVCN内のフォワーディング・ルールは*.customer.com forward to 10.45.2.10.になります。DNSハブVCNはNetwork Anchor VCNであるため、DNSフォワーディング・エンドポイントはAzure VNet委任サブネット内のNICにリンクされ、クエリが名前解決のためにAzureネットワークへ到達できるようになります。
アウトバウンドDNS（Azure -> OCI）
Azure内のリソースがデータベース・インスタンスのFQDN宛てにトラフィックを開始する必要がある場合、DNSハブVCNにはリスニング・エンドポイントが必要です。Azure DNSサーバーには、*.prod.oradbazure.customer.com および *nonprod.oradbazure.customer.com forwarding to 10.44.0.175 のフォワーディング・ルールが必要になります。デフォルトでは、DNSハブVCN内のDNSリゾルバは、自身のDNSプライベート・ビューとプライベート・ゾーンについてしか認識しません。DNSハブVCN内のDNSリスナーが*.prod.oradbazure.customer.com および *nonprod.oradbazure.customer.comのクエリを正常に解決できるようにするには、お客様は本番および非本番のプライベート・ビューをDNSハブVCNリゾルバにアタッチする必要があります。