Configura políticas de enrutamiento de DNS y verificaciones de estado

En esta página, se describe cómo configurar las políticas de enrutamiento de DNS y habilitar las verificaciones de estado con Cloud DNS. Antes de usar esta página, familiarízate con las políticas de enrutamiento de DNS y las verificaciones de estado.

Antes de comenzar

  • Para configurar las políticas de enrutamiento de DNS, crea un conjunto de registros de recursos y elige una de las siguientes políticas para aplicar a ese conjunto.

  • Las políticas de enrutamiento de DNS admiten varias direcciones IP por ubicación geográfica en la política de enrutamiento de ubicación geográfica. Cuando especificas varias direcciones IP para una ubicación geográfica, Cloud DNS devuelve todas las direcciones IP especificadas para esa ubicación. No puedes combinar una política de enrutamiento de ubicación geográfica con una política de WRR con un peso personalizado.

  • Aplica solo un tipo de política de enrutamiento a un conjunto de registros de recursos a la vez. No puedes combinarlas, excepto cuando configuras una política de enrutamiento de conmutación por error, en cuyo caso puedes establecer una política de enrutamiento de ubicación geográfica como copia de seguridad.

  • Asegúrate de habilitar el acceso global para los balanceadores de cargas regionales.

  • Antes de configurar las políticas de enrutamiento de DNS para zonas públicas, inhabilita la restricción de la política de la organización constraints/compute.disableInternetNetworkEndpointGroup. Para obtener más información, consulta las Restricciones de las políticas de la organización.

  • Asegúrate de tener los permisos necesarios para configurar políticas de enrutamiento de DNS.

Crea políticas de enrutamiento de DNS para zonas privadas

Antes de crear políticas de enrutamiento de DNS para zonas privadas, completa los siguientes pasos.

  1. Crea una zona privada.
  2. Configura uno de los siguientes balanceadores de cargas internos:
  3. Crea reglas de reenvío para el balanceador de cargas interno.
  4. Configura la verificación de estado para el balanceador de cargas interno.

Para crear políticas de enrutamiento de DNS para zonas privadas, sigue estos pasos.

Consola

Inicia la configuración

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

    Ir a Zonas de Cloud DNS

  2. Haz clic en el nombre de la zona administrada a la que deseas agregar el registro.

  3. En la página Detalles de la zona, haz clic en Agregar con una política de enrutamiento.

Datos base

  1. Opcional: En la página Crear conjunto de registros con política de enrutamiento, para el Nombre de DNS, ingresa un subdominio del nombre de DNS, por ejemplo, mail. El punto final se agrega de forma automática.

  2. En Tipo de registro del recurso, selecciona una opción.

  3. En 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.

  4. Opcional: En Unidad TTL, selecciona la unidad de tiempo, por ejemplo, minutes. El valor predeterminado es minutes

  5. Haz clic en Siguiente.

Tipo de política de enrutamiento

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

Datos de políticas de enrutamiento

WRR

  1. En Peso, ingresa el peso correspondiente a esta subartículo de los datos del registro de recursos (RR).

    Este peso debe ser un número no negativo entre 0.0 y 1,000.0. La proporción del tráfico enrutado al destino se calcula a partir de la proporción del peso individual sobre el total en todos los pesos. Por ejemplo, si el destino A pesa 25 y el destino B pesa 75, es decir, que el peso total es 100, Cloud DNS enruta el 25/100 = 0.25 (25%) del tráfico total al destino A y el 75/100 = 0.75 (75%) al destino B.

  2. En la sección Destinos con verificación de estado de IPv4, haz lo siguiente:

    1. En Proyecto, selecciona el proyecto en el que existe la regla de reenvío.
    2. En Regla de reenvío, selecciona una.

      La regla de reenvío especifica una dirección IP interna, un puerto y uno de los siguientes destinos:

  3. Haz clic en Listo.

  4. Opcional: Para agregar otro destino cuyo estado esté verificado, haz clic en Agregar destino.

  5. Opcional: Para permitir direcciones IPv4 sin verificación de estado, haz lo siguiente:

    1. Selecciona Permitir direcciones IPv4 sin verificación de estado.
    2. En Dirección IPv4, ingresa una dirección IPv4.
  6. Opcional: Para agregar otro conjunto de datos de enrutamiento de políticas de WRR, haz clic en Agregar datos de enrutamiento.

  7. Haz clic en Siguiente.

Ubicación geográfica

  1. En Geovallado, selecciona Inhabilitado o Habilitado.

    Habilitar el geovallado restringe el tráfico a una ubicación geográfica específica, incluso si ninguno de los extremos de esa ubicación geográfica está en buen estado.

  2. En Región de origen, selecciona una región de origen válida de Google Cloud.

  3. En la sección Destinos con verificación de estado de IPv4, haz lo siguiente:

    1. En Proyecto, selecciona el proyecto en el que existe la regla de reenvío.
    2. En Regla de reenvío, selecciona una.

      La regla de reenvío especifica una dirección IP interna, un puerto y uno de los siguientes destinos:

  4. Haz clic en Listo.

  5. Opcional: Para agregar otro destino cuyo estado esté verificado, haz clic en Agregar destino.

  6. Opcional: Para permitir direcciones IPv4 sin verificación de estado, haz lo siguiente:

    1. Selecciona Permitir direcciones IPv4 sin verificación de estado.
    2. En Dirección IPv4, ingresa una dirección IPv4.
  7. Opcional: Para agregar otro conjunto de datos de enrutamiento de la política de ubicación geográfica, haz clic en Agregar datos de enrutamiento.

  8. Haz clic en Siguiente.

