名前解決の順序

Cloud DNS では、次の手順で Compute Engine 仮想マシン(VM)インスタンスと Google Kubernetes Engine(GKE)ノードからのクエリに応答します。

GKE ノード以外の Compute Engine VM の場合、Cloud DNS は VPC ネットワークの解決順序に従って、受信したクエリを処理します。各 VM は、メタデータ サーバーの IP アドレス(169.254.169.254)をネームサーバーとして使用するように構成する必要があります。

GKE ノードの場合:

  1. Cloud DNS はまず、クラスタ スコープのレスポンス ポリシーと限定公開ゾーンを使用してクエリの照合を試みます。

  2. 次に、VPC ネットワーク解決順序に従って処理を継続します。

クラスタ スコープのレスポンス ポリシーと限定公開ゾーン

  1. GKE クラスタ スコープのレスポンス ポリシーのルールを使用して照合します。Cloud DNS は該当するすべての GKE クラスタ スコープのレスポンス ポリシーをスキャンし、DNS 名属性ができるだけ多くのクエリと一致するルールを検索します。Cloud DNS は、最長サフィックス マッチングを使用して、クラスタ スコープのレスポンス ポリシーをスキャンします。

    1. Cloud DNS が一致するレスポンス ポリシー ルールを検出し、ルールがローカルデータを提供する場合、Cloud DNS はレスポンスとしてローカルデータを返し、名前解決プロセスを完了します。

    2. Cloud DNS が一致するレスポンス ポリシー ルールを検出し、ルールの動作でレスポンス ポリシーを回避した場合、Cloud DNS は次のステップに進みます。

    3. Cloud DNS が一致するレスポンス ポリシーを見つけることができない場合、またはノードに適用可能なクラスタ スコープ レスポンス ポリシーがない場合は、Cloud DNS は次のステップに進みます。

  2. クラスタ スコープの限定公開ゾーンのレコードを照合します。Cloud DNS は、すべてのクラスタ スコープの限定公開マネージド ゾーンをスキャンし、できるだけ多くのクエリに一致するレコードを探します。Cloud DNS は、最長サフィックス マッチングを使用して、クラスタ スコープの限定公開ゾーン内のレコードを検索します。

    1. クエリの最も詳細な一致がクラスタ スコープの限定公開マネージド ゾーンのレコードの場合、Cloud DNS はレコードデータをレスポンスとして返し、名前解決プロセスを完了します。

    2. クエリの最も詳細な一致がクラスタ スコープ転送ゾーンのゾーン名の場合、Cloud DNS は転送ゾーンの転送先のいずれかにクエリを転送して名前解決プロセスを完了します。Cloud DNS から次のいずれかのレスポンスが返されます。

      • 転送先から受信したレスポンス。
      • SERVFAIL レスポンス(転送先が Cloud DNS に応答しない場合)。
    3. クエリがクラスタ スコープの限定公開ゾーンと一致しない場合、Cloud DNS は VPC ネットワークの解決順序に進みます。

