DNS ポリシーの概要

Cloud DNS は、さまざまな種類のポリシーをサポートしています。このページでは、さまざまなポリシータイプとその使用条件について説明します。

  • サーバー ポリシーは、Virtual Private Cloud（VPC）ネットワークに限定公開 DNS の構成（DNS 転送、ロギング）を適用します。
  • レスポンス ポリシーは、クエリ名に基づいて限定公開 DNS のレスポンスをオーバーライドします。
  • ルーティング ポリシーは、クエリ（ラウンドロビン、位置情報など）に基づいてトラフィックを転送します。

この 3 つのポリシーを同時に使用することもできます。

サーバー ポリシー

DNS 解決のハイブリッド デプロイメントを設定するには、サーバー ポリシーを使用します。DNS 解決の方向に応じて、受信サーバー ポリシーを設定できます。ワークロードでオンプレミスの DNS リゾルバを使用する場合、送信サーバー ポリシーを使用して DNS 転送ゾーンを設定できます。オンプレミス ワークロードの名前解決を Google Cloud で行う場合は、受信サーバー ポリシーを設定できます。

サーバー ポリシーの詳細については、サーバー ポリシーの概要をご覧ください。

DNS サーバー ポリシーを構成して適用する方法については、DNS サーバー ポリシーの適用をご覧ください。

レスポンス ポリシー

レスポンス ポリシーは、レコードではなくルールを含む Cloud DNS 限定公開ゾーンのコンセプトです。これらのルールを使用すると、DNS レスポンス ポリシー ゾーン（RPZ）のドラフト コンセプト（IETF）に似た効果が得られます。レスポンス ポリシー機能を使用すると、ルックアップ中に DNS リゾルバがコンサルトするネットワーク内の DNS サーバーに、カスタマイズされたルールを導入できます。レスポンス ポリシーのルールが受信クエリに影響する場合は処理されます。それ以外の場合は、ルックアップが通常どおりに進みます。詳細については、レスポンス ポリシーとルールの管理をご覧ください。

レスポンス ポリシーは RPZ とは異なります。RPZ は通常の DNS ゾーンであり、特殊な形式のデータには、互換性のあるリゾルバが特別な処理を行います。レスポンス ポリシーは DNS ゾーンではなく、API で個別に管理されます。Cloud DNS でレスポンス ポリシーを作成して変更するには、ResponsePolicies API を使用します。レスポンス ポリシーは ManagedZones とは別のものであり、ManagedZones API または RRSet API で管理することはできません。

ルーティング ポリシー

DNS ルーティング ポリシーを使用すると、特定の条件に基づいてトラフィックを転送できます。Cloud DNS は、各ルーティング ポリシーに埋め込まれたヘルスチェックと自動フェイルオーバーもサポートしています。ヘルスチェックは、グローバル アクセスが有効になっている内部パススルー ネットワーク ロードバランサと内部アプリケーション ロードバランサ、およびクロスリージョン内部アプリケーション ロードバランサで使用できます。

Cloud DNS でサポートされるルーティング ポリシー:

  • 重み付きラウンドロビン ルーティング ポリシー
  • 位置情報に基づくルーティング ポリシー
  • ジオフェンス ルーティング ポリシー
  • フェイルオーバー ルーティング ポリシー

一度に 1 つのリソース レコードセットに適用されるルーティング ポリシーは 1 種類だけです。位置情報に基づくルーティング ポリシーをバックアップとして設定できるフェイルオーバー ルーティング ポリシーを構成する場合を除き、ルーティング ポリシーを結合することはできません。

重み付きラウンドロビン ルーティング ポリシー

重み付きラウンドロビン（WRR）ルーティング ポリシーでは、DNS ターゲットごとに異なる重みを指定できます。Cloud DNS は、この重みに従ってトラフィックを分散します。このポリシーは、手動の active-active 構成または active-passive 構成をサポートする場合に使用できます。また、ソフトウェアの本番環境版と試験運用版でトラフィックを分割することもできます。

ターゲットが内部パススルー ネットワーク ロードバランサの場合、ヘルスチェックはデフォルトで使用できます。これにより、エンドポイントがヘルスチェックに失敗した場合に自動フェイルオーバーが可能になります。フェイルオーバーが発生した場合、トラフィック分割は残りの正常なエンドポイント間で自動的に調整されます。詳細については、ヘルスチェックをご覧ください。

位置情報に基づくルーティング ポリシー

位置情報（GEO）ルーティング ポリシーを使用すると、ソースの地理区分（Google Cloud リージョン）から送信されたトラフィックを特定の DNS ターゲットにマッピングできます。このポリシーを使用して、トラフィックの発生元に基づいて受信リクエストを異なるサービス インスタンスに配信します。この機能は、インターネット、外部トラフィック、または Google Cloud 内で発生して内部パススルー ネットワーク ロードバランサにバインドされたトラフィックに使用できます。Cloud DNS は、クエリが Google Cloud に入るリージョンをソース地域として使用します。

