Administrar las políticas de enrutamiento de DNS y las verificaciones de estado

Las políticas de enrutamiento de DNS dirigen el tráfico según el tipo de consulta (por ejemplo, round robin ponderado o ubicación geográfica). Puedes configurar estas políticas mediante la creación de conjuntos de registros de recursos que contengan valores específicos de la política de enrutamiento. Estos valores determinan cómo se enruta el tráfico. Por ejemplo, en una política de round robin ponderado, cada conjunto de registros de recursos tiene una ponderación asignada que afecta la distribución del tráfico.

En esta página, se proporciona información sobre cómo crear, editar y borrar políticas de enrutamiento de DNS, y cómo habilitar la verificación de estado mediante Cloud DNS. Antes de usar esta página, familiarízate con la descripción general de las políticas de DNS.

Permisos necesarios para esta tarea

Para hacer esta tarea, debes tener los siguientes permisos o las siguientes funciones de IAM.

Permisos

dns.networks.useHealthSignals para crear una política con verificaciones de estado para balanceadores de cargas de red de transferencia internos
dns.changes.create para crear un conjunto de registros de recursos
dns.managedZones.list para enumerar las zonas administradas

Funciones

roles/dns.admin
roles/dns.peer

Para usar las políticas de enrutamiento de DNS, crea un conjunto de registros de recursos y elige una de las siguientes políticas de enrutamiento de DNS para aplicarla al conjunto de registros de recursos:

Política de enrutamiento de round robin ponderado (WRR): usa WRR para especificar diferentes ponderaciones por conjunto de registros de recursos para el nombre de DNS. Las políticas de enrutamiento de DNS garantizan que el tráfico se distribuya de acuerdo con las ponderaciones configuradas. No se admite la combinación de una política de enrutamiento de WRR con una política de enrutamiento de ubicación geográfica.

Nota: La dirección de tráfico puede ser inexacta debido al comportamiento de las memorias caché del agente de resolución. Cada respuesta se puede almacenar en caché y entregar a muchos clientes mediante el mismo agente de resolución hasta que venza el TTL. Esta es una limitación inherente del direccionamiento del tráfico de DNS.
Política de enrutamiento de ubicación geográfica (GEO): Usa GEO para especificar las ubicaciones geográficas de origen y proporcionar respuestas correspondientes a esas ubicaciones. La política de enrutamiento de ubicación geográfica aplica la coincidencia más cercana a la ubicación de origen cuando el origen del tráfico no coincide de forma exacta con ningún elemento de la política.

GEO asigna el origen del DNS público y privado de las siguientes maneras:
- Para DNS público: se usa la dirección IP de origen o la subred del cliente del mecanismo de extensión para DNS (EDNS) de la consulta.
- Para el DNS privado, no se usa la subred del cliente de EDNS. En cambio, la ubicación de la consulta es la ubicación del sistema que envía los paquetes para la consulta:
  - Para consultas desde una instancia de máquina virtual (VM) con una interfaz de red en una red de VPC, la ubicación de la consulta es la región que contiene la VM.
  - En el caso de las consultas recibidas por un punto de entrada de la política del servidor entrante, la ubicación de la consulta es la región del túnel de Cloud VPN, el adjunto de VLAN de Cloud Interconnect o el dispositivo de router que recibió los paquetes para la consulta. La región de la dirección IP del punto de entrada no es relevante. Si deseas obtener más información, consulta Red y región para consultas entrantes en la página “Políticas del servidor DNS”.
Política de enrutamiento geovallado: Usa el geovallado para restringir el tráfico a una ubicación geográfica específica, incluso si todos los extremos de esa ubicación geográfica están en mal estado. Para obtener información detallada sobre el geovallado, consulta Políticas de enrutamiento de geovallado.
Política de enrutamiento de conmutación por error: Usa la conmutación por error para establecer configuraciones de copia de seguridad activas. Para obtener más detalles, consulta Políticas de enrutamiento de conmutación por error.

