You can configure DNS routing policies for resource record sets in privateor publiczones to steer traffic based on specific criteria. Create resourcerecord 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 WRRrouting policy to assign different weights to each resource record set for aDNS name. A WRR routing policy helps ensure that traffic is distributedaccording to the configured weights.Combining WRR and geolocationrouting policies is not supported.

  Note: Resolvers might cache and serve responses to multiple clients untilthe resource record's time to live (TTL) expires. This inherent behavior ofDNS traffic steering might sometimes lead to inexact traffic steering.

• Geolocation routing policy: Use the geolocationrouting policy to specify source geolocations and to provide correspondingresponses to those geographies. The geolocation routing policy applies anearest match for the source location when no policy items exactly match thetraffic source.

  • Geolocation routing policy with a geofence: Usegeolocation routing policy with a geofence to restrict traffic to a specificgeolocation even if all endpoints in that geolocation are unhealthy.

• Failover routing policy: Use the failover routingpolicy to set up active backup configurations.

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 weightsper DNS target, and Cloud DNS ensures that your traffic is distributedaccording to the weights. You can use this policy to supportmanualactive-active oractive-passiveconfigurations. You canalso split traffic between production and experimental versions of your service.

Cloud DNS supports health checking and failovers within routingpolicies for internal load balancers and external endpoints.Cloud DNS enables automatic failover when the endpoints fail theirhealth checks. During a failover, Cloud DNSautomatically adjusts the traffic split among the remaining healthy endpoints.For more information, seeHealth checks.

Geolocation routing policies

A geolocation routing policy lets you map traffic originating from sourcegeographies (Google Cloud regions) to specific DNS targets. Use thispolicy to distribute incoming requests to different service instances based onthe traffic's origin. You can use this feature with traffic from outsideGoogle Cloud or with traffic originating within Google Cloud andbound for internal passthrough Network Load Balancers. Cloud DNS uses the region where thequeries enter Google Cloud as the source geography.

A geolocation routing policy maps the source differently for public and privateDNS in the following ways:

• For public DNS, the source IP address or theextension mechanism for DNS (EDNS)client subnet of the query is used.
• For private DNS, the EDNS client subnet is not used. Instead, the locationof the query is the location of the system that sends the packets forthe query:
  • For queries from a Compute Engine virtual machine (VM) instance with a networkinterface in a VPC network, the location of the queryis the region that contains the VM instance.
  • For queries received by aninbound server policy entrypoint, thelocation of the query is the region of the Cloud VPN tunnel,Cloud Interconnect VLAN attachment, or Router appliancethat received the packets for the query. The region of the IP addressof the entry point is not relevant. For more information, seeNetwork and region for inbound queries.

Cloud DNS supports health checking and failovers within routingpolicies for internal load balancers and external endpoints.Cloud DNS enables automatic failover when the endpoints fail theirhealth checks. When you use geolocation routing policies, the traffic failsover to the next closest geolocation to the source traffic.

Geolocation routing policy with geofence

A geofence helps ensure that traffic is directed to a specific region, even ifall endpoints within that region fail the health checks.

When geofencing is disabled and a health check failure occurs for a specificgeolocation, traffic automatically fails over to the next closest geolocation.However, when geofencing is enabled, this automatic failover doesn't occur.As an authoritative server, Cloud DNS must return a value, and in thisscenario, Cloud DNS returns all the IP addresses unaltered when theendpoints fail the health checks.

Failover routing policies

The failover routing policy lets you set up active backup configurations toprovide high availability for internal resources within yourVPC network.

In normal operation, Cloud DNS always returns the IPaddresses from theactive set. When all IP addresses in theactive setbecome unhealthy, Cloud DNS serves the IP addresses from thebackupset. If you configure thebackup set as a geolocation routing policy, itoperates as described in theGeolocation routing policiessection. If you configure thebackup set for an internal load balancer,Cloud DNS health checks all backup virtual IP (VIP) addresses.

Cloud DNS lets you graduallytrickle traffic to the backup VIP addressesso that you can verify that the backup VIP addresses are functioning. You canconfigure the percentage of the traffic sent to the backup as a fractionfrom 0 to 1. You can manually trigger a failover by sending 100% of the trafficto the backup VIP addresses. The typical value is 0.1. Health checks can beapplied only to internal load balancers and external endpoints.

Health checks

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

• Internal Application Load Balancers (regional and cross-region)
• Internal passthrough Network Load Balancers
• Internal proxy Network Load Balancers (Preview)
• External endpoints

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

For information about best practices to keep in mind when you configure theCloud DNS record and health checks,seeBest practices.

Health checks for internal load balancers

Health checks for internal load balancers are only available in privatezones.

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

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

A single internal passthrough Network Load Balancer virtual IP address (VIP) can have multiple backendinstances. If an internal passthrough Network Load Balancer doesn't have any backend instances, Cloud DNSstill considers it healthy. For health checking to work correctly, specify atleast 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 onlyhealthy 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 trafficproportionally among the remaining healthy endpoints defined in thepolicy.
  • For a geolocation policy that doesn't have fencing enabled, the trafficswitches to endpoints in the next closest geography to thesource Google Cloud region defined in the policy.
  • For a geolocation policy that has geofencing enabled, Cloud DNSdistributes the traffic to the VIP address that is closest to thesource Google Cloud region defined in the policy.
  • For a failover policy, Cloud DNS switches the traffic to thebackup endpoints defined in the policy.
  • If all policy buckets are unhealthy, Cloud DNS behaves as ifall endpoints are healthy. This scenario might potentially lead totraffic distributed to unresponsive endpoints.

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

