DNS policies overview

Cloud DNS supports different types of policies. This page provides details about the different policy types and when you can use one or the other.

  • Server policies apply private DNS configuration to a Virtual Private Cloud (VPC) network (DNS forwarding, logging).
  • Response policies override private DNS responses based on the query name.
  • Routing policies steer traffic based on query (for example, round robin, geolocation).

You can use all three policies at the same time depending on your needs.

Server policies

Use server policies to set up hybrid deployments for DNS resolutions. You can set up an inbound server policy depending on the direction of DNS resolutions. If your workloads plan to use an on-premises DNS resolver, you can set up DNS forwarding zones by using an outbound server policy. On the other hand, if you want your on-premises workloads to resolve names on Google Cloud, you can set up an inbound server policy.

For detailed information about server policies, see the Server policies overview.

To configure and apply DNS server policies, see Apply DNS server policies.

Response policies

A response policy is a Cloud DNS private zone concept that contains rules instead of records. These rules can be used to achieve effects similar to the DNS response policy zone (RPZ) draft concept (IETF). The response policy feature lets you introduce customized rules in DNS servers within your network that the DNS resolver consults during lookups. If a rule in the response policy affects the incoming query, it is processed. Otherwise, the lookup proceeds normally. For more information, see Manage response policies and rules.

A response policy is different from an RPZ, which is an otherwise normal DNS zone with specially formatted data that causes compatible resolvers to do special things. Response policies are not DNS zones and are managed separately in the API. To create and modify response policies in Cloud DNS, use the ResponsePolicies API. Response policies are separate from ManagedZones and cannot be managed by using either the ManagedZones API or the RRSet API.

Routing policies

DNS routing policies let you steer your traffic based on specific criteria. Cloud DNS also supports health checking and automatic failovers embedded into each routing policy. Health checking is available for internal passthrough Network Load Balancers and internal Application Load Balancers that have global access enabled, and cross-region internal Application Load Balancers.

Cloud DNS supports the following routing policies:

  • Weighted round robin routing policy
  • Geolocation routing policy
  • Geofenced routing policy
  • Failover routing policy

Only one type of routing policy can be applied to a resource record set at a time. You cannot combine routing policies except when configuring a failover routing policy, in which you can set a geolocation routing policy as the backup.

Weighted round robin routing policies

A weighted round robin (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 software.

Health checking is available by default if the targets are internal passthrough Network Load Balancers. This enables automatic failover when the endpoints fail their health checks. In the case of a failover, the traffic split is automatically adjusted among the remaining healthy endpoints. For more details, see Health checks.

Geolocation routing policies

A geolocation (GEO) routing policy lets you map traffic originating from source geographies (Google Cloud regions) to specific DNS targets. Use this policy to distribute incoming requests to different service instances based on the traffic's origin. You can use this feature with the internet, with external traffic, or with traffic originating within Google Cloud and bound for internal passthrough Network Load Balancers. Cloud DNS uses the region where the queries enter Google Cloud as the source geography.

Health checking is available by default if the target is internal passthrough Network Load Balancer, internal Application Load Balancer, or cross-region internal Application Load Balancer. This enables automatic failover when the endpoints fail their health checks. In the case of geolocation, the traffic fails over to the next closest geolocation to the source traffic.

Geofenced routing policies

Health checking enables the geofenced routing policy type where you can restrict the traffic to a specific geolocation even if all the endpoints in that geolocation are unhealthy. In a geolocation policy, when health check failures are observed for a specific geo bucket, the traffic automatically fails over to the next closest geolocation. When geofencing is enabled, the automatic failover does not happen. As an authoritative server, Cloud DNS must return a value, and in this scenario, Cloud DNS returns all the IP addresses unaltered when they fail their 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. You can configure a failover routing policy only for private zones.

In normal operation, the IP addresses provisioned in the active set are always returned. When all the IP addresses in the active set fail (health status changes to unhealthy), Cloud DNS starts serving the IP addresses in the backup set. You can configure the backup set as geolocation policies, and they behave the same as described in the geolocation policies section. If configured as internal passthrough Network Load Balancer, internal Application Load Balancer, or cross-region internal Application Load Balancer, all of the backup virtual IP (VIP) addresses are also health checked.

Cloud DNS lets you gradually trickle traffic to the backup VIP addresses so that you can be sure 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. The typical value must be 0.1, although Cloud DNS lets you send 100% of the traffic to the backup VIP addresses, to manually trigger a failover. Health checks can only be applied to internal load balancers, therefore, all configured VIP addresses must be either internal passthrough Network Load Balancers, internal Application Load Balancers, or cross-region internal Application Load Balancers.

Health checks

Cloud DNS supports health checks for internal passthrough Network Load Balancers and internal Application Load Balancers that have global access enabled, and cross-region internal Application Load Balancers.

Health checks for private load balancers are only available in private managed zones. Health checks are not available for forwarding, peering, and managed reverse lookup zones.

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

Health checks for internal passthrough Network Load Balancers

Cloud DNS determines the health state of an internal passthrough Network Load Balancer by using the load balancer's built-in health check configuration. Cloud DNS considers the internal passthrough Network Load Balancer to be healthy and eligible to receive traffic when at least 20% of health checks are successful.

For an internal passthrough Network Load Balancer, Cloud DNS gets direct health signals from the individual backend instances and a thresholding algorithm is applied to determine whether an endpoint is healthy or not.

A single internal passthrough Network Load Balancer virtual IP address can have multiple services running behind it. Cloud DNS looks for health signals from the protocol and port specified in the health checking configuration for the load balancer. For detailed information about health checks, see Health checks overview.

For internal Application Load Balancer and cross-region internal Application Load Balancer, 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 ensure 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.

Weighted round robin 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 non-zero 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 completely avoids 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.

Geolocation policy with health checking

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

  • When a geo bucket has multiple IP addresses configured, and all the IP addresses have health checking, only the healthy IP addresses are returned.
  • If there's a mix and match of health checking versus no health checking, and all the health checked IP addresses fail, Cloud DNS returns all the IP addresses that did not have health checking configured. In this scenario, automatic failover to the next nearest geography does not occur.
  • This policy automatically routes traffic to the next nearest geo bucket when:
    • All the IP addresses in a geo bucket have health checking enabled.
    • The policy has fencing disabled.
    • All of the IP addresses fail health checks. This lets you have automatic failover to the next nearest geo target.

Health check logging

Cloud DNS supports health check logging and logs the health check status of any backend changes. It lets you do the following:

  • Validate whether the routing policies are performing as expected. For example:
    • For GEO policies, it lets you validate if the policies are detecting the right geography and returning the right RR dataset.
    • 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.

To create, edit, or delete DNS routing policies, see Manage DNS routing policies and health checks.

Supported record types for DNS routing policies

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

Record type Description
A IPv4 addresses
AAAA IPv6 addresses
CNAME Canonical names
MX Mail exchange records
SRV Host/port (RFC 2782)
TXT Text data