Las políticas de enrutamiento de DNS también admiten varias direcciones IP para cada ubicación geográfica. Cuando se especifica para una ubicación geográfica determinada, se muestran varias direcciones IP de acuerdo con una política de WRR de igual peso. No se admite combinar una política de enrutamiento basado en la ubicación geográfica con una política de WRR ponderada personalizada.

Verificaciones de estado

Cloud DNS admite verificaciones de estado para balanceadores de cargas de red de transferencia internos y balanceadores de cargas de aplicaciones internos que tienen habilitado el acceso global, así como balanceadores de cargas de aplicaciones internos entre regiones.

Después de configurar un balanceador de cargas de red de transferencia interno, configura la política de enrutamiento adecuada dentro de Cloud DNS. Para ello, usa la consola de Google Cloud, gcloud CLI o la API y especifica el balanceador de cargas de red de transferencia interno. En este paso, se deben configurar varios buckets WRR o GEO, y cada bucket puede contener varios balanceadores de cargas de red de transferencia internos.

En el caso de los balanceadores de cargas de red de transferencia internos, Cloud DNS verifica la información de estado en las instancias de backend individuales del balanceador de cargas para determinar si el balanceador de cargas está en buen o mal estado. Cloud DNS aplica un umbral predeterminado del 20% y, si al menos el 20% de las instancias de backend están en buen estado, el extremo del balanceador de cargas se considera en buen estado. Las políticas de enrutamiento de DNS marcan el extremo como en buen o mal estado según este umbral y enrutan el tráfico según corresponda.

Para los balanceadores de cargas de aplicaciones internos y los balanceadores de cargas de aplicaciones internos entre regiones, Cloud DNS verifica el estado general del balanceador de cargas de aplicaciones interno y permite que este verifique el estado de las instancias de backend.

Cuando el extremo se marca como en mal estado, pueden ocurrir las siguientes condiciones:

Si hay varias direcciones VIP programadas según una política, solo se muestran las direcciones VIP en buen estado.
Si todas las direcciones VIP programadas en un bucket de políticas están en mal estado, esa línea de política falló. Se aplica el siguiente comportamiento:
- Para una política WRR, Cloud DNS distribuye el tráfico al siguiente bucket de peso en buen estado.
- En el caso de una política GEO que no tenga la cerca habilitada, el tráfico cambia a la siguiente geografía más cercana.
- En una política con geovallado que tiene el cercado habilitado, las direcciones VIP en el bucket de ubicación geográfica más cercano se muestran tal como están.
- Para una política de conmutación por error, Cloud DNS cambia el tráfico al bucket de conmutación por error.
- Si todos los buckets de políticas están en mal estado, Cloud DNS se comporta como si todos los extremos estuvieran en buen estado.

Antes de comenzar

En este procedimiento, se presupone que completaste lo siguiente:

Creaste una zona administrada y completaste los requisitos previos para crear una zona.
Configura uno de los siguientes balanceadores de cargas internos:
Creaste reglas de reenvío para el balanceador de cargas interno.
Configura la verificación de estado para el balanceador de cargas interno.

Crea políticas de enrutamiento de DNS

Para crear un conjunto de registros de recursos y aplicarle una política de enrutamiento, sigue estos pasos.

Console

Inicia la configuración

En la consola de Google Cloud, ve a la página Zonas de Cloud DNS.

Ir a Zonas de Cloud DNS
Haz clic en el nombre de la zona administrada a la que deseas agregar el registro.
En la página Detalles de la zona, haz clic en Agregar con política de enrutamiento.

Datos base

En la página Crear un conjunto de registros con política de enrutamiento, en el campo Nombre de DNS, ingresa el subdominio de la zona de DNS, por ejemplo, mail. El punto final se agrega automáticamente al final.