Conmutación por error

  1. En la sección Destinos principales con verificación de estado, haz lo siguiente:

    1. En Proyecto, selecciona el proyecto en el que existe la regla de reenvío.
    2. En Regla de reenvío, selecciona una.

      La regla de reenvío especifica una dirección IP interna, un puerto y uno de los siguientes destinos:

  2. En la sección Política de ubicación geográfica con 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 ninguno de los extremos de esa ubicación geográfica está en buen estado.
    2. En Región de origen, selecciona una región de origen válida de Google Cloud.
    3. En la sección Destinos con verificación de estado de IPv4, haz lo siguiente:

      1. En Proyecto, selecciona el proyecto en el que existe la regla de reenvío.
      2. En Regla de reenvío, selecciona una.

        La regla de reenvío especifica una de las siguientes opciones:

        • Una dirección IP interna, un puerto y un servicio de backend regional
        • Un proxy HTTP(S)
        • Un proxy TCP

    Cuando todas las direcciones IP principales están en mal estado, el tráfico se maneja de forma automática según la política de ubicación geográfica con copia de seguridad.

  3. Haz clic en Listo.

  4. Opcional: Para agregar otro destino cuyo estado esté verificado, haz clic en Agregar destino.

  5. Opcional: Para permitir direcciones IPv4 sin verificación de estado, haz lo siguiente:

    1. Selecciona Permitir direcciones IPv4 sin verificación de estado.
    2. En Dirección IPv4, ingresa una dirección IPv4.
  6. Opcional: Para agregar otro conjunto de datos de enrutamiento para la política de la ubicación geográfica con copia de seguridad, haz clic en Agregar datos de enrutamiento.

  7. En el campo Goteo de tráfico (%), ingresa el porcentaje del tráfico que se envía a los destinos de conmutación por error, sin importar cómo resultó la verificación de estado de los destinos principales.

  8. Haz clic en Siguiente.

Revisar y crear

  1. Haz clic en Revisar.
  2. Revisa tu conjunto de registros de Cloud DNS con la configuración de la política de enrutamiento.
  3. Haz clic en Crear.

gcloud

En el caso de un conjunto de registros de recursos, debes establecer una política de enrutamiento (routingPolicy) o datos de DNS (rrdatas), pero no ambos. Para cambiar entre una política de enrutamiento y datos de DNS, actualiza el conjunto de registros de recursos. Por ejemplo, para cambiar un conjunto de registros de recursos que contiene datos de DNS (rrdatas) para que, en cambio, contenga una política de enrutamiento (routingPolicy), borra rrdatas y agrega routingPolicy al mismo conjunto de registros de recursos.

Para crear políticas de enrutamiento de DNS para zonas privadas, sigue estos pasos.

Ejecuta el comando gcloud dns record-sets create:

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

Reemplaza lo siguiente:

  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
  • TTL: el TTL en segundos en el que el agente de resolución almacena en caché ResourceRecordSet, como 30
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A Para obtener una lista de los tipos de registros compatibles, consulta Tipos de registros compatibles con las políticas de enrutamiento de DNS
  • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
  • ROUTING_POLICY_DATA: ingresa una lista delimitada por punto y coma en el formato ${weight_percent}:${rrdatas}, por ejemplo, .8=203.0.113.1;.2=198.51.100.1. Especifica el peso como un decimal no 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 Los nombres de las reglas de reenvío son valores aceptables y generan verificaciones de estado
  • --enable-health-checking: la marca para habilitar la verificación de estado. Cuando usas esta marca, debes brindar el nombre de la regla de reenvío en lugar de la dirección IP en el campo --routing-policy-data

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

Reemplaza lo siguiente:

  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
  • TTL: el TTL en segundos en el que el agente de resolución almacena en caché ResourceRecordSet, como 30
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A Para obtener una lista de los tipos de registros compatibles, consulta Tipos de registros compatibles con las políticas de enrutamiento de DNS
  • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
  • ROUTING_POLICY_DATA: ingresa una lista delimitada por punto y coma en el formato ${region}=${IP_address}, por ejemplo, asia-east1=198.51.100.1;us-central1=203.0.113.1. Puedes especificar varias direcciones IP para una sola región agregando direcciones IP separadas por coma. Los nombres de las reglas de reenvío son valores aceptables y generan verificaciones de estado
  • --enable-health-checking: la marca para habilitar la verificación de estado. Cuando usas esta marca, debes brindar el nombre de la regla de reenvío en lugar de la dirección IP en el campo --routing-policy-data

Ubicación geográfica con 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

