Manage DNS routing policies and health checks

DNS routing policies steer traffic based on query type (for example, weighted round robin or geolocation). You can configure these policies by creating resource record sets that contain specific routing policy values. These values determine how traffic is routed. For example, in a weighted round robin policy, each resource record set has an assigned weight that affects traffic distribution.

This page provides information about creating, editing, and deleting DNS routing policies, and enabling health checking by using Cloud DNS. Before you use this page, familiarize yourself with the DNS policies overview.

Permissions required for this task

To perform this task, you must have been granted the following permissions or the following IAM roles.

Permissions

dns.networks.useHealthSignals to create a policy with health checks for internal passthrough Network Load Balancers
dns.changes.create to create a resource record set
dns.managedZones.list to list managed zones

Roles

roles/dns.admin
roles/dns.peer

To use DNS routing policies, create a resource record set and choose one of the following DNS routing policies to apply to the resource record set:

Weighted round robin (WRR) routing policy: Use WRR to specify different weights per resource record set for the DNS name. DNS routing policies ensure that traffic is distributed according to the configured weights. Combining a WRR routing policy with a geolocation routing policy is not supported.

Note: Traffic steering might be inexact due to the behavior of resolver caches. Each response might be cached and served to many clients by using the same resolver until the TTL expires. This is an inherent limitation of DNS traffic steering.
Geolocation (GEO) routing policy: Use GEO to specify source geolocations and to provide answers corresponding to those geographies. The geolocation routing policy applies a nearest match for the source location when the source of the traffic doesn't match any policy items exactly.

GEO maps the source for public and private DNS in the following ways:
- For public DNS: the source IP address or Extension mechanism for DNS (EDNS) client subnet of the query is used.
- For private DNS, EDNS client subnet is not used. Instead, the location of the query is the location of the system that sends the packets for the query:
  - For queries from a virtual machine (VM) instance with a network interface in a VPC network, the location of the query is the region that contains the VM.
  - For queries received by an inbound server policy entry point, the location of the query is the region of the Cloud VPN tunnel, Cloud Interconnect VLAN attachment, or Router appliance that received the packets for the query. The region of the entry point IP address is not relevant. For more information, see Network and region for inbound queries on the "DNS server policies" page.
Geofenced routing policy: Use geofencing to restrict traffic to a specific geolocation even if all endpoints in that geolocation are unhealthy. For detailed information about geofencing, see Geofenced routing policies.
Failover routing policy: Use failover to set up active backup configurations. For details, see Failover routing policies.

DNS routing policies also support multiple IP addresses for each geographic location. When specified for a given geographic location, multiple IP addresses are returned according to an equal weight WRR policy. Combining̦ a geo-based routing policy with a custom-weighted WRR policy is not supported.

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.

After setting up an internal passthrough Network Load Balancer, set up the appropriate routing policy within Cloud DNS by using the Google Cloud console,̦ gcloud CLI, or the API, specifying the internal passthrough Network Load Balancer. This step involves setting up multiple WRR or GEO buckets and each bucket can contain multiple internal passthrough Network Load Balancers.

For internal passthrough Network Load Balancers, Cloud DNS checks the health information on the load balancer's individual backend instances to determine if the load balancer is healthy or unhealthy. 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, routing traffic accordingly.

For internal Application Load Balancers and cross-region internal Application Load Balancers, Cloud DNS checks the overall health of the internal Application Load Balancer, and lets the internal Application Load Balancer itself check the health of the backend instances.

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 to the next healthy weight bucket.
- For a GEO policy that does not have fencing enabled, the traffic switches to the next nearest geography.
- For a geofenced policy that has fencing enabled, the VIP addresses in the nearest geo bucket are returned as-is.
- For a failover policy, Cloud DNS switches the traffic to the failover bucket.
- If all policy buckets are unhealthy, Cloud DNS behaves as if all endpoints are healthy.

Before you begin

This procedure assumes that you've completed the following:

Created a managed zone and completed the prerequisites for creating a zone.
Set up one of the following internal load balancers:
Created forwarding rules for the internal load balancer.
Set up health checking for the internal load balancer.

Create DNS routing policies