Nota: Agregar el símbolo @ en este campo hace que el registro falle.
Selecciona el Tipo de registros del recursos, por ejemplo, A.
En el campo TTL, ingresa un valor numérico para el tiempo de actividad del registro de recursos. Este valor indica el tiempo que se puede almacenar en caché. El valor debe ser un número entero positivo.
En el menú Unidad de TTL, selecciona la unidad de tiempo, por ejemplo, 30 minutes.
Haz clic en Siguiente.

Tipo de política de enrutamiento

En la lista Política de enrutamiento, selecciona Round robin ponderado, Ubicación geográfica o Conmutación por error.
Haz clic en Siguiente.

Datos de políticas de enrutamiento

Si seleccionaste Round robin ponderado, en la sección Datos de enrutamiento de la política de round robin ponderado, haz lo siguiente:
1. En el campo Weight, ingresa la ponderación correspondiente a esta subsección de los datos del registro de recursos (RR). Esta ponderación debe ser un número positivo entre 0.0 y 1,000.0. La proporción de tráfico enrutado al objetivo se calcula a partir de la proporción del peso individual sobre el total en todas las ponderaciones.
2. En la sección Agregar destino con verificación de estado, haz lo siguiente:
  1. En la lista Proyecto, selecciona el proyecto en el que existe la regla de reenvío.
  2. En la lista Tipo, selecciona el balanceador de cargas de red de transferencia interno, el balanceador de cargas de aplicaciones interno o el balanceador de cargas de aplicaciones interno entre regiones.
  3. En la lista Regla de reenvío, selecciona una regla de reenvío.
    
    La regla de reenvío especifica una dirección IP interna, un puerto y un servicio de backend regional o un proxy HTTP(S). A fin de que Cloud DNS funcione con las verificaciones de estado, debes habilitar el acceso global para el balanceador de cargas interno.
3. Para permitir direcciones IPv4 sin verificación de estado, selecciona Permitir direcciones IPv4 sin verificación de estado.
4. En el campo Dirección IPv4, ingresa una dirección IPv4.
Si seleccionaste Ubicación geográfica, haz lo siguiente:
1. En Geovallado, selecciona Inhabilitado o Habilitado. Habilitar el geovallado restringe el tráfico a una ubicación geográfica específica, incluso si todos los extremos de esa ubicación geográfica están en mal estado.
2. En el menú Región de origen, selecciona una región de origen de Google Cloud válida, como asia-east1.
3. En la sección Agregar destino con verificación de estado, haz lo siguiente:
  1. En la lista Proyecto, selecciona el proyecto en el que existe la regla de reenvío.
  2. En la lista Tipo, selecciona el balanceador de cargas de red de transferencia interno, el balanceador de cargas de aplicaciones interno o el balanceador de cargas de aplicaciones interno entre regiones.
  3. En la lista Regla de reenvío, selecciona una regla de reenvío.
    
    La regla de reenvío especifica una dirección IP interna, un puerto y un servicio de backend regional o un proxy HTTP(S). A fin de que Cloud DNS funcione con las verificaciones de estado, debes habilitar el acceso global para el balanceador de cargas interno.
4. Para permitir direcciones IPv4 sin verificación de estado, selecciona Permitir direcciones IPv4 sin verificación de estado.
5. En el campo Dirección IPv4, ingresa una dirección IPv4.
Si seleccionaste Conmutación por error, haz lo siguiente:

Nota: Puedes configurar una política de enrutamiento de conmutación por error solo para zonas privadas.
1. En el campo Trickle traffic (%), ingresa el porcentaje del tráfico enviado a los destinos de conmutación por error, sin importar el estado de la verificación de estado de los objetivos principales.
2. En la sección Destinos principales, haz lo siguiente:
  1. En la lista Proyecto, selecciona el proyecto en el que existe la regla de reenvío.
  2. En la lista Tipo, selecciona el balanceador de cargas de red de transferencia interno, el balanceador de cargas de aplicaciones interno o el balanceador de cargas de aplicaciones interno entre regiones.
  3. En la lista Regla de reenvío, selecciona una regla de reenvío.
    
    La regla de reenvío especifica una dirección IP interna, un puerto y un servicio de backend regional o un proxy HTTP(S). A fin de que Cloud DNS funcione con las verificaciones de estado, debes habilitar el acceso global para el balanceador de cargas interno.