ターゲットが内部パススルー ネットワーク ロードバランサ、内部アプリケーション ロードバランサ、またはクロスリージョン内部アプリケーション ロードバランサの場合、ヘルスチェックはデフォルトで使用できます。これにより、エンドポイントがヘルスチェックに失敗した場合に自動フェイルオーバーが可能になります。位置情報の場合、トラフィックはソース トラフィックに次に最も近い位置情報にフェイルオーバーします。

ジオフェンス ルーティング ポリシー

ヘルスチェックは、ジオフェンス ルーティング ポリシー タイプを有効にします。特定の位置情報のすべてのエンドポイントが異常であったとしても、トラフィックをその位置情報に制限できます。位置情報ポリシーでは、特定の地域のバケットでヘルスチェックの失敗が発見された場合、トラフィックは次に最も近い位置情報に自動的にフェイルオーバーします。ジオフェンスが有効になっている場合、自動フェイルオーバーは行われません。信頼できるサーバーとして、Cloud DNS は値を返す必要があります。このシナリオでは、Cloud DNS は、ヘルスチェックの失敗時にすべての IP アドレスを変更せずに返します。

フェイルオーバー ルーティング ポリシー

フェイルオーバー ルーティング ポリシーを使用すると、アクティブ バックアップ構成を設定して、VPC 内の内部リソースの高可用性を実現できます。フェイルオーバー ルーティング ポリシーは、非公開ゾーンに対してのみ構成できます。

通常のオペレーションでは、active セットでプロビジョニングされた IP アドレスが常に返されます。アクティブ セット内のすべての IP アドレスが失敗する（ヘルス ステータスが異常に変わった）場合、Cloud DNS はバックアップ セットの IP アドレスの提供を開始します。バックアップ セットを位置情報ポリシーとして構成できます。それらは、位置情報ポリシーのセクションで説明したのと同じ動作をします。内部パススルー ネットワーク ロードバランサ、内部アプリケーション ロードバランサ、またはクロスリージョン内部アプリケーション ロードバランサとして構成されている場合、バックアップの仮想 IP（VIP）アドレスもすべてヘルスチェックの対象となります。

Cloud DNS では、バックアップ VIP アドレスへのトラフィックを段階的にトリクリングできます。これにより、バックアップ VIP アドレスが機能していることを確認できます。バックアップに送信されるトラフィックの割合を 0 ～ 1 の割合で構成できます。一般的な値は 0.1 にする必要がありますが、Cloud DNS はトラフィックの 100% をバックアップ VIP アドレスに送信し、手動でフェイルオーバーをトリガーできます。ヘルスチェックは内部ロードバランサにのみ適用できます。したがって、構成されるすべての VIP アドレスは、内部パススルー ネットワーク ロードバランサ、内部アプリケーション ロードバランサ、またはクロスリージョン内部アプリケーション ロードバランサのいずれかである必要があります。

ヘルスチェック

Cloud DNS では、内部パススルー ネットワーク ロードバランサ、グローバル アクセスが有効になっている内部アプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサのヘルスチェックがサポートされています。

限定公開ロードバランサのヘルスチェックは、限定公開マネージド ゾーンでのみ使用できます。ヘルスチェックは、転送、ピアリング、管理の逆引きゾーンでは使用できません。

ロードバランサのヘルスチェックの詳細については、ヘルスチェックの概要をご覧ください。

内部パススルー ネットワーク ロードバランサのヘルスチェック

Cloud DNS は、ロードバランサの組み込みのヘルスチェック構成を使用して、内部パススルー ネットワーク ロードバランサの健全性を判断します。20% 以上のヘルスチェックが成功した場合、Cloud DNS は、内部パススルー ネットワーク ロードバランサが正常でトラフィックを受信可能であるとみなします。

内部パススルー ネットワーク ロードバランサの場合、Cloud DNS は個々のバックエンド インスタンスから直接ヘルスシグナルを取得します。また、しきい値アルゴリズムにより、エンドポイントが正常かどうかを判断します。

1 つの内部パススルー ネットワーク ロードバランサの仮想 IP アドレスの背後で複数のサービスを実行できます。Cloud DNS は、ロードバランサのヘルスチェック構成で指定されたプロトコルとポートからヘルスシグナルを探します。ヘルスチェックの詳細については、ヘルスチェックの概要をご覧ください。

