DNS routing policies and health checks

You can configure DNS routing policies for resource record sets in private zones to steer traffic based on specific criteria. Create resource record sets with specific routing policy values to set up these policies. These values determine how Cloud DNS routes query traffic.

Cloud DNS supports the following routing policies:

  • Weighted round robin (WRR) routing policy: Use a WRR routing policy to assign different weights to each resource record set for a DNS name. A WRR routing policy helps ensure that traffic is distributed according to the configured weights.

DNS routing policies can't be configured for the following private zones:

  • Forwarding zones
  • DNS peering zones
  • Managed reverse lookup zones
  • Service Directory zones

WRR routing policies

A WRR routing policy lets you specify different weights per DNS target, and Cloud DNS ensures that your traffic is distributed according to the weights. You can use this policy to support manual active-active or active-passive configurations. You can also split traffic between production and experimental versions of your service.

Cloud DNS supports health checking and failovers within routing policies for internal load balancers and external endpoints. Cloud DNS enables automatic failover when the endpoints fail their health checks. During a failover, Cloud DNS automatically adjusts the traffic split among the remaining healthy endpoints. For more information, see Health checks.

Failover routing policies

The failover routing policy lets you set up active backup configurations to provide high availability for internal resources within your VPC network.

In normal operation, Cloud DNS always returns the IP addresses from the active set. When all IP addresses in the active set become unhealthy, Cloud DNS serves the IP addresses from the backup set.

Cloud DNS lets you gradually trickle traffic to the backup VIP addresses so that you can verify that the backup VIP addresses are functioning. You can configure the percentage of the traffic sent to the backup as a fraction from 0 to 1. You can manually trigger a failover by sending 100% of the traffic to the backup VIP addresses. The typical value is 0.1. Health checks can be applied only to internal load balancers and external endpoints.

Health checks

Cloud DNS supports health checking and failovers within routing policies for the following internal load balancers and external endpoints:

When you want to use health checking with a managed zone and DNS Security Extensions (DNSSEC) is enabled, only a single IP address can be used within each policy item . You cannot mix health-checked IP addresses and non-health-checked IP addresses in a specific policy.

For information about best practices to keep in mind when you configure the Cloud DNS record and health checks, see Best practices.

Health checks for internal load balancers

Health checks for internal load balancers are only available in private zones.

For internal Application Load Balancers and internal proxy Network Load Balancers, Cloud DNS considers the health of the load balancer itself during the routing decision. When a load balancer receives a query, it distributes traffic only to the healthy backend services. To help ensure that there are healthy backends, you can manage the lifecycle of the backends by using services such as managed instance groups (MIGs). Cloud DNS doesn't need to be aware of the health status of individual backends; the load balancer handles this task.

For internal passthrough Network Load Balancers, Cloud DNS checks the health information on the load balancer's individual backend instances. Cloud DNS applies a default 20% threshold, and if at least 20% of backend instances are healthy, the load balancer endpoint is considered healthy. DNS routing policies mark the endpoint as healthy or unhealthy based on this threshold, and route traffic accordingly.

A single internal passthrough Network Load Balancer virtual IP address (VIP) can have multiple backend instances. If an internal passthrough Network Load Balancer doesn't have any backend instances, Cloud DNS still considers it healthy. For health checking to work correctly, specify at least one backend instance within the load balancer configuration.

When the endpoint is marked unhealthy, the following conditions can occur:

  • If there are multiple VIP addresses programmed against a policy, then only healthy VIP addresses are returned.

  • If all the VIP addresses programmed against a policy bucket are unhealthy, that policy line has failed. The following behavior applies:

    • For a WRR policy, Cloud DNS distributes the traffic proportionally among the remaining healthy endpoints defined in the policy.
    • For a failover policy, Cloud DNS switches the traffic to the backup endpoints defined in the policy.
    • If all policy buckets are unhealthy, Cloud DNS behaves as if all endpoints are healthy. This scenario might potentially lead to traffic distributed to unresponsive endpoints.

For more information about health checks for internal load balancers, see Health checks overview.

Health check interval

Cloud DNS periodically sends health check probes according to the health check interval. For example, if the health check interval is 30 seconds, Cloud DNS sends one health check probe every 30 seconds.

For Cloud DNS external endpoint health checking, the health check interval must be between 30 and 300 seconds.

Weighted round robin routing policies and health checks

Cloud DNS supports weights from 0 to 1000, inclusive of both. When health checks are included, the following occurs:

  • If you configure multiple targets, all with weight 0, traffic is distributed equally among the targets.
  • If you configure a new, non-zero weighted target, it then becomes the primary target, and all traffic shifts to that target.
  • As you add more targets with nonzero weights, Cloud DNS dynamically computes the traffic split among the targets (with each request) and distributes the traffic appropriately. For example, if you have configured three targets with weights of 0, 25, and 75, the target with the 0 weight gets no traffic, the target with a weight of 25 gets one-fourth of the traffic, and the remaining target gets three-fourths of the incoming traffic.
  • If health checks are associated with non-zero weighted targets but not with zero weighted targets, the zero weighted targets are always considered healthy. If all the non-zero records are unhealthy, Cloud DNS returns the zero weighted records.
  • If health checks are associated with both non-zero and zero weighted records, and if all the records are failing health checks, Cloud DNS returns any non-zero weighted targets and ignores the zero weighted targets.
  • When Cloud DNS chooses a weight bucket to return to the requestor (a single policy item), only the IP address in that weight bucket is returned. If you only specify one IP address in the weight bucket, only that IP address is in the response. If there is more than one IP address in the weight bucket, Cloud DNS returns all the IP addresses in a randomized order.

Health check logging

Cloud DNS supports health check logging and logs the health status of your health-check-enabled IP addresses when you query the DNS name that refers to those IP addresses.

Health check logging lets you do the following:

  • Validate whether the routing policies are performing as expected. For example:
  • For WRR policies, it lets you validate if the policies are returning the IP addresses in the correct weightage.
  • Identify infrastructure issues with specific backends and IP addresses that have failures.
  • Troubleshoot why specific backends are never included or are the only ones that are being returned.

    • For more information, see health check logging information.

    Supported record types for DNS routing policies

    DNS routing policies don't support all the record types that are supported by Cloud DNS.

    The following record types are supported:

    Record type Description
    A IPv4 addresses for internal (private zone) health checks.
    CNAME Canonical names. Health checks are not supported.
    MX Mail exchange records. Health checks are not supported.
    SRV Host/port (RFC 2782). Health checks are not supported.
    TXT Text data. Health checks are not supported.

    What's next