3. En la sección Política de ubicación geográfica de copia de seguridad, haz lo siguiente:
  1. En Geovallado, selecciona Inhabilitado o Habilitado. Habilitar el geovallado restringe el tráfico a una ubicación geográfica específica, incluso si todos los extremos de esa ubicación geográfica están en mal estado.
  2. En el menú Región de origen, selecciona una región de origen de Google Cloud válida, como asia-east1.
  3. En la sección Agregar destino con verificación de estado, haz lo siguiente:
    1. En la lista Proyecto, selecciona el proyecto en el que existe la regla de reenvío.
    2. En la lista Tipo, selecciona el balanceador de cargas de red de transferencia interno, el balanceador de cargas de aplicaciones interno o el balanceador de cargas de aplicaciones interno entre regiones.
    3. En la lista Regla de reenvío, selecciona una regla de reenvío.
    Cuando todas las direcciones IP principales están en mal estado, el tráfico se controla automáticamente de acuerdo con la política de ubicación geográfica de copia de seguridad.
4. Para permitir direcciones IPv4 sin verificación de estado, selecciona Permitir direcciones IPv4 sin verificación de estado.
5. En el campo Dirección IPv4, ingresa una dirección IPv4.
Haz clic en Siguiente.

Revisa y crea

Haz clic en Revisar.
Revisa tu conjunto de registros de Cloud DNS con la configuración de la política de enrutamiento.
Opcional: Haz clic en Línea de comentario equivalente para ver el comando de gcloud CLI que te permitirá crear este conjunto de registros con la política de enrutamiento.
Haz clic en Crear.

gcloud

Un ResourceRecordSet puede contener un routingPolicy o un rrdatas, pero no ambos. Se admite el cambio entre rrdatas o routingPolicy cuando se actualiza ResourceRecordSets. Por ejemplo, si deseas actualizar un ResourceRecordSet que contiene rrdatas, puedes borrar el rrdatas y agregar un routingPolicy al mismo ResourceRecordSet.

Para crear un ResourceRecordSet y aplicarle una política de enrutamiento, sigue estos pasos.

Ejecuta el comando gcloud dns record-sets create.

Para las políticas de ubicación geográfica

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

Para las políticas de WRR

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

Para políticas de geovallado

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

Para políticas de conmutación por error

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

Reemplaza lo siguiente:

RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes con el nombre DNS de esta zona como sufijo, por ejemplo, service.example.com.
TTL: el TTL en segundos que el agente de resolución almacena en caché este ResourceRecordSet, como 30.
RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A.

Para obtener una lista de los tipos de registros compatibles, consulta Selecciona tipos de registros de recursos.
MANAGED_ZONE: Es la zona administrada con la que está afiliado ResourceRecordSet, como service-zone. El nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona administrada como sufijo
ROUTING_POLICY_TYPE: el tipo de política de enrutamiento.

