IBM Cloud Docs
カスタム・リゾルバーの処理

カスタム・リゾルバーの処理

プライベートDNSカスタムリゾルバは、オンプレミスDNSリゾルバから IBM Cloud VPCホスト名の解決を可能にし、 IBM Cloud からオンプレミスホスト名の解決を可能にすることで、ハイブリッドクラウド環境のニーズを満たすために IBM Cloud® DNS Services 'の機能を拡張します。

カスタム・リゾルバーの主要な機能は以下のとおりです。

  • DNS 解決を、オンプレミスにあるリゾルバーに拡張します
  • 1 次リゾルバー・ロケーションが使用不可の場合に、2 次リゾルバー・ロケーション (構成されている場合) への解決フォールバックを許可します

カスタム・リゾルバーの概要

カスタム・リゾルバーの使用を開始するには、カスタム・リゾルバーを作成し、それに転送ルールを追加する必要があります。

カスタムリゾルバは、デフォルトで高可用性に設定されていることが期待される。 高可用性構成を必要としない場合は、『Creating a custom resolver without high availability』の手順に従ってください。

カスタム・リゾルバーを作成し、その転送ルールを構成したら、VPC でそのリゾルバーを有効にすることができます。 これにより、リゾルバーの DHCP オプションがカスタム・リゾルバーの IP アドレスに変更されます。

カスタムリゾルバプロファイルの概要

カスタムリゾルバプロファイルを使用すると、転送ルール、セカンダリゾーン、DNSビューの構成数の上限を増やすことができます。 さらに、セカンダリゾーンに多数のDNSレコードを設定したい場合、プロファイルを大きくすることでパフォーマンスのボトルネックを防ぐことができます。

クォータは、選択したカスタムリゾルバプロファイルによって異なります。 詳細については、 カスタム・リゾルバ・プロファイルのクォータを 参照のこと。

カスタム・リゾルバー用に予約済みの IP

仮想アプライアンスは、カスタム・リゾルバーが DNS 照会にサービスを提供するため、または グローバル・ロード・バランサーのヘルス・チェック が起点サーバーにプローブを送信してその正常性状況をモニターするために作成されます。 仮想アプライアンスは DNS Servicesによって完全に管理されていますが、 「VPC のサブネット」 ダッシュボードに移動し、サブネットの詳細を表示して、そのサブネットの予約 IP を確認することができます。 DNS Servicesによって管理されている仮想アプライアンス上のネットワーク・インターフェースにバインドされている IP アドレスを確認できます。

リザーブドIP
で管理する仮想アプライアンスのリザーブドIP DNS Services

「ターゲット・リソース」 列で、仮想アプライアンスがサブネットに接続されている DNS サービス・インスタンスにバインドされている予約済み IP を確認できます。 「自動リリース」 を有効なままにすることをお勧めします (デフォルト設定)。 自動解放を使用すると、カスタム・リゾルバーおよびグローバル・ロード・バランサー・プールの削除プロセスの一部として、仮想アプライアンスの削除後にこの IP アドレスが自動的に IP アドレス・プールに解放されます。

自動リリースを無効にすると、 DNS Services のリカバリー操作が中断される可能性があります。

コンピュート・インスタンスへのカスタム・リゾルバー・アドレスの伝搬

各カスタム・リゾルバー・ロケーションの予約済み IP アドレスは、まとめてカスタム・リゾルバー・アドレスと呼ばれます。 カスタム・リゾルバーで複数のロケーションが有効になっている場合、VPC 上のコンピュート・インスタンスへのこれらのカスタム・リゾルバー・アドレスの伝搬では、近接性およびロード・バランシングの最適化ルールが考慮されます。

近接ルールは、コンピュート・インスタンスの 1 次 DNS サーバーを決定するための優先ルールと見なされ、アベイラビリティー・ゾーンにロケーションがない場合はロード・バランシングの最適化が考慮されます。 以下の例では、各アベイラビリティー・ゾーン内のコンピュート・インスタンスに対する 1 次 DNS サーバーの割り当てを決定するためのルールについて説明します。

例 1: 異なるアベイラビリティー・ゾーンにある 3 つのロケーション

この例では、各可用性に厳密に 1 つのカスタム・リゾルバー・ロケーションがあります。

カスタム・リゾルバー: R:

  • us-south-1 の location-1 のアドレスは A1 です。
  • us-south-2 の location-2 のアドレスは A2 です。
  • us-south-3 の location-3 のアドレスは A3 です。

近接性は、各アベイラビリティー・ゾーンのコンピュート・インスタンスの 1 次 DNS サーバーを決定するための唯一のポリシーです。

  • us-south-1: A1 (1 次)、 A2A3
  • us-south-2: A2 (1 次)、 A1A3
  • us-south-3: A3 (1 次)、 A1A2

例 2: 同じアベイラビリティー・ゾーン内の 3 つのロケーションのうち 2 つ

この例では、3 つのロケーションのうち 2 つが同じアベイラビリティー・ゾーン us-south-1 にありますが、 us-south-3 にはロケーションがありません。

カスタム・リゾルバー: R:

  • us-south-1 の location-1 のアドレスは A1 です。
  • us-south-1 の location-2 のアドレスは A2 です。
  • us-south-3 の location-3 のアドレスは A3 です。

