Name resolution order

Private Cloud DNS resources such as zones, server policies, and response policies can be scoped to Virtual Private Cloud (VPC) networks or Google Kubernetes Engine (GKE) clusters. DNS resources can be bound to multiple scopes simultaneously. More specific scopes, like GKE clusters, are selected over less specific scopes, like VPC networks. For more information about scopes, see Scopes and hierarchies.

Each VPC network (or GKE cluster configured to use Cloud DNS) provides DNS name resolution services to the virtual machine (VM) instances that use it. When VMs use their metadata server 169.254.169.254 as their name server, Google Cloud searches for DNS records in the following order (starting with cluster-scoped resources in the case of a GKE cluster):

  • If your scope has an outbound server policy, Google Cloud forwards all DNS queries to those alternative servers. The name resolution order consists only of this step.

  • If your scope does not have an outbound server policy:

    1. Google Cloud looks for a response policy that matches as much of the requested record as possible (longest suffix matching). Response policies result in either modified resource records being served, or passthru. If the response policy's action is passthru, Google Cloud continues to the next step as if the policy did not exist. This is true even if there is a wildcard record in the policy that would result in local data being served.

    2. Google Cloud tries to find a private zone that matches as much of the requested record as possible (longest suffix matching). This includes the following:

      • Searching records that you created in private zones
      • Querying the forwarding targets for forwarding zones
      • Querying the name resolution order of another VPC network by using peering zones.

    3. Google Cloud searches the automatically created Compute Engine internal DNS records for the project. Private zones are selected over the automatically-created Compute Engine internal DNS zones only if those private zones are strictly more specific than the Compute Engine zones.

    4. Google Cloud follows the start of authority (SOA) record to query publicly available zones, which include Cloud DNS public zones.

    5. Cloud DNS checks the .internal Compute Engine DNS zone for name resolution before it checks a DNS peering zone that is defined for the root (.) domain.

Example

Suppose that you have two VPC networks, vpc-a and vpc-b, and a GKE cluster, cluster-a, along with the following scoped resources:

  1. vpc-a is authorized to query the following private zones. Note the trailing dot in each entry:

    • static.example.com.
    • 10.internal.

  2. peer.com. is a peering zone that can query the VPC name resolution order of vpc-b.

  3. vpc-a is not associated with any outbound server or response policies.

  4. cluster-a is authorized to query a private zone called example.com. cluster-a is also not associated with any outbound server or response policies.

  5. A VM in cluster-a can query:

    • example.com and children (including static.example.com), answered by the private zone called example.com, authorized to cluster-a.
    • 10.internal on vpc-a.
    • peer.com by using the peering zone.

  6. A VM that is not in cluster-a can query:

    • static.example.com and children, answered by the private zone called static.example.com authorized to vpc-a. Queries for example.com return internet responses.
    • 10.internal on vpc-a.
    • peer.com by using the peering zone.

What's next