Reemplaza lo siguiente:

  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
  • TTL: el TTL en segundos en el que el agente de resolución almacena en caché ResourceRecordSet, como 30
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A Para obtener una lista de los tipos de registros compatibles, consulta Tipos de registros compatibles con las políticas de enrutamiento de DNS
  • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
  • ROUTING_POLICY_DATA: ingresa una lista delimitada por punto y coma en el formato ${region}=${IP_address}, por ejemplo, asia-east1=198.51.100.1;us-central1=203.0.113.1. Puedes especificar varias direcciones IP para una sola región agregando direcciones IP separadas por coma. Los nombres de las reglas de reenvío son valores aceptables y generan verificaciones de estado
  • --enable-geo-fencing: para las políticas de enrutamiento de GEO, 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 ninguno de los extremos de esa región está en buen estado. Usa --no-enable-geo-fencing para inhabilitar el geovallado. Cuando 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
  • --enable-health-checking: la marca para habilitar la verificación de estado. Cuando usas esta marca, debes brindar el nombre de la regla de reenvío en lugar de la dirección IP en el campo --routing-policy-data

Conmutación por error

gcloud dns record-sets create RRSET_NAME \
  --ttl=TTL \
  --type=RRSET_TYPE \
  --zone=MANAGED_ZONE \
  --routing-policy-type=FAILOVER  \
  --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-geo-fencing \
  --enable-health-checking

Reemplaza lo siguiente:

  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
  • TTL: el TTL en segundos en el que el agente de resolución almacena en caché ResourceRecordSet, como 30
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A Para obtener una lista de los tipos de registros compatibles, consulta Tipos de registros compatibles con las políticas de enrutamiento de DNS
  • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
  • ROUTING_POLICY_PRIMARY_DATA: el objetivo principal que se usa 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. Mientras al menos una de estas reglas de reenvío esté en buen estado, se usarán las direcciones IP de todas las reglas de reenvío en buen estado para responder las consultas de este nombre
  • ROUTING_POLICY_BACKUP_DATA_TYPE: para las políticas de enrutamiento FAILOVER, es el tipo de política de enrutamiento que usan los datos de la copia de seguridad. Debe ser GEO
  • ROUTING_POLICY_BACKUP_DATA: el destino de la copia de seguridad que se usa para las políticas de enrutamiento de FAILOVER. Estos destinos se usan cuando ninguna de las reglas de reenvío especificadas en --routing-policy-primary-data está en buen estado. Cloud DNS solo admite destinos de copias 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: la proporción de tráfico que se envía a los destinos de la copia de seguridad, incluso cuando los principales estén en buen estado. La proporción debe estar entre 0 y 1, como 0.1. El valor predeterminado es 0
  • --enable-geo-fencing: para las políticas de enrutamiento de GEO, 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 ninguno de los extremos de esa región está en buen estado. Usa --no-enable-geo-fencing para inhabilitar el geovallado. Cuando 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
  • --enable-health-checking: la marca para habilitar la verificación de estado. Cuando usas esta marca, debes brindar 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.

WRR

POST https://dns.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_ID"
                "region": "REGION"
              }
            ]
          }
        },
        {
          "weight": WEIGHT,
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "LOAD_BALANCER_TYPE"
                "ipAddress": "IP_ADDRESS"
                "port": "PORT_NUMBER"
                "ipProtocol": "IP_PROTOCOL"
                "networkUrl": "NETWORK_URL"
                "project": "PROJECT_ID"
                "region": "REGION"
              }
            ]
          }
        }
      ]
    }
  }
}

Reemplaza lo siguiente:

  • PROJECT_ID: el ID del proyecto
  • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A
  • TTL: el TTL en segundos en el que el agente de resolución almacena en caché este ResourceRecordSet, como 30
  • WEIGHT: para las políticas WRR, ingresa 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 no 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
  • LOAD_BALANCER_TYPE: el tipo de balanceador de cargas, como regionalL4ilb, globalL7ilb o regionalL7ilb. Este parámetro de configuración es opcional
  • IP_ADDRESS: la dirección IP que entrega la regla de reenvío
  • PORT_NUMBER 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: la región en la que creaste la regla de reenvío

Ubicación geográfica

POST https://dns.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_ID"
                "region": "REGION"
              }
            ]
          }
        },
        {
          "location": "LOCATION",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "LOAD_BALANCER_TYPE"
                "ipAddress": "IP_ADDRESS"
                "port": "PORT_NUMBER"
                "ipProtocol": "IP_PROTOCOL"
                "networkUrl": "NETWORK_URL"
                "project": "PROJECT_ID"
                "region": "REGION"
              }
            ]
          }
        }
      ]
    }
  }
}

Reemplaza lo siguiente:

  • PROJECT_ID: el ID del proyecto
  • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A
  • TTL: el TTL en segundos en el que el agente de resolución almacena en caché este ResourceRecordSet, como 30
  • LOCATION: para las políticas GEO, la ubicación geográfica para la que necesitas crearla, como asia-east1
  • LOAD_BALANCER_TYPE: el tipo de balanceador de cargas, como regionalL4ilb, globalL7ilb o regionalL7ilb. Este parámetro de configuración es opcional
  • IP_ADDRESS: la dirección IP que entrega la regla de reenvío
  • PORT_NUMBER: el número de puerto del balanceador de cargas interno
  • 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: la región en la que creaste la regla de reenvío

Conmutación por error

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