us-south-1 および us-south-3 の 2 つのアベイラビリティー・ゾーンにはロケーションがあるため、これらの 1 次 DNS サーバーを判別するために、まず近接規則が適用されます。 次に、負荷分散最適化ルールを使用して、 us-south-2 のプライマリサーバーとして location-2 を選択する。 したがって、各アベイラビリティー・ゾーン内のコンピュート・インスタンスの結果として得られる DNS サーバーは、以下のようになります。

  • us-south-1: A1 (1 次)、 A2A3
  • us-south-3: A3 (1 次)、 A1A2
  • us-south-2: A2 (1 次)、 A1A3

例 3: 3 つのロケーションがすべて同じアベイラビリティー・ゾーンにある

この例では、すべてのロケーションが同じアベイラビリティー・ゾーン us-south-1 にありますが、 us-south-2 および us-south-3 にはロケーションがありません。

カスタム・リゾルバー: R:

  • us-south-1 の location-1 のアドレスは A1 です。
  • us-south-1 の location-2 のアドレスは A2 です。
  • us-south-1 の location-3 のアドレスは A3 です。

近接ルールは、location-1を'us-south-1 のプライマリDNSサーバーとして選択する。 次に、ロード・バランシング最適化ルールは、 us-south-2 および us-south-3 の 1 次 DNS サーバーをそれぞれ location-2 および location-3に割り当てます。 その結果、各アベイラビリティゾーンのコンピュートインスタンスのDNSサーバーは以下のようになる:

  • us-south-1: A1 (1 次)、 A2A3
  • us-south-2: A2 (1 次)、 A1A3
  • us-south-3: A3 (1 次)、 A1A2

例 4: カスタム・リゾルバー・ロケーションの数が 3 未満である

この例では、カスタム・リゾルバーのロケーションは 3 つ未満です。

カスタム・リゾルバー: R:

  • us-south-1 の location-1 のアドレスは A1 です。
  • us-south-2 の location-2 のアドレスは A2 です。

この場合、少なくとも 1 つのロケーションが、2 つのアベイラビリティー・ゾーンの 1 次 DNS サーバーとして使用されます。 上記のルールに従うと、各アベイラビリティー・ゾーン内のコンピュート・インスタンスの結果として得られる DNS サーバーは、以下のようになります。

  • us-south-1: A1 (1 次)、 A2
  • us-south-2: A2 (1 次)、 A1
  • us-south-3: A1 (1 次)、 A2

カスタム・リゾルバーの状況

新しく作成されたカスタムリゾルバのステータスは、リゾルバの場所が完全にプロビジョニングされていないため、最初は Critical。 リゾルバー・ロケーションが Healthy に変わると、状況が Up に変わります。

以下の状況定義は、リゾルバー・ロケーションに適用されます。

  • Up - リゾルバー・ロケーションが機能している場合。
  • Down - リゾルバー・ロケーションが機能していない場合。

以下の状況定義は、カスタム・リゾルバーに適用されます。

  • Healthy - すべてのリゾルバー・ロケーションが Up の場合、状況は Healthy です。
  • Degraded - リゾルバー・ロケーションが複数あり、Up のロケーションと Down のロケーションがある場合、状況は Degraded に変わります。
  • Critical - すべてのリゾルバー・ロケーションが Down の場合、状況は Critical に変わります。

カスタムリゾルバプロファイル機能

次のプロファイルを使用してカスタムリゾルバをプロビジョニングすることで、ロケーションサーバーインスタンスのプロファイルサイズや、セカンダリゾーン、転送ルール、ビューなどのリソースの最大制限など、さまざまな機能を提供することができます。

カスタム リゾルバ プロファイルをアップグレードまたはダウングレードする場合、カスタム リゾルバの場所がプロビジョニングされているサブネットには、使用可能な IP アドレスが少なくとも 1 つ_必要_です。

IPアドレスが利用できない場合、カスタムリゾルバのロケーションは通常通り機能しますが、変更プロセスは完了しません。 また、プロファイル変更中は転送ルールやセカンダリゾーンの作成、更新、削除はできません。

次の表は、各プロファイルの機能を示している。

各プロファイルの機能
プロフィール セカンダリゾーン制限 転送ルールの上限 転送ルールごとの表示制限
必須 10 10 1
拡張 50 50 3
プレミア 100 100 5

カスタムリゾルバとロケーションの有効化または無効化、カスタムリゾルバの削除、ロケーションの追加と削除は、カスタムリゾルバプロファイルの更新中は実行できません。

ルールビューの転送

ビューは、評価結果に基づいて、DNSクエリを異なるDNSリゾルバにルーティングする式を定義します。 この評価により、分割DNSなどの高度なサーバーブロックルーティング機能が可能になります。

ビュー式は 共通表現言語 に従っていますが、すべての CEL 組み込み関数およびマクロをサポートしているわけではありません。 現在、この式では以下のカスタム関数、変数、演算子のみがサポートされています。

  • 関数

    • ipInRange(ip, cidr): ip アドレスが cidr の範囲内にあるかどうかを示すブーリアン値を返します。
  • 変数

    • source: DNS クエリ用のクライアント情報。
      • ip:クライアントのIPアドレス。
  • オペレーター

    • ||:論理和
    • &&:論理 AND
    • !:論理NOT
    • ==: 論理等価
    • !=: 論理 NotEquals
    • ?::条件付き

表現例を見る

  • ipInRange(source.ip, ' 10.240.0.0/24 ' )
  • !ipInRange(source.ip, ' 10.240.0.0/24 ' )
  • ipInRange(source.ip, '10.240.0.0/24') || ipInRange(source.ip, '10.240.1.0/24')
  • source.ip == '10.240.0.5'
  • source.ip != '10.240.0.5'

カスタムレゾルバ限界

詳細については 、「DNSサービスのサービス制限 」を参照してください。