Ingresa WRR para el round robin ponderado, GEO para la ubicación geográfica o FAILOVER para las políticas de conmutación por error. No puedes modificar este campo después de que una política tenga un tipo elegido. Solo puedes borrar la política y agregar una política nueva con el tipo diferente.
ROUTING_POLICY_DATA: los datos de la política de enrutamiento.
- En --routing-policy-type=WRR, ingresa una lista delimitada por punto y coma con el formato ${weight_percent}:${rrdatas}, como .8=203.0.113.1;.2=198.51.100.1. Especifica la ponderación como un decimal no negativo. La proporción del tráfico enrutado al objetivo se calcula a partir de la proporción del peso individual sobre el total en todas las ponderaciones. Los nombres de las reglas de reenvío son valores aceptables y dan como resultado la verificación de estado.
- En --routing-policy-type=GEO, ingresa una lista delimitada por punto y coma con el formato ${region}=${IP_address}, como asia-east1=198.51.100.1;us-central1=203.0.113.1. Si quieres especificar varias direcciones IP para una sola región, agrega direcciones IP separadas por comas. Los nombres de las reglas de reenvío son valores aceptables y dan como resultado la verificación de estado.
- Para --routing-policy-type=FAILOVER, ingresa el nombre de la regla de reenvío que creaste en el formato ${region}=${Forwarding rule name}.
  
  Nota: Cuando se inhabilitan las verificaciones de estado, los rrdata de WRR o GEO pueden ser <aclass="external" l10n-attrs-original-order="href,class" l10n-encrypted-href="fbj0fi6rS3pPqxfn3YD3etONK6A9Q8tQ5ZMUfKCg7jl7p.
  Cuando las verificaciones de estado están habilitadas, los rrdata hacen referencia a una regla de reenvío. En Cloud DNS, se usa la dirección IP de la regla de reenvío como rrdata. Cloud DNS supervisa el estado de la regla de reenvío y la quita de los resultados si no está en buen estado.
  </aclass="external">
Debes especificar el tipo y los datos de la política de enrutamiento. Si especificas una, no puedes dejar la otra sin propagar.
--enable-geo-fencing: para las políticas de enrutamiento de GEO, esto determina si el tráfico debe conmutar por error entre regiones si todos los extremos de una región están en mal estado. Cuando se configura, Cloud DNS siempre dirige las consultas a la región más cercana, incluso si todos los extremos de esa región están en mal estado. Usa --no-enable-geo-fencing para inhabilitar el geovallado. Si no se configura, Cloud DNS dirige las consultas a la siguiente región más cercana cuando todos los extremos de una región están en mal estado. El valor predeterminado es false.
ROUTING_POLICY_PRIMARY_DATA: Es el destino principal que se usará para las políticas de enrutamiento de FAILOVER. Este destino debe ser una referencia a una o más reglas de reenvío, como forwarding-rule-1. Siempre que al menos una de estas reglas de reenvío esté en buen estado, las direcciones IP de todas las reglas de reenvío en buen estado se usarán para responder las consultas de este nombre.
ROUTING_POLICY_BACKUP_DATA: El destino de copia de seguridad que se usará para las políticas de enrutamiento FAILOVER. Estos destinos se usan cuando todas las reglas de reenvío especificadas en --routing-policy-primary-data están en mal estado. Cloud DNS solo admite destinos de copia de seguridad basados en la ubicación geográfica. El formato de este campo coincide con el de --routing-policy-data cuando --routing-policy-type = 'GEO', como asia-east1=forwarding-rule-2.
ROUTING_POLICY_BACKUP_DATA_TYPE: Para las políticas de enrutamiento de FAILOVER, el tipo de política de enrutamiento que usan los datos de copia de seguridad Debe ser GEO.
BACKUP_DATA_TRICKLE_RATIO: Es la proporción del tráfico que se enviará a los destinos de copia de seguridad, incluso cuando las primarias están en buen estado. La proporción debe ser entre 0 y 1, como 0.1. El valor predeterminado es 0.
--enable-health-checking: Es la marca para habilitar las verificaciones de estado. Cuando usas esta marca, debes proporcionar el nombre de la regla de reenvío en lugar de la dirección IP en el campo --routing-policy-data.

API

Usa el método resourceRecordSets.create.

Para las políticas de ubicación geográfica

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"
                      }
                     ]
                  }
              },
              }
           ]

        }
     }
}

Para las políticas de WRR

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"
              }
            ]
          }
        },
      ]
    }
  }
}

Para la conmutación por error de las políticas geográficas

En la opción de conmutación por error, Cloud DNS solo admite políticas GEO.

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"
             ]
           }
         ]
       }
     },
   }
}

Reemplaza lo siguiente:

PROJECT_ID: El ID del proyecto
MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, como service-zone; el nombre de este ResourceRecordSet debe tener el nombre de DNS del administrado zone como sufijo.
RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes con el nombre DNS de esta zona como sufijo, por ejemplo, service.example.com.
RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A.
TTL: el TTL en segundos que el agente de resolución almacena en caché este ResourceRecordSet, como 30.
TRICKLE_TRAFFIC: Es la proporción del tráfico que se enviará a los objetivos de copia de seguridad, incluso cuando los principales están en buen estado. La proporción debe ser entre 0 y 1, como 0.1.
ENABLE_FENCING: Para las políticas de enrutamiento de GEO, esto determina si el tráfico debe realizar una conmutación por error entre regiones si todos los extremos de una región están en mal estado. Cuando se configura, Cloud DNS siempre dirige las consultas a la región más cercana, incluso si todos los extremos de esa región están en mal estado. Si no se configura, Cloud DNS dirige las consultas a la siguiente región más cercana cuando todos los extremos de una región están en mal estado. La configuración predeterminada es false.
LOCATION: Para las políticas GEO, la ubicación geográfica para la que necesitas crear la política, como asia-east1
WEIGHT: Para las políticas WRR, es una lista delimitada por punto y coma en el formato ${weight_percent}=${rrdatas}, como .8=10.128.1.1;.2=10.130.1.1; especifica el peso como cualquier decimal no negativo.
Nota: Debes especificar el peso como un número que no sea negativo. La proporción de tráfico enrutado al objetivo se calcula a partir de la proporción del peso individual sobre el total en todos los pesos.
RR_DATA: un valor arbitrario asociado con el conjunto de registros de recursos, como 198.51.100.5, también puedes ingresar varios valores, rrdata1 rrdata2 rrdata3, como 198.51.100.1 203.0.113.1...
LOAD_BALANCER_TYPE: Es el tipo de balanceador de cargas, como regionalL4ilb.
IP_ADDRESS: La dirección IP que entrega la regla de reenvío
PORT_NUMBER es el número de puerto.
IP_PROTOCOL: Define el protocolo que se usa para la verificación de estado. Las opciones válidas son tcp y udp.
NETWORK_URL: La URL de la red a la que se aplica esta regla de reenvío
REGION: Es la región en la que creaste la regla de reenvío.

Actualiza las políticas de enrutamiento de DNS

Para actualizar la política de enrutamiento de un conjunto de registros de recursos, sigue estos pasos:

Console

En la consola de Google Cloud, ve a la página Zonas de Cloud DNS.

Ir a Zonas de Cloud DNS
Haz clic en la zona para la que deseas actualizar la política de enrutamiento del conjunto de registros de recursos.
En la página Detalles de la zona, junto al conjunto de registros de recursos que deseas actualizar, haz clic en Editar .
Después de realizar las actualizaciones necesarias, haga clic en Guardar.

gcloud

Ejecuta el comando gcloud dns record-sets update:

Para las políticas de ubicación geográfica

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

Para las políticas de WRR

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

Para políticas de geovallado

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

Para políticas de conmutación por error

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

Reemplaza lo siguiente:

RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes con el nombre DNS de esta zona como sufijo, por ejemplo, service.example.com.
TTL: el TTL en segundos que el agente de resolución almacena en caché este ResourceRecordSet, como 30.
RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A.

Para obtener una lista de los tipos de registros compatibles, consulta Selecciona tipos de registros de recursos.
MANAGED_ZONE: Es la zona administrada con la que está afiliado ResourceRecordSet, como service-zone. El nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona administrada como sufijo
ROUTING_POLICY_TYPE: el tipo de política de enrutamiento.