POST https://dns.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_ID"
            "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, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A
  • TTL: el TTL en segundos en el que el agente de resolución almacena en caché este ResourceRecordSet, como 30
  • TRICKLE_TRAFFIC: la proporción de tráfico que se enviará a los destinos de copia de seguridad incluso cuando los principales estén en buen estado. La proporción debe estar entre 0 y 1, como 0.1
  • IP_ADDRESS: la dirección IP que entrega la regla de reenvío
  • PORT_NUMBER 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
  • PORT_NUMBER: el número de puerto del balanceador de cargas interno
  • REGION: la región en la que creaste la regla de reenvío
  • ENABLE_FENCING: para las políticas de enrutamiento de GEO, 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 ninguno de los extremos de esa región está en buen estado. Cuando 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 crearla, como asia-east1
  • WEIGHT: para las políticas WRR, ingresa 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
  • RRDATA: 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

Crea políticas de enrutamiento de DNS para zonas públicas

Para crear políticas de enrutamiento de DNS para zonas públicas, sigue estos pasos.

Consola

Inicia la configuración

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

    Ir a Zonas de Cloud DNS

  2. Haz clic en el nombre de la zona administrada a la que deseas agregar el registro.

  3. En la página Detalles de la zona, haz clic en Agregar con una política de enrutamiento.

Datos base

  1. Opcional: En la página Crea un conjunto de registros con política de enrutamiento, en Nombre de DNS, ingresa un subdominio del nombre de DNS completado previamente, por ejemplo, mail. El punto final se agrega de forma automática.

  2. En Tipo de registro del recurso, selecciona una opción.

  3. En 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.

  4. Opcional: En Unidad TTL, selecciona la unidad de tiempo, por ejemplo, minutes. El valor predeterminado es minutes

  5. Haz clic en Siguiente.

Tipo de política de enrutamiento

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

Datos de políticas de enrutamiento

WRR

  1. En Peso, ingresa el peso correspondiente a esta subartículo de los datos del registro de recursos (RR).

    Este peso debe ser un número no negativo entre 0.0 y 1,000.0. La proporción del tráfico enrutado al destino se calcula a partir de la proporción del peso individual sobre el total en todos los pesos. Por ejemplo, si el destino A pesa 25 y el destino B pesa 75, es decir, que el peso total es 100, Cloud DNS enruta el 25/100 = 0.25 (25%) del tráfico total al destino A y el 75/100 = 0.75 (75%) al destino B.

  2. En la sección Direcciones IP externas, haz lo siguiente:

    1. En Dirección IP, ingresa una dirección IP externa.
    2. Opcional: Para seleccionar una dirección IP externa de un recurso de Google Cloud en el proyecto actual, haz clic en Seleccionar.
    3. Para habilitar la verificación de estado, selecciona Verificación de estado 1.
    4. Opcional: Para agregar otra dirección IP externa, haz clic en Agregar dirección IP.
    5. Haz clic en Listo.
  3. Si habilitaste la verificación de estado en el paso anterior, en la lista Verificación de estado, selecciona una verificación de estado o crea una nueva siguiendo estos pasos.

    1. Haz clic en Crear una verificación de estado nueva.
    2. En Nombre, ingresa un nombre para la verificación de estado.
    3. Opcional: En Descripción, ingresa una descripción para la verificación de estado.
    4. En Regiones de origen, selecciona tres regiones de Google Cloud desde las que quieras enviar sondeos de verificación de estado.
    5. Opcional: En la lista Protocolo, selecciona uno.
    6. En Puerto, ingresa un número de puerto.

      El protocolo y el número de puerto determinan cómo Cloud DNS envía los sondeos de verificación de estado.

    7. Opcional: Para configurar la verificación de estado basada en el contenido, en Respuesta, brinda una cadena de respuesta esperada, cada una de hasta 1,024 caracteres ASCII (de un solo byte) de longitud.

    8. Opcional: Para activar los registros de verificación de estado, en Registros, selecciona Activado.

    9. En Intervalo de verificación, ingresa el intervalo de tiempo en segundos entre los sondeos de verificación de estado. El intervalo de verificación es la cantidad de tiempo desde el inicio de un sondeo emitido por un sistema de sondeo hasta el inicio del siguiente emitido por el mismo sistema.

    10. En Tiempo de espera, ingresa la cantidad de tiempo en segundos que deseas que Google Cloud espere una respuesta a un sondeo.

    11. En Umbral de buen estado, ingresa la cantidad de resultados de sondeos correctos consecutivos para que se considere que un backend está en buen estado.

    12. En Umbral de mal estado, ingresa la cantidad de resultados de sondeos fallidos consecutivos para que se considere que un backend está en mal estado.

    13. Haz clic en Crear.

  4. Haz clic en Siguiente

