Name resolution order

Cloud DNS uses the following procedure to answer queries from Compute Engine virtual machine (VM) instances and Google Kubernetes Engine (GKE) nodes.

For Compute Engine VMs other than GKE nodes, Cloud DNS follows the VPC network resolution order to process queries it receives. Each VM must be configured to use the metadata server IP address (169.254.169.254) as its name server.

For GKE nodes:

  1. Cloud DNS first attempts to match a query using cluster-scoped response policies and private zones.

  2. Cloud DNS continues by following the VPC network resolution order.

Cluster-scoped response policies and private zones

  1. Match using rules in GKE cluster-scoped response policies. Cloud DNS scans all applicable GKE cluster-scoped response policies for a rule where the DNS name attribute matches as much of the query as possible. Cloud DNS uses longest-suffix matching to scan cluster-scoped response policies:

    1. If Cloud DNS finds a matching response policy rule and the rule serves local data, then Cloud DNS returns the local data as its response, completing the name resolution process.

    2. If Cloud DNS finds a matching response policy rule and the rule's behavior bypasses the response policy, then Cloud DNS continues to the next step.

    3. If Cloud DNS fails to find a matching response policy or if there isn't an applicable cluster-scoped response policy for the node, then Cloud DNS continues to the next step.

  2. Match records in cluster-scoped private zones. Cloud DNS scans all cluster-scoped managed private zones for a record that matches as much of the query as possible. Cloud DNS uses longest-suffix matching to find records in cluster-scoped private zones:

    1. If the most specific match for the query is a record in a cluster-scoped managed private zone, then Cloud DNS returns the record data as its response, completing the name resolution process.

    2. If the most specific match for the query is the zone name of a cluster-scoped forwarding zone, then Cloud DNS forwards the query to one of the forwarding zone's forwarding targets to complete the name resolution process. Cloud DNS returns one of the following responses:

      • The response received from the forwarding target.
      • A SERVFAIL response, if the forwarding target does not respond to Cloud DNS.

    3. If the query does not match any cluster-scoped private zone, Cloud DNS continues to the VPC network resolution order.

VPC network resolution order

  1. VPC network alternative name server: If the VPC network has an outbound server policy, Google Cloud forwards the query to one of the alternative servers defined in that policy to complete the name resolution process. Cloud DNS returns one of the following responses:

    • The response received from the alternative name server.
    • A SERVFAIL response, if the alternative name server does not respond to Cloud DNS.

    If the VPC network does not have an outbound server policy, Cloud DNS continues to the next step.

  2. Match using rules in VPC network-scoped response policies. Cloud DNS scans all applicable VPC network response policies for a rule where the DNS name attribute matches as much of the query as possible. Cloud DNS uses longest-suffix matching to scan network-scoped response policies:

    1. If Cloud DNS finds a matching response policy rule and the rule serves local data, then Cloud DNS returns the local data as its response, completing the name resolution process.

    2. If Cloud DNS finds a matching response policy rule and the rule's behavior bypasses the response policy, then Cloud DNS continues to the next step.

    3. If Cloud DNS fails to find a matching response policy or if there isn't an applicable network-scoped response policy for the VM or node, then Cloud DNS continues to the next step.

  3. Match records in VPC network-scoped managed private zones and Compute Engine .internal zones. Cloud DNS scans all applicable Compute Engine internal DNS zones and all managed private zones authorized for the VPC network for a record that matches as much of the query as possible. Cloud DNS uses longest-suffix matching to find records:

    1. If the most specific match for the query is a Compute Engine internal DNS name, Cloud DNS returns the internal IPv4 address of the VM's network interface as its response, completing the name resolution process. A record from a managed private zone only takes precedence over an automatically created Compute Engine internal DNS name when the record in the private zone is a more specific match.

    2. If the most specific match for the query is a record in a network-scoped managed private zone, Cloud DNS returns the record data as its response, completing the name resolution process.

    3. If the most specific match for the query is the zone name of a network-scoped forwarding zone, then Cloud DNS forwards the query to one of the forwarding zone's forwarding targets to complete the name resolution process. Cloud DNS returns one of the following responses:

      • The response received from the forwarding target.
      • A SERVFAIL response, if the forwarding target does not respond to Cloud DNS.

    4. If the most specific match for the query is the name of a network-scoped peering zone, Cloud DNS stops the current name resolution process and begins a new name resolution process from the perspective of the peering zone's target VPC network.

    If the query does not match any Compute Engine internal DNS name, or if the query doesn't match a private zone, forwarding zone, or peering zone, Cloud DNS continues to the next step.

  4. Match record using public DNS query: Google Cloud follows the start of authority (SOA) record to query publicly available zones, including Cloud DNS public zones. Cloud DNS returns one of the following responses:

    • The response received from an authoritative name server.
    • An NXDOMAIN response, if the record does not exist.

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