To create a resource record set and apply a routing policy to it, follow these steps.

Console

Start the configuration

In the Google Cloud console, go to the Cloud DNS zones page.

Go to Cloud DNS zones
Click the name of the managed zone that you want to add the record to.
On the Zone details page, click Add with routing policy.

Base data

On the Create record set with routing policy page, in the DNS name field, enter the subdomain of the DNS zone—for example, mail. The trailing dot is automatically added at the end.

Note: Adding the @ symbol in this field causes the record to fail.
Select the Resource record type—for example, A.
In the TTL field, enter a numeric value for the resource record's time to live, which is the amount of time that it can be cached. This value must be a positive integer.
In the TTL unit menu, select the unit of time—for example, 30 minutes.
Click Next.

Routing policy type

In the Routing policy list, select Weighted round robin, Geolocation, or Failover.
Click Next.

Routing policy data

If you selected Weighted round robin, in the Weighted round robin policy routing data section, do the following:
1. In the Weight field, enter the weight corresponding to this subsection of the resource record (RR) data. This weight should be a non-negative number from 0.0 to 1000.0. Ratio of traffic routed to the target is calculated from the ratio of individual weight over the total across all weights.
2. In the Add health checked target section, do the following:
  1. In the Project list, select the project where the forwarding rule exists.
  2. In the Type list, select internal passthrough Network Load Balancer, internal Application Load Balancer, or cross-region internal Application Load Balancer.
  3. In the Forwarding rule list, select a forwarding rule.
    
    The forwarding rule specifies an internal IP address, port, and a regional backend service or an HTTP(S) proxy. For Cloud DNS to work with health checks, you must enable global access for the internal load balancer.
3. To allow IPv4 addresses without health checking, select Allow IPv4 addresses without health checking.
4. In the IPv4 Address field, enter an IPv4 address.
If you selected Geolocation, do the following:
1. For Geo fencing, select Disabled or Enabled. Enabling geo fencing restricts the traffic to a specific geolocation even if all the endpoints in that geolocation are unhealthy.
2. In the Source region menu, select a valid Google Cloud source region, such as asia-east1.
3. In the Add health checked target section, do the following:
  1. In the Project list, select the project where the forwarding rule exists.
  2. In the Type list, select internal passthrough Network Load Balancer, internal Application Load Balancer, or cross-region internal Application Load Balancer.
  3. In the Forwarding rule list, select a forwarding rule.
    
    The forwarding rule specifies an internal IP address, port, and a regional backend service or an HTTP(S) proxy. For Cloud DNS to work with health checks, you must enable global access for the internal load balancer.
4. To allow IPv4 addresses without health checking, select Allow IPv4 addresses without health checking.
5. In the IPv4 Address field, enter an IPv4 address.
If you selected Failover, do the following:

Note: You can configure a failover routing policy only for private zones.
1. In the Trickle traffic (%) field, enter the percentage of the traffic sent to the failover targets, regardless of the health check status of the primary targets.
2. In the Primary targets section, do the following:
  1. In the Project list, select the project where the forwarding rule exists.
  2. In the Type list, select internal passthrough Network Load Balancer, internal Application Load Balancer, or cross-region internal Application Load Balancer.
  3. In the Forwarding rule list, select a forwarding rule.
    
    The forwarding rule specifies an internal IP address, port, and a regional backend service or an HTTP(S) proxy. For Cloud DNS to work with health checks, you must enable global access for the internal load balancer.
3. In the Backup geolocation policy section, do the following:
  1. For Geo fencing, select Disabled or Enabled. Enabling geo fencing restricts the traffic to a specific geolocation even if all the endpoints in that geolocation are unhealthy.
  2. In the Source region menu, select a valid Google Cloud source region, such as asia-east1.
  3. In the Add health checked target section, do the following:
    1. In the Project list, select the project where the forwarding rule exists.
    2. In the Type list, select internal passthrough Network Load Balancer, internal Application Load Balancer, or cross-region internal Application Load Balancer.
    3. In the Forwarding rule list, select a forwarding rule.
    When all primary IP addresses are unhealthy, traffic is automatically handled according to the backup geolocation policy.