Ubicación geográfica

  1. En Geovallado, selecciona Inhabilitado o Habilitado. Habilitar el geovallado restringe el tráfico a una ubicación geográfica específica, incluso si ninguno de los extremos de esa ubicación geográfica está en buen estado.
  2. En Región de origen, selecciona una región de origen válida de Google Cloud.
  3. En la sección Direcciones IP externas, haz lo siguiente:
    1. En Dirección IP, ingresa una dirección IP externa.
    2. Opcional: Para seleccionar una dirección IP externa de un Google Cloud recurso en el proyecto actual, haz clic en Seleccionar.
    3. Para habilitar la verificación de estado, selecciona Verificación de estado 1.
    4. Opcional: Para agregar otra dirección IP externa, haz clic en Agregar dirección IP.
    5. Haz clic en Listo.
  4. Si habilitaste la verificación de estado en el paso anterior, en la lista Verificación de estado, selecciona una verificación de estado o crea una nueva siguiendo estos pasos.

    1. Haz clic en Crear una verificación de estado nueva.
    2. En Nombre, ingresa un nombre para la verificación de estado.
    3. Opcional: En Descripción, ingresa una descripción para la verificación de estado.
    4. En Regiones de origen, selecciona tres regiones de Google Cloud desde las que quieras enviar sondeos de verificación de estado.
    5. Opcional: En la lista Protocolo, selecciona uno.
    6. En Puerto, ingresa un número de puerto.

      El protocolo y el número de puerto determinan cómo Cloud DNS envía los sondeos de verificación de estado.

    7. Opcional: Para configurar la verificación de estado basada en el contenido, en Respuesta, brinda una cadena de respuesta esperada, cada una de hasta 1,024 caracteres ASCII (de un solo byte) de longitud.

    8. Opcional: Para activar los registros de verificación de estado, en Registros, selecciona Activado.

    9. En Intervalo de verificación, ingresa el intervalo de tiempo en segundos entre los sondeos de verificación de estado. El intervalo de verificación es la cantidad de tiempo desde el inicio de un sondeo emitido por un sistema de sondeo hasta el inicio del siguiente emitido por el mismo sistema.

    10. En Tiempo de espera, ingresa la cantidad de tiempo en segundos que deseas que Google Cloud espere una respuesta a un sondeo.

    11. En Umbral de buen estado, ingresa la cantidad de resultados de sondeos correctos consecutivos para que se considere que un backend está en buen estado.

    12. En Umbral de mal estado, ingresa la cantidad de resultados de sondeos fallidos consecutivos para que se considere que un backend está en mal estado.

    13. Haz clic en Crear.

  5. Haz clic en Siguiente

Conmutación por error

  1. En la sección Destino de la dirección IP externa principal, en Dirección IP, ingresa la dirección IP externa principal a la que se le verifica el estado en este registro.
  2. Opcional: Para seleccionar una dirección IP externa principal de un recurso de Google Cloud en el proyecto actual, haz clic en Seleccionar.
  3. Opcional: Para agregar otra dirección IP externa principal, haz clic en Agregar destino. Cuando las DNSSEC están habilitadas, solo puedes agregar un objetivo de dirección IP externa principal.
  4. En la sección Política de ubicación geográfica con 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 ninguno de los extremos de esa ubicación geográfica está en buen estado.
    2. En Región de origen, selecciona una región de origen válida de Google Cloud.
    3. En la sección Direcciones IP externas, haz lo siguiente:
      1. En Dirección IP, ingresa una dirección IP externa.
      2. Opcional: Para seleccionar una dirección IP externa de un recurso de Google Cloud en el proyecto actual, haz clic en Seleccionar.
      3. Para habilitar la verificación de estado, selecciona Verificación de estado 1.
      4. Opcional: Para agregar otra dirección IP externa, haz clic en Agregar dirección IP.
    4. Haz clic en Listo.
  5. Si habilitaste la verificación de estado en el paso anterior, en la lista Verificación de estado, selecciona una verificación.

    Si no tienes una verificación de estado existente, crea una nueva.

    1. Haz clic en Crear una verificación de estado nueva.
    2. En Nombre, ingresa un nombre para la verificación de estado.
    3. Opcional: En Descripción, ingresa una descripción para la verificación de estado.
    4. En Regiones de origen, selecciona tres regiones de Google Cloud desde las que quieras enviar sondeos de verificación de estado.
    5. Opcional: En la lista Protocolo, selecciona uno.
    6. En Puerto, ingresa un número de puerto.

    El protocolo y el número de puerto determinan cómo Cloud DNS envía los sondeos de verificación de estado.

    1. Opcional: Para configurar la verificación de estado basada en el contenido, en Respuesta, brinda una cadena de respuesta esperada, cada una de hasta 1,024 caracteres ASCII (de un solo byte) de longitud.
    2. Opcional: Para activar los registros de verificación de estado, en Registros, selecciona Activado.
    3. En Intervalo de verificación, ingresa el intervalo de tiempo en segundos entre los sondeos de verificación de estado. El intervalo de verificación es la cantidad de tiempo desde el inicio de un sondeo emitido por un sistema de sondeo hasta el inicio del siguiente emitido por el mismo sistema.
    4. En Tiempo de espera, ingresa la cantidad de tiempo en segundos que deseas que Google Cloud espere una respuesta a un sondeo.
    5. En Umbral de buen estado, ingresa la cantidad de resultados de sondeos correctos consecutivos para que se considere que un backend está en buen estado.
    6. En Umbral de mal estado, ingresa la cantidad de resultados de sondeos fallidos consecutivos para que se considere que un backend está en mal estado.
    7. Haz clic en Crear.
  6. En el campo Goteo de tráfico (%), ingresa el porcentaje del tráfico que se envía a los destinos de conmutación por error, sin importar cómo resultó la verificación de estado de los destinos principales.

  7. En la lista Verificación de estado, selecciona una verificación.

  8. Haz clic en Siguiente.

