OCIデータベース・ホストでのAutonomous Recovery Serviceでのdnsmasq Split-DNSの使用 (2026/04/03)

OCIデータベース・ホストでのAutonomous Recovery Serviceでのdnsmasq Split-DNSの使用 (2026/04/03)

https://www.ateam-oracle.com/using-dnsmasq-split-dns-for-autonomous-recovery-service-on-oci-database-hosts

投稿者： Marius Radulescu | Principal Cloud Solution Architect

Diego Losi | Master Principal Account Cloud Engineer - Database Platform formerly DBA in Oracle Consulting

Bryan Grenn | Database, Infrastructure & Cloud Solutions Architect

推奨されるOCIプライベートDNSエンドポイントアーキテクチャを採用できない場合の、実用的なホストローカルフォールバックパターン

はじめに

ハイブリッドおよびエンタープライズDNS統合の場合、Oracleは一般的に、OCIプライベートDNSをリスニングエンドポイント、フォワーディングエンドポイント、およびリゾルバルールと組み合わせて使用​​することを推奨しています。これにより、OCI VCNネイティブDNS解決がエンタープライズDNSサービスおよびオンプレミスリゾルバと円滑に相互運用できるようになります。このモデルでは、OCIはOCIネイティブおよびVCNローカルDNSの権威パスとして機能し、エンタープライズDNSシステムは明示的に定義されたリゾルバエンドポイントとフォワーディングポリシーを介してOCIとクエリを交換できます。

これらの推奨される展開パターンに関する有用な参考資料として、A-Teamの記事「OCIプライベートDNS – 一般的なシナリオ」があります。この記事では、一般的なOCIプライベートDNS統合モデルの概要を示し、ハイブリッドDNSトポロジにおけるリスニングエンドポイント、フォワーディングエンドポイント、およびリゾルバルールの役割を解説しています。OCIへのエンタープライズDNS接続を設計するお客様にとって、この記事は推奨される出発点となります。

しかし、すべての環境でこの推奨アーキテクチャをすぐに採用できるとは限りません。特に、DNSの動作がホストレベルのオペレーティングシステム構成と密接に結びついている場合や、データベースシステムが既にOS上で直接顧客管理のリゾルバに依存している場合など、一部の顧客環境では、OCIプライベートDNSリゾルバエンドポイントとそれに対応する転送アーキテクチャの実装は短期的には実現不可能な場合があります。

Autonomous Recovery Serviceのサブネット設定時に、OCIはVCN内に複数のプライベートDNSゾーンを作成します。これらのプライベートゾーンには、OCI内のAutonomous Recoveryサービスで使用されるDNSレコード（名前やプライベートIPアドレスなど）が含まれます。

より重要な点は、リカバリサービスでは、同じリージョン内の顧客環境間で構造的に同一のサービス名を使用する一方、それらの名前に対して返されるプライベートIPアドレスは、保護対象のデータベースが存在するVCNに固有のものであるということです。そのため、顧客が異なるVCNに存在するデータベースを保護するためにリカバリサービスを使用する場合、VCNのコンテキストに応じて異なるプライベートIPアドレスに解決される名前であっても、各VCNにまったく同じDNS名を含めることができます。

つまり、集中管理型のカスタムDNSリゾルバは、適切なリカバリサービスエンドポイントIPアドレスを特定するために必要なOCI VCNコンテキストを十分に持っていないということです。カスタムDNSサービスがそのような要求を転送しようとしても、特定のVCN内でのOCIプライベート解決に依存するため、適切なリカバリサービスプライベートIPアドレスを確実に特定することはできません。

実際には、データベースホストが顧客管理のDNSのみを使用するように構成されている場合、リカバリサービスの名前解決が失敗したり、誤った解決が行われたりする可能性があります。その結果、データベースシステムが自律型リカバリサービスと適切に通信できなくなる可能性があります。

ここで、このブログで説明するアプローチが重要になります。オペレーティングシステムへのアクセスを提供する OCI Base Database Service (BaseDB) および OCI Exadata Database Service (ExaDB-D および ExaDB-XS) システムでは、dnsmasqデータベース ホスト上でローカルに使用して、分割 DNS 構成を実装できます。この設計では、などのAutonomous Recovery Service ドメインrs.br.<region-1>.oraclecloud.com へのクエリは OCI VCN リゾルバによって解決されますが rs.br.<region-1>.oci.oraclecloud.com、その他のすべてのクエリは引き続き顧客のエンタープライズ DNS サーバーを使用します。