4. To allow IPv4 addresses without health checking, select Allow IPv4 addresses without health checking.
5. In the IPv4 Address field, enter an IPv4 address.
Click Next.

Review and create

Click Review.
Review your Cloud DNS record set with routing policy configuration.
Optional: Click Equivalent comment line to view the gcloud CLI command to create this record set with routing policy.
Click Create.

gcloud

A ResourceRecordSet can contain a routingPolicy or rrdatas, but not both. Changing between rrdatas or routingPolicy is supported when updating ResourceRecordSets. For example, if you want to update a ResourceRecordSet that contains rrdatas, you can delete the rrdatas and add a routingPolicy to the same ResourceRecordSet.

To create a ResourceRecordSet and apply a routing policy to it, follow these steps.

Run the gcloud dns record-sets create command.

For GEO policies

gcloud dns record-sets create RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=GEO \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-health-checking

For WRR policies

gcloud dns record-sets create RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=WRR \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-health-checking

For geofenced policies

gcloud dns record-sets create RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=GEO \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-geo-fencing
    --enable-health-checking

For failover policies

gcloud dns record-sets create RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=FAILOVER \
    --enable-geo-fencing \
    --routing-policy-primary-data=ROUTING_POLICY_PRIMARY_DATA \
    --routing-policy-backup-data-type=ROUTING_POLICY_BACKUP_DATA_TYPE \
    --routing-policy-backup-data=ROUTING_POLICY_BACKUP_DATA \
    --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO \
    --enable-health-checking

Replace the following:

RRSET_NAME: the DNS name that matches the incoming queries with this zone's DNS name as its suffix, such as service.example.com
TTL: the TTL in seconds that the resolver caches this ResourceRecordSet, such as 30
RRSET_TYPE: the resource record type of this ResourceRecordSet, such as A

For a list of supported record types, see Select resource record types.
MANAGED_ZONE: the managed zone that this ResourceRecordSet is affiliated with, such as service-zone. The name of this ResourceRecordSet must have the DNS name of the managed zone as its suffix
ROUTING_POLICY_TYPE: the type of routing policy

Enter WRR for weighted round robin, GEO for geo-location, or FAILOVER for failover policies. You cannot modify this field after a policy has a chosen type; you can only delete the policy and add a new policy with the different type.
ROUTING_POLICY_DATA: the routing policy data
- For --routing-policy-type=WRR, enter a semicolon-delimited list in the format ${weight_percent}:${rrdatas}, such as .8=203.0.113.1;.2=198.51.100.1. Specify the weight as a non-negative decimal. The ratio of traffic routed to the target is calculated from the ratio of individual weight over the total across all weights. Forwarding rule names are acceptable values and result in health checking.
- For --routing-policy-type=GEO, enter a semicolon-delimited list in the format ${region}=${IP_address}, such as asia-east1=198.51.100.1;us-central1=203.0.113.1. You can specify multiple IP addresses for a single region by adding IP addresses separated by a comma. Forwarding rule names are acceptable values and result in health checking.
- For --routing-policy-type=FAILOVER, enter the name of the forwarding rule that you created in the format ${region}=${Forwarding rule name}.
  
  Note: When health checks are disabled, the rrdata for WRR or GEO can be RFC 1035 format DNS rrdata.
  When health checks are enabled, the rrdata is a reference to a forwarding rule. Cloud DNS uses the IP address of the forwarding rule as the rrdata. Cloud DNS monitors the health status of the forwarding rule and removes the forwarding rule from the results if it becomes unhealthy.