Revisar y crear

  1. Haz clic en Revisar.
  2. Revisa tu conjunto de registros de Cloud DNS con la configuración de la política de enrutamiento.
  3. Haz clic en Crear.

gcloud

Para crear políticas de enrutamiento de DNS para zonas públicas, sigue estos pasos.

  1. Para habilitar la verificación de estado en las políticas de enrutamiento de DNS para zonas públicas, crea una verificación de estado para los extremos externos.

    Ejecuta el comando gcloud beta compute health-checks create:

    gcloud beta compute health-checks create PROTOCOL HEALTH_CHECK_NAME \
        --global \
        --check-interval=CHECK_INTERVAL \
        --source-regions=SOURCE_REGIONS \
        --port=PORT_NUMBER
    

    Reemplaza lo siguiente:

    • PROTOCOL: el protocolo que se usa para la verificación de estado. Las opciones válidas son http, https, ssl o tcp
    • HEALTH_CHECK_NAME: el nombre de la verificación de estado
    • CHECK_INTERVAL la cantidad de tiempo desde el inicio de la conexión de un sistema de sondeo de verificación de estado hasta el inicio de la siguiente. Las unidades son segundos. El valor CHECK_INTERVAL debe estar entre 30 y 300 segundos
    • SOURCE_REGIONS: una lista separada por comas de las regiones deGoogle Cloud desde las que deseas enviar sondeos de verificación de estado
    • PORT_NUMBER: el número de puerto para las solicitudes de verificación de estado
  2. Para crear un ResourceRecordSet y aplicarle una política de enrutamiento, ejecuta el comando gcloud beta dns record-sets create.

    WRR

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

    Reemplaza lo siguiente:

    • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
    • TTL: el TTL en segundos en el que el agente de resolución almacena en caché este ResourceRecordSet, como 30
    • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A
    • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
    • ROUTING_POLICY_DATA: los datos de la política de enrutamiento. Ingresa una lista delimitada por punto y coma en el formato ${weight_percent}:${rrdatas}, como .8=203.0.113.1;.2=198.51.100.1. Especifica el peso como un decimal no negativo. El peso debe ser un número no negativo entre 0 y 1000
    • HEALTH_CHECK_NAME: el nombre de la verificación de estado que creaste en el paso anterior

    Ubicación geográfica

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

    Reemplaza lo siguiente:

    • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
    • TTL: el TTL en segundos en el que el agente de resolución almacena en caché este ResourceRecordSet, como 30
    • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A
    • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
    • ROUTING_POLICY_DATA: los datos de la política de enrutamiento. Ingresa una lista delimitada por punto y coma en el formato ${region}=${IP_address},${IP_address}, como asia-east1=198.51.100.1;us-central1=203.0.113.1, 203.0.113.2. Puedes especificar varias direcciones IP para una sola región agregando direcciones IP separadas por coma. Los nombres de las reglas de reenvío son valores aceptables y generan verificaciones de estado
    • HEALTH_CHECK_NAME: el nombre de la verificación de estado que creaste en el paso anterior

    Ubicación geográfica con geovallado

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

    Reemplaza lo siguiente:

    • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
    • TTL: el TTL en segundos en el que el agente de resolución almacena en caché este ResourceRecordSet, como 30
    • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A
    • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
    • ROUTING_POLICY_DATA: los datos de la política de enrutamiento. Ingresa una lista delimitada por punto y coma en el formato ${region}=${IP_address}, como asia-east1=198.51.100.1;us-central1=203.0.113.1. Puedes especificar varias direcciones IP para una sola región agregando direcciones IP separadas por coma. Los nombres de las reglas de reenvío son valores aceptables y generan verificaciones de estado
    • HEALTH_CHECK_NAME: el nombre de la verificación de estado que creaste en el paso anterior

      --enable-geo-fencing: para las políticas de enrutamiento de GEO, 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 ninguno de los extremos de esa región está en buen estado. Usa --no-enable-geo-fencing para inhabilitar el geovallado. Cuando 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

    Conmutación por error

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

    Reemplaza lo siguiente:

    • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
    • TTL: el TTL en segundos en el que el agente de resolución almacena en caché este ResourceRecordSet, como 30
    • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A
    • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
    • ROUTING_POLICY_PRIMARY_DATA: el objetivo principal que se usa 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. Mientras al menos una de estas reglas de reenvío esté en buen estado, se usarán las direcciones IP de todas las reglas de reenvío en buen estado para responder las consultas de este nombre
    • ROUTING_POLICY_BACKUP_DATA: el destino de la copia de seguridad que se usa para las políticas de enrutamiento de FAILOVER. Estos destinos se usan cuando ninguna de las reglas de reenvío especificadas en --routing-policy-primary-data está en buen estado. Cloud DNS solo admite destinos de copias 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 FAILOVER, es el tipo de política de enrutamiento que usan los datos de la copia de seguridad. Debe ser GEO
    • BACKUP_DATA_TRICKLE_RATIO: la proporción de tráfico que se envía a los destinos de la copia de seguridad, incluso cuando los principales estén en buen estado. La proporción debe estar entre 0 y 1, como 0.1. El valor predeterminado es 0
    • HEALTH_CHECK_NAME: el nombre de la verificación de estado que creaste en el paso anterior