VPC ネットワークの解決順序

  1. VPC ネットワークの代替ネームサーバー: VPC ネットワークにアウトバウンド サーバー ポリシーがある場合、Google Cloud は、そのポリシーで定義されたいずれかの代替ネームサーバーにクエリを転送して、名前解決プロセスを完了します。

    アウトバウンド サーバー ポリシーに複数の代替ネームサーバーが存在する場合、Cloud DNS は内部アルゴリズムを使用して代替ネームサーバーをランク付けします。代替ネーム サーバーは、同等のランクから始まり、正常なレスポンス(NXDOMAIN レスポンスを含む)の割合と最短ラウンドトリップ時間(最小レスポンス レイテンシ)に基づいてランクが上がります。

    Cloud DNS は、代替ネームサーバーにクエリを送信し、次のプロセスを使用してレスポンスを返します。

    • 送信サーバー ポリシーに複数の代替ネームサーバーが存在する場合、Cloud DNS はまずランクが最も高い代替ネームサーバーにクエリを送信します。その後最もランクの高い代替ネーム サーバーから応答を受信しない場合は、Cloud DNS は、その次にランクの高い代替ネームサーバーに送信します。Cloud DNS は、次にランクされている代替ネームサーバーからのレスポンスを受信しない場合、代替ネームサーバーのリストがなくなるまでランクの降順で代替ネームサーバーにクエリを送信します。

    • Cloud DNS が代替ネームサーバーからレスポンスを受信すると、Cloud DNS はそのレスポンスを返します。レスポンスには NXDOMAIN レスポンスが含まれます。

    • Cloud DNS がアウトバウンド サーバー ポリシーのすべての代替ネームサーバーからレスポンスを受信しない場合、Cloud DNS は SERVFAIL レスポンスを合成します。代替ネームサーバーの接続に関するトラブルシューティングについては、代替ネームサーバー ネットワークの要件をご覧ください。

    VPC ネットワークにアウトバウンド サーバー ポリシーがない場合、Cloud DNS は次のステップに進みます。

  2. VPC ネットワーク スコープのレスポンス ポリシーのルールを使用して照合します。Cloud DNS は該当するすべての VPC ネットワーク レスポンス ポリシーをスキャンして、DNS 名属性ができるだけ多くのクエリと一致するルールを検索します。Cloud DNS は、最長サフィックス マッチングを使用して、ネットワーク スコープのレスポンス ポリシーをスキャンします。

    1. Cloud DNS が一致するレスポンス ポリシー ルールを検出し、ルールがローカルデータを提供する場合、Cloud DNS はレスポンスとしてローカルデータを返し、名前解決プロセスを完了します。

    2. Cloud DNS が一致するレスポンス ポリシー ルールを検出し、ルールの動作でレスポンス ポリシーを回避した場合、Cloud DNS は次のステップに進みます。

    3. Cloud DNS が一致するレスポンス ポリシーを見つけることができない場合や、VM またはノードに適用可能なネットワーク スコープ レスポンス ポリシーがない場合、Cloud DNS は次のステップに進みます。

  3. VPC ネットワーク スコープの限定公開マネージド ゾーンと Compute Engine .internal ゾーンのレコードを照合します。Cloud DNS は、該当するすべての Compute Engine の内部 DNS ゾーンと VPC ネットワークの許可されたすべての限定公開マネージド ゾーンをスキャンし、できるだけ多くのクエリと一致するレコードを検索します。Cloud DNS は、最長サフィックス マッチングを使用してレコードを検索します。

    1. クエリの最も詳細な一致が Compute Engine の内部 DNS 名の場合、Cloud DNS は VM のネットワーク インターフェースの内部 IPv4 アドレスをレスポンスとして返し、名前解決プロセスを完了します。限定公開ゾーンのレコードがより詳細に一致する場合、マネージド限定公開ゾーンのレコードは、自動的に作成された Compute Engine の内部 DNS 名のみ優先します。

    2. クエリの最も詳細な一致がネットワーク スコープの限定公開マネージド ゾーンのレコードの場合、Cloud DNS はレコードデータをレスポンスとして返し、名前解決プロセスを完了します。

    3. クエリの最も詳細な一致がネットワーク スコープ転送ゾーンのゾーン名の場合、Cloud DNS は転送ゾーンの転送先のいずれかにクエリを転送して名前解決プロセスを完了します。Cloud DNS から次のいずれかのレスポンスが返されます。

      • 転送先から受信したレスポンス。
      • SERVFAIL レスポンス(転送先が Cloud DNS に応答しない場合)。
    4. クエリの最も詳細な一致がネットワーク スコープのピアリング ゾーンの名前である場合、Cloud DNS は現在の名前解決プロセスを中止し、ピアリング ゾーンのターゲット VPC ネットワークの観点から新しい名前解決プロセスを開始します。

    クエリがどの Compute Engine の内部 DNS 名とも一致しない場合、またはクエリが限定公開ゾーン、転送ゾーン、ピアリング ゾーンと一致しない場合、Cloud DNS は次のステップに進みます。

  4. 一般公開 DNS クエリを使用したレコードを照合する: Google Cloud は Start of Authority(SOA)レコードに従い、Cloud DNS 一般公開ゾーンを含む一般に利用可能なゾーンをクエリします。Cloud DNS から次のいずれかのレスポンスが返されます。

    • 信頼できるネームサーバーから受信したレスポンス。
    • NXDOMAIN レスポンス(レコードが存在しない場合)。

たとえば、vpc-avpc-b という 2 つの VPC ネットワークと、cluster-a という GKE クラスタがあり、次のスコープ対象リソースがあるとします。

  1. vpc-a は、次の限定公開ゾーンをクエリできます。各エントリの末尾のドットに注意してください。

    • static.example.com.
    • 10.internal.
  2. peer.com. は、vpc-b の VPC 名前解決順序をクエリできるピアリング ゾーンです。

  3. vpc-a は、どのアウトバウンド サーバーやレスポンス ポリシーにも関連付けられていません。

  4. cluster-a には、example.com という限定公開ゾーンにクエリを送信する権限が付与されています。cluster-a も、どのアウトバウンド サーバーやレスポンス ポリシーにも関連付けられていません。

  5. cluster-a の VM は、以下をクエリできます。

    • example.comと子(static.example.com を含める)は、cluster-a 承認の example.com と呼ばれる限定公開ゾーンによって応答されます。
    • vpc-a10.internal
    • ピアリング ゾーンを使用した peer.com
  6. cluster-a に存在しない VM は、以下をクエリできます。

    • static.example.com と子は、vpc-a 承認の static.example.com と呼ばれる限定公開ゾーンによって応答されます。example.com に対するクエリは、インターネット レスポンスを返します。
    • vpc-a10.internal
    • ピアリング ゾーンを使用した peer.com

次のステップ