You must specify both the routing policy type and the routing policy data. If you specify one, you cannot leave the other flag unpopulated.
--enable-geo-fencing: for GEO routing policies, this determines whether traffic should failover across regions if all endpoints in a region are unhealthy. When set, Cloud DNS always directs queries to the nearest region, even if all endpoints in that region are unhealthy. Use --no-enable-geo-fencing to disable geofencing. When unset, Cloud DNS directs queries to the next nearest region when all endpoints in a region are unhealthy. This defaults to false.
ROUTING_POLICY_PRIMARY_DATA: the primary target to use for FAILOVER routing policies. This target must be a reference to one or more forwarding rules, such as forwarding-rule-1. As long as at least one of these forwarding rules is healthy, the IP addresses of all healthy forwarding rules are used to answer queries for this name.
ROUTING_POLICY_BACKUP_DATA: the backup target to use for FAILOVER routing policies. These targets are used when all forwarding rules specified in --routing-policy-primary-data are unhealthy. Cloud DNS only supports geo-based backup targets. The format of this field matches that of --routing-policy-data when --routing-policy-type = 'GEO', such as asia-east1=forwarding-rule-2.
ROUTING_POLICY_BACKUP_DATA_TYPE: for FAILOVER routing policies, the type of routing policy the backup data uses. This must be GEO.
BACKUP_DATA_TRICKLE_RATIO: the ratio of traffic to send to the backup targets, even when the primaries are healthy. The ratio must be between 0 and 1, such as 0.1. The default is set to 0.
--enable-health-checking: the flag to enable health checking. When you use this flag, you must provide the forwarding rule name instead of the IP address in the --routing-policy-data field.

API

Use the resourceRecordSets.create method.

For GEO policies

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
            "name": "RRSET_NAME",
            "type": "RRSET_TYPE",
            "ttl": TTL,
            "routingPolicy": {
          "geo": {
              "items": [
              {
                  "location": "LOCATION",
                  "healthCheckedTargets": {
                     "internalLoadBalancers": [
                      {
                       "loadBalancerType": "LOAD_BALANCER_TYPE"
                       "ipAddress": "IP_ADDRESS"
                       "port" : "PORT_NUMBER"
                       "ipProtocol": "IP_PROTOCOL"
                       "networkUrl": "NETWORK_URL"
                       "project": "PROJECT"
                       "region": "REGION"
                      }
                     ]
                  }
              },
              {
                  "location": "LOCATION",
                  "healthCheckedTargets": {
                     "internalLoadBalancers": [
                      {
                       "loadBalancerType": "LOAD_BALANCING_TYPE"
                       "ipAddress": "IP_ADDRESS"
                       "port" : "PORT_NUMBER"
                       "ipProtocol": "IP_PROTOCOL"
                       "networkUrl": "NETWORK_URL"
                       "project": "PROJECT"
                       "region": "REGION"
                      }
                     ]
                  }
              },
              }
           ]

        }
     }
}

For WRR policies

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
  "name": "RRSET_NAME",
        "type": "RRSET_TYPE",
        "ttl": TTL,
  "routingPolicy": {
    "wrr": {
      "items": [
        {
          "weight": WEIGHT,
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "LOAD_BALANCER_TYPE"
                "ipAddress": "IP_ADDRESS"
                "port" : "PORT_NUMBER"
                "ipProtocol": "IP_PROTOCOL"
                "networkUrl": "NETWORK_URL"
                "project": "PROJECT"
                "region": "REGION"
              }
            ]
          }
        },
        {
          "weight": WEIGHT,
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "LOAD_BALANCER_TYPE"
                "ipAddress": "IP_ADDRESS"
                "port" : "PORT_NUMBER"
                "ipProtocol": "IP_PROTOCOL"
                "networkUrl": "NETWORK_URL"
                "project": "PROJECT"
                "region": "REGION"
              }
            ]
          }
        },
      ]
    }
  }
}

For FAILOVER for GEO policies

In the failover option, Cloud DNS only supports GEO policies.

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
  "name": "RRSET_NAME",
        "type": "RRSET_TYPE",
        "ttl": TTL,
  "routingPolicy": {
    "primaryBackup": {
      "trickleTraffic": TRICKLE_TRAFFIC,
      "primaryTargets": {
        "internalLoadBalancers": [
          {
            "ipAddress": "IP_ADDRESS"
            "ipProtocol": "IP_PROTOCOL"
            "loadBalancerType": "LOAD_BALANCER_TYPE"
            "networkUrl": "NETWORK_URL"
            "port": "PORT_NUMBER"
            "project": "PROJECT"
            "region": "REGION"
           }
         ]
       },
       "backupGeoTargets": {
         "enableFencing": ENABLE_FENCING,
         "items": [
           {
             "location": "LOCATION",
             "rrdatas": [
               "RRDATA"
             ]
           },
           {
             "location": "LOCATION",
             "rrdatas": [
               "RRDATA"
             ]
           }
         ]
       }
     },
   }
}