Health checks for external endpoints

Health checks for external endpoints are only available in public zones. Theendpoints that you want to health check must be accessible over the publicinternet. The specified endpoint could be any external IP address and port,including a global external Application Load Balancer VIP, Regional external Application Load Balancer VIP,global external proxy Network Load Balancer VIP, on-premisesendpoints, or any other endpoint that is accessible over the public internet.

Use health checks for external endpoints in the following scenarios:

• To reroute traffic to a regional external Application Load Balancer if a global external Application Load Balancerbackend or a global external proxy Network Load Balancer backend becomes unhealthy.
• To reroute traffic to another regional external Application Load Balancer if a specificregional external Application Load Balancer's backend becomes unhealthy.
• To monitor the health of on-premises endpoints or other endpoints that arereachable on the public internet.

When you create DNS routing policy with health checks for externalendpoints, Cloud DNS sends health check probes to your endpoints. Thesehealth check probes originate from three Google Cloud source regions thatyou specify. Each region's health check probers run independently, andCloud DNS aggregates their results to determine the endpoint's overallhealth. Within each region, three health check prober instances probe eachendpoint. If one probe fails, Cloud DNS can still determine theendpoint's health by using the remaining probes. This means that you have nineprobers in total for each endpoint, and each probe occurs at the frequency thatyou specify in the health check's check interval. Based on the parametersof the routing policy and the health information, Cloud DNS selects anendpoint and routes traffic to the selected endpoint.

Cloud DNS supports the TCP, HTTP, and HTTPS protocols with thefollowing caveats:

• The TCP request field is not supported.
• TheproxyHeader field for HTTP, HTTPS, and TCP is not supported.

SSL, HTTP/2, and gRPC protocols are not supported.

For the TCP protocol, Cloud DNS attempts to connect to the endpoint.For the HTTP and HTTPS protocols, Cloud DNS verifies that the endpointreturns an HTTP response code200. You can also configure content-based healthchecking, where Cloud DNS checks that the response contains a specificstring.

Unlike health checking for internal load balancers, Cloud DNShealth checks for external endpoints don't originate from fixed IP address ranges.The probe source IP address ranges are subject to change over time.

The protocol and port that you specify when creating the health check determinehow health check probes are done. If you don't specify a port, Cloud DNSuses port80. To help ensure that health checks work correctly,configure your firewall rules to allow health check probes from any sourceIP address and on the specific port configured in the health check.

If you haven't configured your firewall to allow health check probes, the probesfail, so Cloud DNS considers the blocked endpoints as unhealthy. Ifevery endpoint is returned as unhealthy, Cloud DNS still provides allof them as a result, even though they are unhealthy.

Health check interval

Cloud DNS periodically sends health check probes according to thehealth 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 checkinterval 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. Whenhealth checks are included, the following occurs:

• If you configure multiple targets, all with weight 0, traffic is distributedequally among the targets.
• If you configure a new, non-zero weighted target, it then becomes theprimary target, and all traffic shifts to that target.
• As you add more targets with nonzero weights, Cloud DNSdynamically computes the traffic split among the targets (with each request)and distributes the traffic appropriately. For example, if you haveconfigured three targets with weights of 0, 25, and 75, the target with the0 weight gets no traffic, the target with a weight of 25 gets one-fourth ofthe traffic, and the remaining target gets three-fourths of the incomingtraffic.
• If health checks are associated with non-zero weighted targets but not withzero weighted targets, the zero weighted targets are always consideredhealthy. If all the non-zero records are unhealthy, Cloud DNSreturns the zero weighted records.
• If health checks are associated with both non-zero and zero weightedrecords, and if all the records are failing health checks,Cloud DNS returns any non-zero weighted targets and ignoresthe 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 isreturned. If you only specify one IP address in the weight bucket, only thatIP address is in the response. If there is more than one IP address in theweight bucket, Cloud DNS returns all the IP addresses in arandomized order.

Geolocation routing policies and health checks

For geolocation routing policies with health checks enabled, the following occurs:

• When a policy has multiple IP addresses configured, and all the IP addresseshave health checking, only the healthy IP addresses are returned.
• When there's a mix and match of health-checked and non-health-checked IPaddresses, and all the health-checked IP addresses fail, Cloud DNSreturns all the IP addresses that don't have health checking configured. Inthis scenario, automatic failover to the next nearest geography doesn'toccur.

Health check logging

Cloud DNS supports health check logging and logs the health status ofyour health-check-enabled IP addresses when you query the DNS name that refersto those IP addresses.

Health check logging lets you do the following:

• Validate whether the routing policies are performing as expected. Forexample:
  • For geolocation policies, it lets you validate whether the policies detectthe correct geography and return the correct resource record dataset.
  • For WRR policies, it lets you validate if the policies are returningthe IP addresses in the correct weightage.
• Identify infrastructure issues with specific backends and IP addresses thathave failures.
• Troubleshoot why specific backends are never included or are the only onesthat are being returned.

For more information, seehealth check logging information.

Supported record types for DNS routing policies

DNS routing policies don't support all therecord types that aresupported by Cloud DNS.

The following record types are supported:

What's next

• Configure DNS routing policies and health checks