つまり、このブログでは、推奨されているOCIプライベートDNSエンドポイントベースのアーキテクチャを実装できない場合でも、リカバリサービスのためにOCIネイティブのDNS解決を維持する必要がある場合の、実用的な代替パターンについて説明します。

前提条件

• オペレーティングシステムからのアクセスが可能なOCI BaseDB、ExaDB-D、またはExaDB-XS

• DNSホスト名が有効になっているVCN

• OCIリゾルバへのアクセス169.254.169.254

• カスタムDNSサーバーのIPアドレス

・Rootまたはsudoデータベースホストへのアクセス

・dnsmasqホストにインストール済み

OCI を介して解決可能である必要がある正確な OCI サービス ドメインを特定することも重要です。この例では、リカバリ サービス関連のドメインは次のとおりです。

rs.br.us-ashburn-1.oraclecloud.com
rs.br.us-ashburn-1.oci.oraclecloud.com

解決策の説明

ソリューション概要

この設計では、dnsmasqデータベースホスト上で直接スプリットDNSを実装するために使用されます。これが、このソリューションの中核となるアーキテクチャ上の考え方です。

ホストにOCI DNSとカスタムDNSのどちらかを選択させるのではなく、dnsmasq両方のリゾルバパスを共存させることができます。クエリはローカルで評価され、ドメインベースのポリシーに従って転送されます。リカバリサービス関連のルックアップはOCI VCNリゾルバに送信されますが、その他のすべてのルックアップは引き続き顧客のエンタープライズDNSサーバーを使用します。

これは、単なる転送サービス以上のものになるため重要ですdnsmasq。ホスト上で軽量なDNSポリシーレイヤーとなり、必要な場所でOCIネイティブな名前解決を維持しつつ、より広範な名前空間ではカスタムDNSをデフォルトパスとして維持することを可能にします。

ローカルリゾルバ構成

データベースホストは、ループバックアドレスをリゾルバとして使用するように構成されています。 では/etc/resolv.conf、ネームサーバーエントリが に設定されています127.0.0.1。

これにより、オペレーティングシステムによって生成されるすべてのDNSクエリが、まずローカルdnsmasqプロセスに到達することが保証されます。

nameserver 127.0.0.1

dnsmasqの設定

この例では、リカバリサービスのサービスドメインは両方とも明示的にOCI VCNリゾルバに転送されます。以下のdnsmasq構成は、リカバリサービスに必要なスプリットDNS動作を実装しています。

no-resolv
listen-address=127.0.0.1
bind-interfaces

# OCI target via OCI resolver
server=/rs.br.us-ashburn-1.oraclecloud.com/169.254.169.254
server=/rs.br.us-ashburn-1.oci.oraclecloud.com/169.254.169.254

# Everything else via custom DNS
server=<CUSTOMER_DNS_IP_1>
server=<CUSTOMER_DNS_IP_2>

cache-size=0

各指令の内容

no-resolv —dnsmasqから上流のリゾルバを継承することを防止します/etc/resolv.conf。これは、/etc/resolv.confがを指しているため重要であり127.0.0.1、上流の動作は明示的に定義する必要があります。

listen-address=127.0.0.1 — dnsmasqがループバックインターフェースのみでリッスンするようにします。リゾルバはDBホストにローカルに留まり、共有サブネットサービスとして公開されません。

bind-interfaces —予測可能なバインディング動作を提供し、複数のインターフェースが存在する場合に曖昧さを回避します。

server=/rs.br.us-ashburn-1.oraclecloud.com/169.254.169.254およびserver=/rs.br.us-ashburn-1.oci.oraclecloud.com/169.254.169.254 —これが重要な分割DNSステートメントです。これにより、dnsmasqはリカバリサービスの検索をOCI VCNリゾルバに特化して送信します。

server=<CUSTOMER_DNS_IP_1>およびserver=<CUSTOMER_DNS_IP_2> —これらは、リカバリーサービス以外のすべての DNS トラフィックのデフォルトのアップストリーム リゾルバを定義します。