Replace the following:

PROJECT_ID: the ID of the project
MANAGED_ZONE: the managed zone that this ResourceRecordSet is affiliated with, such as service-zone; the name of this ResourceRecordSet must have the DNS name of the managed zone as its suffix
RRSET_NAME: the DNS name that matches the incoming queries with this zone's DNS name as its suffix, such as service.example.com
RRSET_TYPE: the resource record type of this ResourceRecordSet, such as A
TTL: the TTL in seconds that the resolver caches this ResourceRecordSet, such as 30
TRICKLE_TRAFFIC: the ratio of traffic to send to the backup targets even when the primaries are healthy; the ratio must be between 0 and 1, such as 0.1
ENABLE_FENCING: for GEO routing policies, this determines whether traffic should failover across regions if all endpoints in a region are unhealthy. When set, Cloud DNS always directs queries to the nearest region, even if all endpoints in that region are unhealthy. When unset, Cloud DNS directs queries to the next nearest region when all endpoints in a region are unhealthy. This defaults to false.
LOCATION: for GEO policies, the geolocation for which you need to create the policy, such as asia-east1
WEIGHT: for WRR policies, a semicolon-delimited list in the format ${weight_percent}=${rrdatas}, such as .8=10.128.1.1;.2=10.130.1.1; specify the weight as any non-negative decimal
Note: You must specify weight as a non-negative number. The ratio of traffic routed to the target is calculated from the ratio of individual weight over the total across all weights.
RR_DATA: an arbitrary value associated with the resource record set, such as 198.51.100.5; you can also enter multiple values, rrdata1 rrdata2 rrdata3, such as 198.51.100.1 203.0.113.1...
LOAD_BALANCER_TYPE: the type of load balancer, such as regionalL4ilb
IP_ADDRESS: the IP address that the forwarding rule serves
PORT_NUMBER: the port number
IP_PROTOCOL: defines the protocol used for the health check; valid options are tcp and udp
NETWORK_URL: the network URL to which this forwarding rule applies
REGION: the region in which you created the forwarding rule

Update DNS routing policies

To update a resource record set's routing policy, follow these steps.

Console

In the Google Cloud console, go to the Cloud DNS zones page.

Go to Cloud DNS zones
Click the zone for which you want to update the resource record set's routing policy.
On the Zone details page, next to the resource record set that you want to update, click Edit.
After making the necessary updates, click Save.

gcloud

Run the gcloud dns record-sets update command:

For GEO policies

gcloud dns record-sets update RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=GEO \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-health-checking

For WRR policies

gcloud dns record-sets update RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=WRR \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-health-checking

For geofenced policies

gcloud dns record-sets update RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=GEO \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-geo-fencing
    --enable-health-checking

For failover policies

gcloud dns record-sets update RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=FAILOVER \
    --enable-geo-fencing \
    --routing-policy-primary-data=ROUTING_POLICY_PRIMARY_DATA \
    --routing-policy-backup-data=ROUTING_POLICY_BACKUP_DATA \
    --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO \
    --enable-health-checking

Replace the following:

RRSET_NAME: the DNS name that matches the incoming queries with this zone's DNS name as its suffix, such as service.example.com
TTL: the TTL in seconds that the resolver caches this ResourceRecordSet, such as 30
RRSET_TYPE: the resource record type of this ResourceRecordSet, such as A

For a list of supported record types, see Select resource record types.
MANAGED_ZONE: the managed zone that this ResourceRecordSet is affiliated with, such as service-zone. The name of this ResourceRecordSet must have the DNS name of the managed zone as its suffix
ROUTING_POLICY_TYPE: the type of routing policy