API

  1. Para habilitar la verificación de estado en las políticas de enrutamiento de DNS para zonas públicas, usa el método healthChecks.insert.

  2. Para crear un ResourceRecordSet y aplicarle una política de enrutamiento, usa el método resourceRecordSets.create.

    WRR

    POST https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
    {
      "name": "RRSET_NAME",
      "type": "RRSET_TYPE",
      "ttl": TTL,
      "routingPolicy": {
        "healthCheck": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME"
        "wrr": {
          "items": [
            {
              "weight": WEIGHT,
              "rrdata": ["RRDATA"],
              "healthCheckedTargets": {
                "externalEndpoints": ["EXTERNAL_ENDPOINTS"]
              }
            },
            {
              "weight": WEIGHT,
              "rrdata": ["RRDATA"],
              "healthCheckedTargets": {
                "externalEndpoints": ["EXTERNAL_ENDPOINTS"]
              }
            }
          ]
        }
      }
    }
    

    Reemplaza lo siguiente:

    • PROJECT_ID: el ID del proyecto
    • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
    • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
    • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A
    • TTL: el TTL en segundos en el que el agente de resolución almacena en caché este ResourceRecordSet, como 30
    • HEALTH_CHECK_NAME: el nombre de la verificación de estado
    • WEIGHT: para las políticas WRR, ingresa 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 no 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
    • RRDATA: 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
    • EXTERNAL_ENDPOINTS: las direcciones IP de Internet que se verificarán

    Ubicación geográfica

    POST https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
    {
      "name": "RRSET_NAME",
      "type": "RRSET_TYPE",
      "ttl": TTL,
      "routingPolicy": {
        "healthCheck": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME"
        "geo": {
          "enableFencing": ENABLE_FENCING
          "items": [
            {
              "location": "LOCATION",
              "rrdata": ["RRDATA"],
              "healthCheckedTargets": {
                "externalEndpoints": ["EXTERNAL_ENDPOINTS"]
              }
            },
            {
              "location": "LOCATION",
              "rrdata": ["RRDATA"],
              "healthCheckedTargets": {
                "externalEndpoints": ["EXTERNAL_ENDPOINTS"]
              }
            }
          ]
        }
      }
    }
    

    Reemplaza lo siguiente:

    • PROJECT_ID: el ID del proyecto
    • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
    • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
    • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A
    • TTL: el TTL en segundos en el que el agente de resolución almacena en caché este ResourceRecordSet, como 30
    • HEALTH_CHECK_NAME: el nombre de la verificación de estado
    • ENABLE_FENCING: para las políticas de enrutamiento de GEO, 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 ninguno de los extremos de esa región está en buen estado. Cuando 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. Las opciones válidas son true y false. El parámetro de configuración predeterminado es false
    • LOCATION: para las políticas GEO, la ubicación geográfica para la que necesitas crear la política, como asia-east1
    • RRDATA: 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
    • EXTERNAL_ENDPOINTS: las direcciones IP de Internet que se verificarán

    Conmutación por error

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

    POST https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
    {
      "name": "RRSET_NAME",
      "type": "RRSET_TYPE",
      "ttl": TTL,
      "routingPolicy": {
        "healthCheck": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME"
        "primaryBackup": {
          "trickleTraffic": TRICKLE_TRAFFIC,
          "primaryTargets": {
              "rrdata": ["RRDATA"]
          },
          "backupGeoTargets": {
            "enableFencing": ENABLE_FENCING,
            "items": [
              {
                "location": "LOCATION",
                "rrdatas": ["RRDATA]
              },
              {
                "location": "LOCATION",
                "rrdatas": ["RRDATA", "RRDATA"]
              }
            ]
          }
        }
      }
    }
    

    Reemplaza lo siguiente:

    • PROJECT_ID: el ID del proyecto
    • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
    • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
    • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A
    • TTL: el TTL en segundos en el que el agente de resolución almacena en caché este ResourceRecordSet, como 30
    • HEALTH_CHECK_NAME: el nombre de la verificación de estado
    • TRICKLE_TRAFFIC: la proporción de tráfico que se envía a los destinos de la copia de seguridad incluso cuando los principales estén en buen estado. La proporción debe estar entre 0 y 1, como 0.1
    • LOCATION: para las políticas GEO, la ubicación geográfica para la que necesitas crear la política, como asia-east1
    • RRDATA: 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
    • ENABLE_FENCING: para las políticas de enrutamiento de GEO, 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 ninguno de los extremos de esa región está en buen estado. Cuando 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 parámetro de configuración predeterminado es false

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.

Consola

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

    Ir a Zonas de Cloud DNS

  2. Haz clic en la zona para la que deseas actualizar la política de enrutamiento del conjunto de registros de recursos.

  3. En la página Detalles de la zona, junto con el conjunto de registros de recursos que deseas actualizar, haz clic en Editar.

  4. Después de realizar las actualizaciones, haz clic en Guardar.

gcloud

Ejecuta el comando gcloud dns record-sets update:

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

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

Ubicación geográfica con 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

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 y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
  • TTL: el TTL en segundos en el que el agente de resolución almacena en caché este ResourceRecordSet, como 30
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, 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, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada

  • ROUTING_POLICY_TYPE: el tipo de política de enrutamiento

    Ingresa WRR para las políticas de round robin ponderado, GEO para la de ubicación geográfica o FAILOVER para las de conmutación por error. No puedes modificar este campo después de elegir un tipo de política. Solo puedes borrar la política y agregar una nueva con el tipo diferente

  • ROUTING_POLICY_DATA: los datos de la política de enrutamiento

    • Para --routing-policy-type=WRR, ingresa una lista delimitada por punto y coma en el formato ${weight_percent}:${rrdatas}, como .8=203.0.113.1;.2=198.51.100.1. Especifica el peso como un decimal no 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 Los nombres de las reglas de reenvío son valores aceptables y generan verificaciones de estado
    • Para --routing-policy-type=GEO, ingresa una lista delimitada por punto y coma en el formato ${region}=${IP_address}, como asia-east1=198.51.100.1;us-central1=203.0.113.1. Puedes especificar varias direcciones IP para una sola región agregando direcciones IP separadas por coma. Los nombres de las reglas de reenvío son valores aceptables y generan verificaciones 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}

  • --enable-geo-fencing: para las políticas de enrutamiento de GEO, determina si el tráfico debe conmutar por error entre regiones si ninguno de los extremos de una región está en buen estado. Cuando se configura, Cloud DNS siempre dirige las consultas a la región más cercana, incluso si ninguno de los extremos de esa región está en buen estado. Usa --no-enable-geo-fencing para inhabilitar el geovallado. Cuando no se configura, ninguno de los extremos de una región está en buen estado y Cloud DNS dirige las consultas a la siguiente región más cercana. El parámetro de configuración predeterminado es false

  • ROUTING_POLICY_PRIMARY_DATA: el objetivo principal que se usa 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. Mientras al menos una de estas reglas de reenvío esté en buen estado, se usarán las direcciones IP de todas las reglas de reenvío en buen estado para responder las consultas de este nombre

  • ROUTING_POLICY_BACKUP_DATA: el destino de la copia de seguridad que se usa para las políticas de enrutamiento de FAILOVER. Estos destinos se usan cuando ninguna de las reglas de reenvío especificadas en --routing-policy-primary-data está en buen estado. Cloud DNS solo admite destinos de copias 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: la proporción de tráfico que se envía a los destinos de la copia de seguridad incluso cuando los destinos principales estén en buen estado. La proporción debe estar entre 0 y 1, como 0.1. El valor predeterminado está establecido en 0

  • --enable-health-checking: habilita la verificación de estado de las reglas de reenvío que se brindan 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.