cache-size=0 —ローカル DNS キャッシュを無効にすることで、動作が明確になり、テストやトラブルシューティング中に検証しやすくなります。

DNS解決フロー

この構成では、データベースホストは決定論的な DNS パスに従います。ホストはすべてのクエリを に送信します127.0.0.1。dnsmasqは要求されたドメインを評価します。クエリが rs.br.us-ashburn-1.oraclecloud.comまたはの場合rs.br.us-ashburn-1.oci.oraclecloud.com、リクエストを に転送します169.254.169.254。クエリがその他のドメインの場合、リクエストをカスタム DNS サーバーに転送します。

そのため、この設計を単なるDNS転送ではなく、分割DNSと表現する方がより正確です。転送の決定は意図的にドメインごとに分割されており、各クラスのDNSリクエストに対して、適切な応答を提供するのに最適なリゾルバが応答するようになっています。

これがAutonomous Recoveryに有効な理由

この設計の有効性は、OCIネイティブな名前解決とエンタープライズ環境における名前解決の間のDNS境界を尊重することにある。

リカバリサービスは、DNSが利用できないために失敗するわけではありません。OCI VCNローカルコンテキストを必要とする名前に対して、誤ったリゾルバパスが使用された場合に失敗します。dnsmasqデータベースをホスト上にローカルに配置し、リカバリサービスによる名前解決をOCIリゾルバに誘導することで、OCIがリカバリサービスに期待する解決パスを維持しつつ、その他のすべての処理にはエンタープライズDNSを引き続き使用できます。

これにより、両方の要件が問題なく共存することが可能になります。OCI固有の名前解決は正しく維持され、顧客が管理するDNSは、ネームスペースの残りの部分における標準パスとして維持されます。

ここではローカルのdnsmasqが推奨される理由

このロジックを別の仮想マシンや集中型DNSフォワーダーに配置したくなるかもしれませんが、dnsmasqこのユースケースでは、データベースホスト上で直接実行する方が運用上よりクリーンです。

ローカル展開モデルでは、復旧プロセスに新たなコンピューティング依存関係、ネットワークホップ、および可動部品を導入する必要がありません。DNSの動作はローカルかつ透過的でホスト固有のままであるため、検証とトラブルシューティングが容易になります。

オペレーティングシステムからのアクセスが可能なBaseDB、ExaDB-D、およびExaDB-XSシステムにおいては、この設計は実用的かつ洗練されたものとなる。

まとめ

OCIデータベースシステムが顧客管理DNSを使用するように構成されている場合、Autonomous Recovery Serviceは、微妙ながらも重要な名前解決上の課題をもたらします。Recovery Serviceのエンドポイント名は環境間で共有されますが、対応するプライベートIPアドレスはVCN固有です。そのため、集中管理型のカスタムDNSリゾルバでは、Recovery Serviceに対して確実に正しい応答を返すことができません。

適切な設計とは、カスタムDNSを放棄することではなく、DNS解決を選択的に適用することである。

dnsmasqデータベースホスト上でローカルに実行し、/etc/resolv.confを使用するように構成することで127.0.0.1、顧客は、OCIネイティブのリカバリサービス解決を維持しつつ、他のすべてのルックアップにはエンタープライズDNSを引き続き使用する分割DNS構成を実装できます。

この設計は軽量で、決定論的であり、検証が容易で、運用がシンプルで、OCI BaseDB、ExaDB-D、およびExaDB-XS環境に最適です。最も重要な点は、リカバリサービス関連の名前が正しいDNSコンテキスト（VCN内）で解決されることを保証することです。

コメント

コメントを投稿

このブログの人気の投稿

Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