Ingresa WRR para el round robin ponderado, GEO para la ubicación geográfica o FAILOVER para las políticas de conmutación por error. No puedes modificar este campo después de que una política tenga un tipo elegido. Solo puedes borrar la política y agregar una política nueva con el tipo diferente.
ROUTING_POLICY_DATA: los datos de la política de enrutamiento.
- En --routing-policy-type=WRR, ingresa una lista delimitada por punto y coma con el formato ${weight_percent}:${rrdatas}, como .8=203.0.113.1;.2=198.51.100.1. Especifica la ponderación como un decimal no negativo. La proporción del tráfico enrutado al objetivo se calcula a partir de la proporción del peso individual sobre el total en todas las ponderaciones. Los nombres de las reglas de reenvío son valores aceptables y dan como resultado la verificación de estado.
- En --routing-policy-type=GEO, ingresa una lista delimitada por punto y coma con el formato ${region}=${IP_address}, como asia-east1=198.51.100.1;us-central1=203.0.113.1. Si quieres especificar varias direcciones IP para una sola región, agrega direcciones IP separadas por comas. Los nombres de las reglas de reenvío son valores aceptables y dan como resultado la verificación de estado.
- Para --routing-policy-type=FAILOVER, ingresa el nombre de la regla de reenvío que creaste en el formato ${region}=${Forwarding rule name}.
  
  Nota: Cuando las verificaciones de estado están inhabilitadas, los rrdata para “WRR” o “GEO” pueden tener DNS de formato RFC 1035 “rrdata”.
  Cuando las verificaciones de estado están habilitadas, los rrdata hacen referencia a una regla de reenvío. En Cloud DNS, se usa la dirección IP de la regla de reenvío como rrdata. Cloud DNS supervisa el estado de la regla de reenvío y la quita de los resultados si no está en buen estado.
Debes especificar el tipo y los datos de la política de enrutamiento. Si especificas una, no puedes dejar la otra sin propagar.
--enable-geo-fencing: para las políticas de enrutamiento de GEO, esto determina si el tráfico debe conmutar por error entre regiones si todos los extremos de una región están en mal estado. Cuando se configura, Cloud DNS siempre dirige las consultas a la región más cercana, incluso si todos los extremos de esa región están en mal estado. Usa --no-enable-geo-fencing para inhabilitar el geovallado. Si no se configura, Cloud DNS dirige las consultas a la siguiente región más cercana cuando todos los extremos de una región están en mal estado. El valor predeterminado es false.
ROUTING_POLICY_PRIMARY_DATA: Es el destino principal que se usará para las políticas de enrutamiento de FAILOVER. Este destino debe ser una referencia a una o más reglas de reenvío, como forwarding-rule-1. Siempre que al menos una de estas reglas de reenvío esté en buen estado, las direcciones IP de todas las reglas de reenvío en buen estado se usarán para responder las consultas de este nombre.
ROUTING_POLICY_BACKUP_DATA: El destino de copia de seguridad que se usará para las políticas de enrutamiento FAILOVER. Estos destinos se usan cuando todas las reglas de reenvío especificadas en --routing-policy-primary-data están en mal estado. Cloud DNS solo admite destinos de copia de seguridad basados en la ubicación geográfica. El formato de este campo coincide con el de --routing-policy-data cuando --routing-policy-type = 'GEO', como asia-east1=forwarding-rule-2.
BACKUP_DATA_TRICKLE_RATIO: Es la proporción del tráfico que se enviará a los destinos de copia de seguridad, incluso cuando las primarias están en buen estado. La proporción debe ser entre 0 y 1, como 0.1. El valor predeterminado es 0.
--enable-health-checking: Habilita la verificación de estado de las reglas de reenvío que se proporcionan como rrdata a --routing-policy-data.

API

Usa el método resourceRecordSets.patch. Especifica solo uno de rrset.rrdatas o rrset.routingPolicy. Si especificas routingPolicy, debes especificar el nuevo campo routingPolicy en su totalidad.

Para las políticas GEO, usa el siguiente método:

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"
                      }
                     ]
                  }
              },
              }
           ]

        }
     }
}

Para las políticas WRR, usa el siguiente método:

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"]
                     }
               ],
            }
      }
}

Reemplaza lo siguiente:

PROJECT_ID: El ID del proyecto
MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, como service-zone; el nombre de este ResourceRecordSet debe tener el nombre de DNS del administrado zone como sufijo.
RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes con el nombre DNS de esta zona como sufijo, por ejemplo, service.example.com.
RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A.
TTL: el TTL en segundos que el agente de resolución almacena en caché este ResourceRecordSet, como 30.
TRICKLE_TRAFFIC: Es la proporción del tráfico que se enviará a los objetivos de copia de seguridad, incluso cuando los principales están en buen estado. La proporción debe ser entre 0 y 1, como 0.1.
ENABLE_FENCING: Para las políticas de enrutamiento de GEO, esto determina si el tráfico debe realizar una conmutación por error entre regiones si todos los extremos de una región están en mal estado. Cuando se configura, Cloud DNS siempre dirige las consultas a la región más cercana, incluso si todos los extremos de esa región están en mal estado. Si no se configura, Cloud DNS dirige las consultas a la siguiente región más cercana cuando todos los extremos de una región están en mal estado. La configuración predeterminada es false.
LOCATION: Para las políticas de GEO, la ubicación geográfica en la que necesitas actualizar la política, como asia-east1
WEIGHT: Para las políticas WRR, es una lista delimitada por punto y coma en el formato ${weight_percent}=${rrdatas}, como .8=10.128.1.1;.2=10.130.1.1; especifica el peso como cualquier decimal no negativo.
Nota: Debes especificar el peso como un número que no sea negativo. La proporción de tráfico enrutado al objetivo se calcula a partir de la proporción del peso individual sobre el total en todos los pesos.
RR_DATA: un valor arbitrario asociado con el conjunto de registros de recursos, como 198.51.100.5, también puedes ingresar varios valores, rrdata1 rrdata2 rrdata3, como 198.51.100.1 203.0.113.1...
LOAD_BALANCER_TYPE: Es el tipo de balanceador de cargas, como regionalL4ilb.
IP_ADDRESS: La dirección IP que entrega la regla de reenvío
PORT_NUMBER es el número de puerto.
IP_PROTOCOL: Define el protocolo que se usa para la verificación de estado. Las opciones válidas son tcp y udp.
NETWORK_URL: La URL de la red a la que se aplica esta regla de reenvío
REGION: Es la región en la que creaste la regla de reenvío.

Borra políticas de enrutamiento de DNS

Para borrar una política de enrutamiento, debes borrar el conjunto de registros de recursos que contiene la política de enrutamiento. Para hacerlo, siga estos pasos.

Console

En la consola de Google Cloud, ve a la página Zonas de Cloud DNS.

Ir a Zonas de Cloud DNS
Haz clic en la zona para la que deseas borrar el conjunto de registros de recursos.
En la página Detalles de la zona, junto a el nombre de DNS del conjunto de registros de recursos que deseas borrar, selecciona la casilla de verificación.
Haz clic en Borrar conjuntos de registros.

gcloud

Ejecuta el comando gcloud dns record-sets delete:

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

Reemplaza lo siguiente:

RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes con el nombre DNS de esta zona como sufijo, por ejemplo, service.example.com.
RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A.

Para obtener una lista de los tipos de registros compatibles, consulta Selecciona tipos de registros de recursos.
MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, como service-zone; el nombre de este ResourceRecordSet debe tener el nombre de DNS del administrado zone como sufijo.

API

Usa el método resourceRecordSets.delete:

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

Reemplaza lo siguiente:

PROJECT_ID: El ID del proyecto
MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, como my-zone-name; el nombre de este ResourceRecordSet debe tener el nombre de DNS del administrado zone como sufijo.
RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes con el nombre DNS de esta zona como sufijo, por ejemplo, test.example.com.
RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A.

¿Qué sigue?

Para trabajar con zonas administradas, consulta Crea, modifica y borra zonas.
Para encontrar soluciones a problemas habituales que podrías tener cuando usas Cloud DNS, consulta Solución de problemas.
Para obtener una descripción general de Cloud DNS, consulta Descripción general de Cloud DNS.