Enter WRR for weighted round robin, GEO for geo-location, or FAILOVER for failover policies. You cannot modify this field after a policy has a chosen type; you can only delete the policy and add a new policy with the different type.
ROUTING_POLICY_DATA: the routing policy data
- For --routing-policy-type=WRR, enter a semicolon-delimited list in the format ${weight_percent}:${rrdatas}, such as .8=203.0.113.1;.2=198.51.100.1. Specify the weight as a non-negative decimal. The ratio of traffic routed to the target is calculated from the ratio of individual weight over the total across all weights. Forwarding rule names are acceptable values and result in health checking.
- For --routing-policy-type=GEO, enter a semicolon-delimited list in the format ${region}=${IP_address}, such as asia-east1=198.51.100.1;us-central1=203.0.113.1. You can specify multiple IP addresses for a single region by adding IP addresses separated by a comma. Forwarding rule names are acceptable values and result in health checking.
- For --routing-policy-type=FAILOVER, enter the name of the forwarding rule that you created in the format ${region}=${Forwarding rule name}.
  
  Note: When health checks are disabled, the rrdata for `WRR` or `GEO` can be RFC 1035 format DNS `rrdata`.
  When health checks are enabled, the rrdata is a reference to a forwarding rule. Cloud DNS uses the IP address of the forwarding rule as the rrdata. Cloud DNS monitors the health status of the forwarding rule and removes the forwarding rule from the results if it becomes unhealthy.
You must specify both the routing policy type and the routing policy data. If you specify one, you cannot leave the other flag unpopulated.
--enable-geo-fencing: for GEO routing policies, this determines whether traffic should failover across regions if all endpoints in a region are unhealthy. When set, Cloud DNS always directs queries to the nearest region, even if all endpoints in that region are unhealthy. Use --no-enable-geo-fencing to disable geofencing. When unset, Cloud DNS directs queries to the next nearest region when all endpoints in a region are unhealthy. This defaults to false.
ROUTING_POLICY_PRIMARY_DATA: the primary target to use for FAILOVER routing policies. This target must be a reference to one or more forwarding rules, such as forwarding-rule-1. As long as at least one of these forwarding rules is healthy, the IP addresses of all healthy forwarding rules are used to answer queries for this name.
ROUTING_POLICY_BACKUP_DATA: the backup target to use for FAILOVER routing policies. These targets are used when all forwarding rules specified in --routing-policy-primary-data are unhealthy. Cloud DNS only supports geo-based backup targets. The format of this field matches that of --routing-policy-data when --routing-policy-type = 'GEO', such as asia-east1=forwarding-rule-2.
BACKUP_DATA_TRICKLE_RATIO: the ratio of traffic to send to the backup targets even when the primaries are healthy. The ratio must be between 0 and 1, such as 0.1. The default is set to 0.
--enable-health-checking: Enables the health checking of forwarding rules that are provided as rrdata to --routing-policy-data.

API

Use the resourceRecordSets.patch method. Specify only one of rrset.rrdatas or rrset.routingPolicy. If specifying routingPolicy, you must specify the new routingPolicy field in its entirety.

For GEO policies, use the following method:

PATCH https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
            "name": "RRSET_NAME",
            "type": "RRSET_TYPE",
            "ttl": TTL,
            "routingPolicy": {
          "geo": {
              "items": [
              {
                  "location": "LOCATION",
                  "healthCheckedTargets": {
                     "internalLoadBalancers": [
                      {
                       "loadBalancerType": "LOAD_BALANCER_TYPE"
                       "ipAddress": "IP_ADDRESS"
                       "port" : "PORT_NUMBER"
                       "ipProtocol": "IP_PROTOCOL"
                       "networkUrl": "NETWORK_URL"
                       "project": "PROJECT"
                       "region": "REGION"
                      }
                     ]
                  }
              },
              {
                  "location": "LOCATION",
                  "healthCheckedTargets": {
                     "internalLoadBalancers": [
                      {
                       "loadBalancerType": "LOAD_BALANCING_TYPE"
                       "ipAddress": "IP_ADDRESS"
                       "port" : "PORT_NUMBER"
                       "ipProtocol": "IP_PROTOCOL"
                       "networkUrl": "NETWORK_URL"
                       "project": "PROJECT"
                       "region": "REGION"
                      }
                     ]
                  }
              },
              }
           ]

        }
     }
}

For WRR policies, use the following method:

PATCH https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
        "name": "RRSET_NAME.",
        "type": "RRSET_TYPE",
        "ttl": TTL,
        "routingPolicy": {
          "wrrPolicy": {
              "item": [
                    {
                        "weight": WEIGHT,
                        "rrdatas": ["RR_DATA"]
                    },
                    {
                        "weight": WEIGHT,
                        "rrdatas": ["RR_DATA"]
                     }
               ],
            }
      }
}

Replace the following:

PROJECT_ID: the ID of the project
MANAGED_ZONE: the managed zone that this ResourceRecordSet is affiliated with, such as service-zone; the name of this ResourceRecordSet must have the DNS name of the managed zone as its suffix
RRSET_NAME: the DNS name that matches the incoming queries with this zone's DNS name as its suffix, such as service.example.com
RRSET_TYPE: the resource record type of this ResourceRecordSet, such as A
TTL: the TTL in seconds that the resolver caches this ResourceRecordSet, such as 30
TRICKLE_TRAFFIC: the ratio of traffic to send to the backup targets even when the primaries are healthy; the ratio must be between 0 and 1, such as 0.1
ENABLE_FENCING: for GEO routing policies, this determines whether traffic should failover across regions if all endpoints in a region are unhealthy. When set, Cloud DNS always directs queries to the nearest region, even if all endpoints in that region are unhealthy. When unset, Cloud DNS directs queries to the next nearest region when all endpoints in a region are unhealthy. This defaults to false.
LOCATION: for GEO policies, the geolocation for which you need to update the policy, such as asia-east1
WEIGHT: for WRR policies, a semicolon-delimited list in the format ${weight_percent}=${rrdatas}, such as .8=10.128.1.1;.2=10.130.1.1; specify the weight as any non-negative decimal
Note: You must specify weight as a non-negative number. The ratio of traffic routed to the target is calculated from the ratio of individual weight over the total across all weights.
RR_DATA: an arbitrary value associated with the resource record set, such as 198.51.100.5; you can also enter multiple values, rrdata1 rrdata2 rrdata3, such as 198.51.100.1 203.0.113.1...
LOAD_BALANCER_TYPE: the type of load balancer, such as regionalL4ilb
IP_ADDRESS: the IP address that the forwarding rule serves
PORT_NUMBER: the port number
IP_PROTOCOL: defines the protocol used for the health check; valid options are tcp and udp
NETWORK_URL: the network URL to which this forwarding rule applies
REGION: the region in which you created the forwarding rule

Delete DNS routing policies

To delete a routing policy, you must delete the resource record set that contains the routing policy. To do so, follow these steps.

Console

In the Google Cloud console, go to the Cloud DNS zones page.

Go to Cloud DNS zones
Click the zone for which you want to delete the resource record set.
On the Zone details page, next to the DNS name of the resource record set that you want to delete, select the checkbox.
Click Delete record sets.

gcloud

Run the gcloud dns record-sets delete command:

gcloud dns record-sets delete RRSET_NAME \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \

Replace the following:

RRSET_NAME: the DNS name that matches the incoming queries with this zone's DNS name as its suffix, such as service.example.com
RRSET_TYPE: the resource record type of this ResourceRecordSet, such as A

For a list of supported record types, see Selecting resource record types.
MANAGED_ZONE: the managed zone that this ResourceRecordSet is affiliated with, such as service-zone; the name of this ResourceRecordSet must have the DNS name of the managed zone as its suffix

API

Use the resourceRecordSets.delete method:

DELETE https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets/RRSET_NAME/RRSET_TYPE

Replace the following:

PROJECT_ID: the ID of the project
MANAGED_ZONE: the managed zone that this ResourceRecordSet is affiliated with, such as my-zone-name; the name of this ResourceRecordSet must have the DNS name of the managed zone as its suffix
RRSET_NAME: the DNS name that matches the incoming queries with this zone's DNS name as its suffix, such as test.example.com
RRSET_TYPE: the resource record type of this ResourceRecordSet, such as A

What's next

To work with managed zones, see Create, modify, and delete zones.
To find solutions for common issues that you might encounter when using Cloud DNS, see Troubleshooting.
To get an overview of Cloud DNS, see Cloud DNS overview.