イメージ
Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20) https://mikedietrichde.com/2024/11/20/important-update-to-oracle-database-19c-support-timelines/ 長い沈黙は、私が隠れているという意味ではありません。つまり、今はとても忙しいということです。そして、より少ない旅行で、私はあなたのコメントにもブログと返信するより多くの時間を持っていることを願っています。それでも、Oracle Database 19cサポート・タイムラインの非常に重要な更新について説明します。 * 更新された内容 2024年11月19日現在、Oracle Database 19cのサポート・タイムラインが調整されています。 MOSノート: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールを見ると、新しい日付が表示されます。 Premier Support、2029年12月31日まで 2030年1月1日から2032年12月31日までの拡張サポート 2033年1月1日から2034年12月31日までのアップグレード・サポート これは知ることがとても大切です。 他のリリースの更新はありますか。 MOSノートの終わりにある変更ログ: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールでは、Oracle Database 21cの最新の更新も確認できます。このリリースのPremier Support期間は、2027年7月31日まで延長されました。 また、Oracle Database 23aiのパッチ適用終了日は2032年12月31日に設定されています。 Lifetime Support Policy 更新は、Oracle Technology Productsの Oracle Lifetime Support Policy (6ページ)でも確認できます。 From: Oracle Lifetime Support Policy for Oracle Technology Product s – page 6 – Nov 19, 2024 特に、次の表に示す制限事項に注意してください。 Oracle Database 1...
続きを読む

ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13)

イメージ
ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13) https://blogs.oracle.com/cloud-infrastructure/post/milliseconds-matter-bcc-group-and-oci-vs-aws 投稿者： Steven Riley | Senior Cloud Architect William Bierds | Business Analyst and Systems Engineer - BCC Group International Travis Liles | Master Principal Cloud Architect Puru Patel | Cloud Architect - FSI これは、BCC グループと Oracle Cloud Infrastructure (OCI) 間の市場データ パートナーシップを紹介するブログ シリーズの第 2 部です。   はじめに 金融市場データアプリケーションは、トレーダー、金融機関、そして市場参加者が情報に基づいた意思決定を行えるよう、リアルタイムデータを提供することで、取引エコシステムにおいて重要な役割を果たしています。 前回のブログ で述べたように、取引環境において最適なパフォーマンスを確保するには、市場データを超低レイテンシかつ高い信頼性で配信する必要があります。 今日の急速に変化する金融市場において、クラウドは市場データ・アプリケーションにとって強力な推進力として台頭しています。適切なネットワークとインフラストラクチャがあれば、企業は実行時間の短縮、可用性の向上、そして堅牢なセキュリティを実現できます。しかし、企業によるクラウド導入は遅れており、ワークロードのクラウド移行計画を中止しているケースもあります。そこで、BCCグループとOracle Cloud Infrastructure（OCI）のパートナーシップが注目されています。 BCCグループは、主力市場データアプリケーションであるONE PlatformをOCI上に導入しました。このブログでは、以下の点について説明します。 このパートナーシップがなぜこれほど相乗効果をもたらすのかを探る OC...
続きを読む

OCIのカスタム・ルート表を使用した詳細なルーティング制御 (2025/02/27)

イメージ
OCIのカスタム・ルート表を使用した詳細なルーティング制御 (2025/02/27) https://www.ateam-oracle.com/post/granular-routing-control-with-custom-route-tables-in-oci 投稿者： Achinthya Gopinath | Principal Cloud Architect OCIでは、カスタムVCNルート表をVNIC上の個々のVNICまたは特定のIPアドレスに割り当てることができるため、ルーティングの柔軟性を高める強力な新機能が導入されました。この更新により、異なるトラフィック・ルーティング・ポリシーを必要とするインスタンスに対して個別のサブネットを作成する必要がなくなります。 概要: 以前は、VCNルート表はサブネット・レベルでのみ割り当てられていました。つまり、同じサブネット内の異なるインスタンスで異なるルーティング・ルールが必要な場合は、別々のサブネットを作成し、ネットワーク設計に複雑さを加える必要がありました。 この機能により、次のことができるようになりました。 •    カスタムVCNルート表をVNICまたはVNICの特定のIPアドレスに割り当てます。 •    プライマリIPアドレスとセカンダリIPアドレスの両方にルーティング・ポリシーを適用します。 •    階層ルート表のプリファレンスを有効にします。このプリファレンスは、使用するルート表を決定する構造化アプローチに従います。 ルーティングに関する考慮事項: •    一度にトラフィック・ルーティングを決定するために使用されるルート表は1つのみです。 •    ルート表がIPアドレスに関連付けられている場合は、他のルート表よりも優先されます。 •    IPアドレス/VNICにルート表がない場合は、階層内の次に使用可能なルート表(VNICレベルまたはサブネット・レベル)が使用されます。 詳細の選択プロセス: 1.    VNICのIPアドレスにルート表が関連付けられている場合、その表はIPアドレスからのトラフィックのルーティングに使用されます。 2.  ...
続きを読む