内部アプリケーション ロードバランサとクロスリージョン内部アプリケーション ロードバランサの場合、Cloud DNS は、ルーティングの決定時にロードバランサ自体の健全性を考慮します。クエリを受信すると、ロードバランサは正常なバックエンド サービスにのみトラフィックを分散します。正常なバックエンドを確保するために、マネージド インスタンス グループ（MIG）などのサービスを使用してバックエンドのライフサイクルを管理できます。Cloud DNS は、個々のバックエンドのヘルス ステータスを認識する必要はありません。このタスクはロードバランサによって処理されます。

重み付きラウンドロビン ポリシーとヘルスチェック

Cloud DNS は、0～1,000 の重み（両端を含む）をサポートします。ヘルスチェックを含めると、次のようになります。

  • 複数のターゲットをすべて重み 0 で構成すると、トラフィックはターゲット間で均等に分配されます。
  • 新しいゼロ以外で重み付けされたターゲットを構成すると、それがプライマリ ターゲットになり、すべてのトラフィックがそのターゲットにシフトします。
  • ゼロ以外で重み付けされたターゲットを追加すると、Cloud DNS は（リクエストごとに）ターゲット間でトラフィック分割を動的に計算し、トラフィックを適切に分配します。たとえば、重みを 0、25、75 で 3 つのターゲットを構成した場合、重みが 0 のターゲットはトラフィックを取得せず、重みが 25 のターゲットはトラフィックの 4 分の 1 を取得し、残りのターゲットは受信トラフィックの 4 分の 3 を取得します。
  • ゼロ以外の重み付けのターゲットにヘルスチェックが関連付けられていても、ゼロの重み付けのターゲットに関連付けられていない場合は、ゼロの重み付けのターゲットは常に正常とみなされます。ゼロ以外のレコードがすべて異常な場合は、Cloud DNS がゼロの重み付けのレコードを返します。
  • ヘルスチェックがゼロ以外の重み付けのレコードとゼロの重み付けレコードの両方に関連付けられている場合に、すべてのレコードがヘルスチェックに失敗すると、Cloud DNS はゼロ以外の重み付けのターゲットを返し、ゼロの重み付けのターゲットを返さないようにします。
  • Cloud DNS がリクエスト元に返す重みバケット（単一のポリシー アイテム）を選択すると、その重みバケット内の IP アドレスのみが返されます。重みバケットに 1 つの IP アドレスのみを指定した場合、その IP アドレスのみが応答に含まれます。重みバケットに複数の IP アドレスがある場合、Cloud DNS はすべての IP アドレスをランダムな順序で返します。

ヘルスチェックを使用する位置情報ポリシー

ヘルスチェックを有効にした位置情報ポリシーの場合、次のようになります。

  • ジオバケットに複数の IP アドレスが構成されていて、すべての IP アドレスがヘルスチェックされる場合は、正常な IP アドレスのみが返されます。
  • ヘルスチェックありとヘルスチェックなしが混在して一致し、ヘルスチェックしたすべての IP アドレスが失敗すると、Cloud DNS はヘルスチェックが構成されていないすべての IP アドレスを返します。このシナリオでは、次に最も近い地域への自動フェイルオーバーは発生しません。
  • このポリシーは、以下の場合に、次に最も近い地域バケットに自動的にトラフィックをルーティングします。
    • 地域バケット内のすべての IP アドレスでヘルスチェックが有効になっている。
    • ポリシーでフェンスが無効になっている。
    • すべての IP アドレスがヘルスチェックに失敗している。この場合、次に最も近い地理的ターゲットに自動的にフェイルオーバーされます。

ヘルスチェックのロギング

Cloud DNS は、ヘルスチェックのロギングをサポートし、任意のバックエンドの変更のヘルスチェックのステータスを記録します。これにより、次のことが可能になります。

  • ルーティング ポリシーが期待どおりに機能しているかどうかを検証します。次に例を示します。
    • GEO ポリシーの場合、ポリシーが適切な地域を検出し、適切な RR データセットを返しているかどうかを検証できます。
    • WRR ポリシーの場合、ポリシーが正しい重みで IP アドレスを返しているかどうかを検証できます。
  • 障害が発生している特定のバックエンドと IP アドレスに関するインフラストラクチャの問題を特定します。
  • 特定のバックエンドが含まれないか、それらだけが返される問題をトラブルシューティングします。

DNS ルーティング ポリシーを作成、編集、削除するには、DNS ルーティング ポリシーとヘルスチェックを管理するをご覧ください。

DNS ルーティング ポリシーでサポートされるレコードタイプ

DNS ルーティング ポリシーは、Cloud DNS でサポートされているレコードタイプをすべてサポートしているわけではありません。DNS ルーティング ポリシーは、次のレコードタイプをサポートします。

レコードタイプ 説明
A IPv4 アドレス
AAAA IPv6 アドレス
CNAME 正規名
MX Mail Exchange レコード
SRV ホスト/ポート（RFC 2782）
TXT テキストデータ