WRR

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

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

Reemplaza lo siguiente:

  • PROJECT_ID: el ID del proyecto
  • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A
  • WEIGHT: para las políticas WRR, ingresa 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
  • RRDATA: 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

Ubicación geográfica

Usa el siguiente método.

PATCH https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets/RRSET_NAME/RRSET_TYPE
{
  "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_ID"
                "region": "REGION"
              }
            ]
          }
        },
        {
          "location": "LOCATION",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "LOAD_BALANCER_TYPE"
                "ipAddress": "IP_ADDRESS"
                "port": "PORT_NUMBER"
                "ipProtocol": "IP_PROTOCOL"
                "networkUrl": "NETWORK_URL"
                "project": "PROJECT_ID"
                "region": "REGION"
              }
            ]
          }
        }
      ]
    }
  }
}

Reemplaza lo siguiente:

  • PROJECT_ID: el ID del proyecto
  • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A
  • TTL: el TTL en segundos en el que el agente de resolución almacena en caché este ResourceRecordSet, como 30
  • LOCATION: para las políticas GEO, la ubicación geográfica para la que necesitas actualizar la política, como asia-east1
  • LOAD_BALANCER_TYPE: el tipo de balanceador de cargas, como regionalL4ilb, globalL7ilb o regionalL7ilb. Este parámetro de configuración es opcional
  • IP_ADDRESS: la dirección IP que entrega la regla de reenvío
  • PORT_NUMBER 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: 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 la contiene. Para hacerlo, sigue estos pasos.

Consola

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

    Ir a Zonas de Cloud DNS

  2. Haz clic en la zona para la que deseas borrar el conjunto de registros de recursos.

  3. En la página Detalles de la zona, junto al nombre de DNS del conjunto de registros de recursos que deseas borrar, selecciona la casilla de verificación.

  4. 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 y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, service.example.com
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, 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, por ejemplo, service-zone. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada

API

Usa el método resourceRecordSets.delete.

DELETE https://dns.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, por ejemplo, my-zone-name. El nombre del ResourceRecordSet debe tener como sufijo el nombre de DNS de la zona administrada
  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes y tiene como sufijo el nombre de DNS de esta zona, por ejemplo, test.example.com
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, por ejemplo, A

¿Qué sigue?