Configurar políticas de enrutamiento de DNS y comprobaciones del estado

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

Antes de empezar

  • Para configurar 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.

  • Las políticas de enrutamiento de DNS admiten varias direcciones IP por ubicación geográfica en la política de enrutamiento por geolocalización. Si 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 por geolocalización con una política WRR personalizada con pesos.

  • Aplica solo un tipo de política de enrutamiento a un conjunto de registros de recursos a la vez. No puedes combinar políticas de enrutamiento, excepto cuando configures una política de enrutamiento de conmutación por error. En ese caso, puedes definir una política de enrutamiento por geolocalización como copia de seguridad.

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

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

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

Crear políticas de enrutamiento de DNS para zonas privadas

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

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

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

Consola

Iniciar la configuración

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

    Ir a las zonas de Cloud DNS

  2. Haz clic en el nombre de la zona gestionada a la que quieras añadir el registro.

  3. En la página Detalles de la zona, haga clic en Añadir con política de enrutamiento.

Datos base

  1. Opcional: En la página Create record set with routing policy (Crear conjunto de registros con política de enrutamiento), en DNS name (Nombre de DNS), introduce un subdominio del nombre de DNS. Por ejemplo, mail. El punto final se añade automáticamente.

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

  3. En TTL, introduce un valor numérico para el tiempo de vida del registro del recurso, es decir, el tiempo que puede almacenarse en la caché. Este 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, Geolocalización o Conmutación por error.
  2. Haz clic en Siguiente.

Datos de la política de enrutamiento

WRR

  1. En Peso, introduce el peso correspondiente a esta subsección de los datos del registro de recursos (RR).

    Este peso debe ser un número no negativo comprendido entre 0,0 y 1000,0. La proporción del tráfico dirigido al destino se calcula a partir de la proporción del peso individual con respecto al total de todos los pesos. Por ejemplo, si el destino A tiene un peso de 25 y el destino B tiene un peso de 75, con un peso total de 100, Cloud DNS dirige 25/100 = 0,25 (25 %) del tráfico total al destino A y 75/100= 0,75 (75 %) al destino B.

  2. En la sección Objetivos con comprobación de estado de IPv4, haga lo siguiente:

    1. En Proyecto, selecciona el proyecto en el que se encuentra la regla de reenvío.

    2. En Regla de reenvío, selecciona una regla de reenvío.

      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 añadir otro destino con comprobación de estado, haga clic en Añadir destino.

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

    1. Selecciona Permitir direcciones IPv4 sin comprobación del estado.
    2. En Dirección IPv4, introduce una dirección IPv4.

  6. Opcional: Para añadir otro conjunto de datos de enrutamiento de la política WRR, haz clic en Añadir datos de enrutamiento.

  7. Haz clic en Siguiente.

Geolocalización

  1. En Geovalla, selecciona Inhabilitado o Habilitado.

    Si habilitas la geovalla, el tráfico se restringe a una geolocalización específica, aunque todos los endpoints de esa geolocalización no estén en buen estado.

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

  3. En la sección Objetivos con comprobación de estado de IPv4, haga lo siguiente:

    1. En Proyecto, selecciona el proyecto en el que se encuentra la regla de reenvío.

    2. En Regla de reenvío, selecciona una regla de reenvío.

      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 añadir otro destino con comprobación de estado, haga clic en Añadir destino.

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

    1. Selecciona Permitir direcciones IPv4 sin comprobación del estado.
    2. En Dirección IPv4, introduce una dirección IPv4.

  7. Opcional: Para añadir otro conjunto de datos de enrutamiento de la política de geolocalización, haz clic en Añadir datos de enrutamiento.

  8. Haz clic en Siguiente.

Conmutación por error

  1. En la sección Objetivos principales de comprobación del estado, haga lo siguiente:

    1. En Proyecto, selecciona el proyecto en el que se encuentra la regla de reenvío.

    2. En Regla de reenvío, selecciona una regla de reenvío.

      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 geolocalización de copias de seguridad, haga lo siguiente:

    1. En Geovalla, selecciona Inhabilitado o Habilitado. Si habilitas la geovalla, el tráfico se restringe a una geolocalización específica, aunque todos los endpoints de esa geolocalización no estén en buen estado.
    2. En Región de origen, selecciona una región de origen Google Cloud válida.

    3. En la sección Objetivos con comprobación de estado de IPv4, haga lo siguiente:

      1. En Proyecto, selecciona el proyecto en el que se encuentra la regla de reenvío.

      2. En Regla de reenvío, selecciona una regla de reenvío.

        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 o HTTPS
        • Un proxy TCP

    Cuando todas las direcciones IP principales no están en buen estado, el tráfico se gestiona automáticamente según la política de geolocalización de copia de seguridad.

  3. Haz clic en Listo.

  4. Opcional: Para añadir otro destino con comprobación de estado, haga clic en Añadir destino.

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

    1. Selecciona Permitir direcciones IPv4 sin comprobación del estado.
    2. En Dirección IPv4, introduce una dirección IPv4.

  6. Opcional: Para añadir otro conjunto de datos de enrutamiento de la política de geolocalización de respaldo, haz clic en Añadir datos de enrutamiento.

  7. En el campo Goteo de tráfico (%), introduce el porcentaje del tráfico que se envía a los destinos de conmutación por error, independientemente del estado de la comprobación del estado de los destinos principales.

  8. Haz clic en Siguiente.

Revisar y crear

  1. Haga clic en Revisión.
  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 un conjunto de registros de recursos, se define una política de enrutamiento (routingPolicy) o datos de DNS (rrdatas), pero no ambos. Para cambiar entre una política de enrutamiento y datos DNS, actualiza el conjunto de registros de recursos. Por ejemplo, para cambiar un conjunto de registros de recursos que contenga datos DNS (rrdatas) y que, en su lugar, contenga una política de enrutamiento (routingPolicy), elimina rrdatas y añade 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

Haz los cambios siguientes:

  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com.
  • TTL: el TTL, en segundos, en el que la resolución almacena en caché ResourceRecordSet, como 30.
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A. Para ver una lista de los tipos de registros admitidos, consulta Tipos de registros admitidos en las políticas de enrutamiento de DNS.
  • MANAGED_ZONE: la zona gestionada a la que está afiliada esta ResourceRecordSet, como service-zone. El nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada como sufijo.
  • ROUTING_POLICY_DATA: introduce 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 el peso como un decimal no negativo. La proporción de tráfico que se dirige al destino se calcula a partir de la proporción del peso individual con respecto al total de todos los pesos. Los nombres de las reglas de reenvío son valores aceptables y dan como resultado una comprobación de estado.
  • --enable-health-checking: la marca para habilitar la comprobación del estado. Cuando uses 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.

Geolocalización

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

Haz los cambios siguientes:

  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com.
  • TTL: el TTL, en segundos, en el que la resolución almacena en caché ResourceRecordSet, como 30.
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A. Para ver una lista de los tipos de registros admitidos, consulta Tipos de registros admitidos en las políticas de enrutamiento de DNS.
  • MANAGED_ZONE: la zona gestionada a la que está afiliada esta ResourceRecordSet, como service-zone. El nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada como sufijo.
  • ROUTING_POLICY_DATA: introduce 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. Puedes especificar varias direcciones IP para una sola región añadiendo direcciones IP separadas por comas. Los nombres de las reglas de reenvío son valores aceptables y dan como resultado una comprobación de estado.
  • --enable-health-checking: la marca para habilitar la comprobación del estado. Cuando uses 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.

Geolocalización con geovalla

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

Haz los cambios siguientes:

  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com.
  • TTL: el TTL, en segundos, en el que la resolución almacena en caché ResourceRecordSet, como 30.
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A. Para ver una lista de los tipos de registros admitidos, consulta Tipos de registros admitidos en las políticas de enrutamiento de DNS.
  • MANAGED_ZONE: la zona gestionada a la que está afiliada esta ResourceRecordSet, como service-zone. El nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada como sufijo.
  • ROUTING_POLICY_DATA: introduce 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. Puedes especificar varias direcciones IP para una sola región añadiendo direcciones IP separadas por comas. Los nombres de las reglas de reenvío son valores aceptables y dan como resultado una comprobación de estado.
  • --enable-geo-fencing: en el caso de las políticas de enrutamiento GEO, determina si el tráfico debe conmutar por error entre regiones si todos los endpoints de una región no están en buen estado. Cuando se configura, Cloud DNS siempre dirige las consultas a la región más cercana, aunque todos los endpoints de esa región no estén en buen estado. Usa --no-enable-geo-fencing para inhabilitar la geovalla. Si no se define, Cloud DNS dirige las consultas a la región más cercana cuando todos los endpoints de una región no están en buen estado. El valor predeterminado es false.
  • --enable-health-checking: la marca para habilitar la comprobación del estado. Cuando uses 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.

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

Haz los cambios siguientes:

  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com.
  • TTL: el TTL, en segundos, en el que la resolución almacena en caché ResourceRecordSet, como 30.
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A. Para ver una lista de los tipos de registros admitidos, consulta Tipos de registros admitidos en las políticas de enrutamiento de DNS.
  • MANAGED_ZONE: la zona gestionada a la que está afiliada esta ResourceRecordSet, como service-zone. El nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada como sufijo.
  • ROUTING_POLICY_PRIMARY_DATA: el objetivo principal que se va a usar para las FAILOVER políticas de enrutamiento. Este destino debe ser una referencia a una o varias reglas de reenvío, como forwarding-rule-1. Mientras 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 a las consultas de este nombre.
  • ROUTING_POLICY_BACKUP_DATA_TYPE: en el caso de las políticas de enrutamiento FAILOVER, 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 va a usar en las políticas de enrutamiento de FAILOVER. Estos destinos se usan cuando no están operativos todos los destinos especificados en --routing-policy-primary-data. 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: la proporción de tráfico que se debe enviar a los destinos de copia de seguridad, incluso cuando los principales están en buen estado. La relación debe estar entre 0 y 1, como 0.1. El valor predeterminado es 0.
  • --enable-geo-fencing: en el caso de las políticas de enrutamiento GEO, determina si el tráfico debe conmutar por error entre regiones si todos los endpoints de una región no están en buen estado. Cuando se configura, Cloud DNS siempre dirige las consultas a la región más cercana, aunque todos los endpoints de esa región no estén en buen estado. Usa --no-enable-geo-fencing para inhabilitar la geovalla. Si no se define, Cloud DNS dirige las consultas a la región más cercana cuando todos los endpoints de una región no están en buen estado. El valor predeterminado es false.
  • --enable-health-checking: la marca para habilitar la comprobación del estado. Cuando uses 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.

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

Haz los cambios siguientes:

  • PROJECT_ID: el ID del proyecto
  • MANAGED_ZONE: la zona gestionada a la que está afiliado este ResourceRecordSet, como service-zone; el nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada como sufijo
  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A
  • TTL: el TTL, en segundos, en el que la resolución almacena en caché este ResourceRecordSet, como 30
  • WEIGHT: en el caso de las políticas WRR, una lista delimitada por punto y coma con el formato ${weight_percent}=${rrdatas}, como .8=10.128.1.1;.2=10.130.1.1; especifique el peso como cualquier número decimal no negativo. Nota: Debe especificar el peso como un número no negativo. La proporción de tráfico que se dirige al destino se calcula a partir de la proporción del peso individual con respecto al total de todos los pesos.
  • LOAD_BALANCER_TYPE: el tipo de balanceador de carga, como regionalL4ilb, globalL7ilb o regionalL7ilb. Este ajuste es opcional.
  • IP_ADDRESS: la dirección IP a la que sirve la regla de reenvío
  • PORT_NUMBER: número de puerto
  • IP_PROTOCOL: define el protocolo usado para la comprobació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 has creado la regla de reenvío`

Geolocalización

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

      }
  }
}

Haz los cambios siguientes:

  • PROJECT_ID: el ID del proyecto
  • MANAGED_ZONE: la zona gestionada a la que está afiliado este ResourceRecordSet, como service-zone; el nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada como sufijo
  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A
  • TTL: el TTL, en segundos, en el que la resolución almacena en caché este ResourceRecordSet, como 30
  • LOCATION: en el caso de las políticas de GEO, la geolocalización para la que necesitas crear la política, como asia-east1
  • LOAD_BALANCER_TYPE: el tipo de balanceador de carga, como regionalL4ilb, globalL7ilb o regionalL7ilb. Este ajuste es opcional.
  • IP_ADDRESS: la dirección IP a la que sirve la regla de reenvío
  • PORT_NUMBER: número de puerto del balanceador de carga interno.
  • IP_PROTOCOL: define el protocolo usado para la comprobació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 has creado la regla de reenvío

Conmutación por error

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_ID"
          "region": "REGION"
        }
      ]
    },
    "backupGeoTargets": {
      "enableFencing": ENABLE_FENCING,
      "items": [
        {
          "location": "LOCATION",
          "rrdatas": [
            "RRDATA"
          ]
        },
        {
          "location": "LOCATION",
          "rrdatas": [
            "RRDATA"
          ]
        }
      ]
    }
  },
}
}

Haz los cambios siguientes:

  • PROJECT_ID: el ID del proyecto
  • MANAGED_ZONE: la zona gestionada a la que está afiliado este ResourceRecordSet, como service-zone; el nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada como sufijo
  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A
  • TTL: el TTL, en segundos, en el que la resolución almacena en caché este ResourceRecordSet, como 30
  • TRICKLE_TRAFFIC: la proporción de tráfico que se debe 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 a la que sirve la regla de reenvío
  • PORT_NUMBER: número de puerto
  • IP_PROTOCOL: define el protocolo usado para la comprobació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: número de puerto del balanceador de carga interno.
  • REGION: la región en la que has creado la regla de reenvío
  • ENABLE_FENCING: en el caso de las políticas de enrutamiento GEO, determina si el tráfico debe conmutar por error entre regiones si todos los endpoints de una región están en mal estado. Cuando se define, Cloud DNS siempre dirige las consultas a la región más cercana, aunque todos los endpoints de esa región no estén en buen estado. Si no se define, Cloud DNS dirige las consultas a la región más cercana cuando todos los endpoints de una región no están en buen estado. El valor predeterminado es false.
  • LOCATION: en el caso de las políticas de GEO, la geolocalización para la que necesitas crear la política, como asia-east1
  • WEIGHT: en el caso de las políticas WRR, una lista delimitada por punto y coma con el formato ${weight_percent}=${rrdatas}, como .8=10.128.1.1;.2=10.130.1.1. Especifica el peso como cualquier número decimal no negativo.
  • RRDATA: valor arbitrario asociado al conjunto de registros de recursos, como 198.51.100.5. También puede introducir varios valores, rrdata1 rrdata2 rrdata3, como 198.51.100.1 203.0.113.1...

Crear 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

Iniciar la configuración

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

    Ir a las zonas de Cloud DNS

  2. Haz clic en el nombre de la zona gestionada a la que quieras añadir el registro.

  3. En la página Detalles de la zona, haga clic en Añadir con política de enrutamiento.

Datos base

  1. Opcional: En la página Create record set with routing policy (Crear conjunto de registros con política de enrutamiento), en DNS name (Nombre de DNS), introduce un subdominio del nombre de DNS rellenado automáticamente. Por ejemplo, mail. El punto final se añade automáticamente.

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

  3. En TTL, introduce un valor numérico para el tiempo de vida del registro del recurso, es decir, el tiempo que puede almacenarse en la caché. Este 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, Geolocalización o Conmutación por error.
  2. Haz clic en Siguiente.

Datos de la política de enrutamiento

WRR

  1. En Peso, introduce el peso correspondiente a esta subsección de los datos del registro de recursos (RR).

    Este peso debe ser un número no negativo comprendido entre 0,0 y 1000,0. La proporción del tráfico dirigido al destino se calcula a partir de la proporción del peso individual con respecto al total de todos los pesos. Por ejemplo, si el destino A tiene un peso de 25 y el destino B tiene un peso de 75, con un peso total de 100, Cloud DNS dirige 25/100 = 0,25 (25 %) del tráfico total al destino A y 75/100= 0,75 (75 %) al destino B.

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

    1. En Dirección IP , introduzca una dirección IP externa.
    2. Opcional: Para seleccionar una dirección IP externa de un Google Cloud recurso del proyecto actual, haz clic en Seleccionar.
    3. Para habilitar la comprobación del estado, selecciona Comprobación del estado 1.
    4. Opcional: Para añadir otra dirección IP externa, haz clic en Añadir dirección IP.
    5. Haz clic en Listo.

  3. Si has habilitado la comprobación del estado en el paso anterior, en la lista Comprobación del estado, selecciona una comprobación del estado o crea una siguiendo estos pasos.

    1. Haz clic en Crear una comprobación del estado.
    2. En Name (Nombre), introduce un nombre para la comprobación del estado.
    3. Opcional: En Descripción, escribe una descripción de la comprobación de estado.
    4. En Regiones de origen, selecciona tres Google Cloud regiones desde las que quieras enviar sondeos de comprobación del estado.
    5. Opcional: En la lista Protocolo, seleccione un protocolo.

    6. En Puerto, introduce un número de puerto.

      El protocolo y el número de puerto determinan cómo envía Cloud DNS las sondas de comprobación del estado.

    7. Opcional: Para configurar la comprobación de estado basada en el contenido, en Respuesta, proporciona una cadena de respuesta esperada, de hasta 1024 caracteres ASCII (de un byte) cada una.

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

    9. En Intervalo de comprobación, introduce el intervalo de tiempo en segundos entre las comprobaciones del estado. El intervalo de comprobación es el tiempo que transcurre desde el inicio de una comprobación emitida por un comprobador hasta el inicio de la siguiente comprobación emitida por el mismo comprobador.

    10. En Tiempo de espera, introduce el tiempo en segundos que quierasGoogle Cloud esperar para recibir una respuesta a una petición.

    11. En Umbral de buen estado, introduzca el número de resultados de sondeo correctos consecutivos para que un backend se considere en buen estado.

    12. En Umbral de estado incorrecto, introduzca el número de resultados de sondeo fallidos consecutivos para que un backend se considere en mal estado.

    13. Haz clic en Crear.

  4. Haz clic en Siguiente.

Geolocalización

  1. En Geovalla, selecciona Inhabilitado o Habilitado. Si habilitas la geovalla, el tráfico se restringe a una geolocalización específica, aunque todos los endpoints de esa geolocalización no estén en buen estado.
  2. En Región de origen, selecciona una región de origen Google Cloud válida.
  3. En la sección Direcciones IP externas, haga lo siguiente:
    1. En Dirección IP , introduzca una dirección IP externa.
    2. Opcional: Para seleccionar una dirección IP externa de un recurso de Google Cloud del proyecto actual, haz clic en Seleccionar.
    3. Para habilitar la comprobación del estado, selecciona Comprobación del estado 1.
    4. Opcional: Para añadir otra dirección IP externa, haz clic en Añadir dirección IP.
    5. Haz clic en Listo.

  4. Si has habilitado la comprobación del estado en el paso anterior, en la lista Comprobación del estado, selecciona una comprobación del estado o crea una siguiendo estos pasos.

    1. Haz clic en Crear una comprobación del estado.
    2. En Name (Nombre), introduce un nombre para la comprobación del estado.
    3. Opcional: En Descripción, escribe una descripción de la comprobación de estado.
    4. En Regiones de origen, selecciona tres Google Cloud regiones desde las que quieras enviar sondeos de comprobación del estado.
    5. Opcional: En la lista Protocolo, seleccione un protocolo.

    6. En Puerto, introduce un número de puerto.

      El protocolo y el número de puerto determinan cómo envía Cloud DNS las sondas de comprobación del estado.

    7. Opcional: Para configurar la comprobación de estado basada en el contenido, en Respuesta, proporciona una cadena de respuesta esperada, de hasta 1024 caracteres ASCII (de un byte) cada una.

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

    9. En Intervalo de comprobación, introduce el intervalo de tiempo en segundos entre las comprobaciones del estado. El intervalo de comprobación es el tiempo que transcurre desde el inicio de una comprobación emitida por un comprobador hasta el inicio de la siguiente comprobación emitida por el mismo comprobador.

    10. En Tiempo de espera, introduce el tiempo en segundos que quierasGoogle Cloud esperar para recibir una respuesta a una petición.

    11. En Umbral de buen estado, introduzca el número de resultados de sondeo correctos consecutivos para que un backend se considere en buen estado.

    12. En Umbral de estado incorrecto, introduzca el número de resultados de sondeo fallidos consecutivos para que un backend se considere 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, introduce la dirección IP externa principal cuya salud se comprueba en este registro.
  2. Opcional:Para seleccionar una dirección IP externa principal de un Google Cloud recurso del proyecto actual, haz clic en Seleccionar.
  3. Opcional: Para añadir otra dirección IP externa principal, haz clic en Añadir destino. Cuando DNSSEC está habilitado, solo puedes añadir un destino de dirección IP externa principal .
  4. En la sección Política de geolocalización de copias de seguridad, haga lo siguiente:
    1. En Geovalla, selecciona Inhabilitado o Habilitado. Si habilitas la geovalla, el tráfico se restringe a una geolocalización específica, aunque todos los endpoints de esa geolocalización no estén en buen estado.
    2. En Región de origen, selecciona una región de origen Google Cloud válida.
    3. En la sección Direcciones IP externas, haga lo siguiente:
      1. En Dirección IP , introduzca una dirección IP externa.
      2. Opcional: Para seleccionar una dirección IP externa de un Google Cloud recurso del proyecto actual, haz clic en Seleccionar.
      3. Para habilitar la comprobación del estado, selecciona Comprobación del estado 1.
      4. Opcional: Para añadir otra dirección IP externa, haz clic en Añadir dirección IP.
    4. Haz clic en Listo.

  5. Si has habilitado la comprobación del estado en el paso anterior, selecciona una comprobación del estado en la lista Comprobación del estado.

    Si no tienes ninguna comprobación del estado, crea una.

    1. Haz clic en Crear una comprobación del estado.
    2. En Name (Nombre), introduce un nombre para la comprobación del estado.
    3. Opcional: En Descripción, escribe una descripción de la comprobación de estado.
    4. En Regiones de origen, selecciona tres Google Cloud regiones desde las que quieras enviar sondeos de comprobación del estado.
    5. Opcional: En la lista Protocolo, seleccione un protocolo.
    6. En Puerto, introduce un número de puerto.

    El protocolo y el número de puerto determinan cómo envía Cloud DNS las sondas de comprobación del estado.

    1. Opcional: Para configurar la comprobación de estado basada en el contenido, en Respuesta, proporciona una cadena de respuesta esperada, de hasta 1024 caracteres ASCII (de un byte) cada una.
    2. Opcional: Para activar los registros de comprobación del estado, en Registros, selecciona Activado.
    3. En Intervalo de comprobación, introduce el intervalo de tiempo en segundos entre las comprobaciones del estado. El intervalo de comprobación es el tiempo que transcurre desde el inicio de una comprobación emitida por un comprobador hasta el inicio de la siguiente comprobación emitida por el mismo comprobador.
    4. En Tiempo de espera, introduce el tiempo en segundos que quierasGoogle Cloud esperar para recibir una respuesta a una petición.
    5. En Umbral de buen estado, introduzca el número de resultados de sondeo correctos consecutivos para que un backend se considere en buen estado.
    6. En Umbral de estado incorrecto, introduzca el número de resultados de sondeo fallidos consecutivos para que un backend se considere en mal estado.
    7. Haz clic en Crear.

  6. En el campo Goteo de tráfico (%), introduce el porcentaje del tráfico que se envía a los destinos de conmutación por error, independientemente del estado de la comprobación del estado de los destinos principales.

  7. En la lista Comprobación del estado, selecciona una comprobación del estado.

  8. Haz clic en Siguiente.

Revisar y crear

  1. Haga clic en Revisión.
  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 comprobación del estado en las políticas de enrutamiento de DNS de zonas públicas, crea una comprobación del estado para los endpoints 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

    Haz los cambios siguientes:

    • PROTOCOL: el protocolo usado para la comprobación del estado. Las opciones válidas son http, https, ssl o tcp.
    • HEALTH_CHECK_NAME: el nombre de la comprobación del estado.
    • CHECK_INTERVAL: el tiempo transcurrido desde el inicio de la conexión de un sistema de sondeo de comprobación del estado hasta el inicio del siguiente. Las unidades son segundos. El valor de CHECK_INTERVAL debe estar entre 30 y 300 segundos.
    • SOURCE_REGIONS: una lista separada por comas deGoogle Cloud regiones desde las que quieras enviar sondeos de comprobación del estado.
    • PORT_NUMBER: número de puerto para las solicitudes de comprobación del 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

    Haz los cambios siguientes:

    • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com.
    • TTL: el TTL, en segundos, en el que el resolver almacena en caché este ResourceRecordSet, como 30.
    • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A.
    • MANAGED_ZONE: la zona gestionada a la que está afiliada esta ResourceRecordSet, como service-zone. El nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada como sufijo.
    • ROUTING_POLICY_DATA: los datos de la política de enrutamiento. Introduce 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 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 del chequeo de salud que has creado en el paso anterior.

    Geolocalización

    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

    Haz los cambios siguientes:

    • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com.
    • TTL: el TTL, en segundos, en el que el resolver almacena en caché este ResourceRecordSet, como 30.
    • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A.
    • MANAGED_ZONE: la zona gestionada a la que está afiliada esta ResourceRecordSet, como service-zone. El nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada como sufijo.
    • ROUTING_POLICY_DATA: los datos de la política de enrutamiento. Introduce una lista delimitada por punto y coma con 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 misma región añadiendo direcciones IP separadas por comas. Los nombres de las reglas de reenvío son valores aceptables y dan como resultado una comprobación del estado.
    • HEALTH_CHECK_NAME: el nombre del chequeo de salud que has creado en el paso anterior.

    Geolocalización con geovalla

    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

    Haz los cambios siguientes:

    • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com.
    • TTL: el TTL, en segundos, en el que el resolver almacena en caché este ResourceRecordSet, como 30.
    • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A.
    • MANAGED_ZONE: la zona gestionada a la que está afiliada esta ResourceRecordSet, como service-zone. El nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada como sufijo.
    • ROUTING_POLICY_DATA: los datos de la política de enrutamiento. Introduce 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. Puedes especificar varias direcciones IP para una sola región añadiendo direcciones IP separadas por comas. Los nombres de las reglas de reenvío son valores aceptables y dan como resultado una comprobación del estado.

    • HEALTH_CHECK_NAME: el nombre del chequeo de salud que has creado en el paso anterior.

      --enable-geo-fencing: en el caso de las políticas de enrutamiento GEO, determina si el tráfico debe conmutar por error entre regiones si todos los endpoints 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, aunque todos los endpoints de esa región no estén operativos. Usa --no-enable-geo-fencing para inhabilitar la geovalla. Si no se define, Cloud DNS dirige las consultas a la región más cercana cuando todos los endpoints de una región no están en buen estado. El valor predeterminado 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

    Haz los cambios siguientes:

    • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com.
    • TTL: el TTL, en segundos, en el que el resolver almacena en caché este ResourceRecordSet, como 30
    • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A.
    • MANAGED_ZONE: la zona gestionada a la que está afiliada esta ResourceRecordSet, como service-zone. El nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada como sufijo.
    • ROUTING_POLICY_PRIMARY_DATA: el objetivo principal que se va a usar en las políticas de enrutamiento de FAILOVER. Este destino debe ser una referencia a una o varias 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 a las consultas de este nombre.
    • ROUTING_POLICY_BACKUP_DATA: el destino de copia de seguridad que se va a usar en las políticas de enrutamiento de FAILOVER. Estos destinos se usan cuando no están disponibles todas las reglas de reenvío especificadas en --routing-policy-primary-data. 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: en el caso de las políticas de enrutamiento FAILOVER, el tipo de política de enrutamiento que usan los datos de copia de seguridad. Debe ser GEO.
    • BACKUP_DATA_TRICKLE_RATIO: la proporción de tráfico que se debe enviar a los destinos de copia de seguridad, incluso cuando los principales están en buen estado. La relación debe estar comprendida entre 0 y 1, como 0.1. El valor predeterminado es 0.
    • HEALTH_CHECK_NAME: el nombre del chequeo de salud que has creado en el paso anterior.

API

  1. Para habilitar la comprobación del estado en las políticas de enrutamiento de DNS de 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://www.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/beta/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME"
            "wrr": {
                "items": [{
                    "weight": WEIGHT,
                    "healthCheckedTargets": {
                        "rrdata": ["RRDATA"]
                    }
                }, {
                    "weight": 1.0,
                    "healthCheckedTargets": {
                        "rrdata": ["RRDATA", "RRDATA"]
                    }
                }]
            }
        }
    }

    Haz los cambios siguientes:

    • PROJECT_ID: el ID del proyecto
    • MANAGED_ZONE: la zona gestionada a la que está afiliado este ResourceRecordSet, como service-zone; el nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada como sufijo.
    • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com.
    • TTL: el TTL, en segundos, en el que la resolución almacena en caché este ResourceRecordSet, como 30.
    • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A.
    • HEALTH_CHECK_NAME: el nombre de la comprobación del estado.
    • WEIGHT: en el caso de las políticas de WRR, una lista delimitada por punto y coma con el formato ${weight_percent}=${rrdatas}, como .8=10.128.1.1;.2=10.130.1.1; especifique la ponderación como cualquier decimal no negativo. Nota: Debes especificar el peso como un número no negativo. La proporción de tráfico que se dirige al destino se calcula a partir de la proporción del peso individual con respecto al total de todos los pesos.
    • RRDATA: valor arbitrario asociado al conjunto de registros de recursos, como 198.51.100.5. También puedes introducir varios valores, como rrdata1, rrdata2 y rrdata3, como 198.51.100.1 y 203.0.113.1.

    Geolocalización

        POST https://www.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/beta/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME"
            "geo": {
          "enableFencing": ENABLE_FENCING
                "items": [{
                    "location": "LOCATION",
                    "healthCheckedTargets": {
                        "rrdata": ["RRDATA"]
                    }
                }, {
                    "location": "LOCATION",
                    "healthCheckedTargets": {
                        "rrdata": ["RRDATA", "RRDATA"]
                    }
                }]
            }
        }
    }

    Haz los cambios siguientes:

    • PROJECT_ID: el ID del proyecto
    • MANAGED_ZONE: la zona gestionada a la que está afiliado este ResourceRecordSet, como service-zone; el nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada como sufijo.
    • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com.
    • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A.
    • TTL: el TTL, en segundos, en el que la resolución almacena en caché este ResourceRecordSet, como 30.
    • HEALTH_CHECK_NAME: el nombre de la comprobación del estado.
    • ENABLE_FENCING: en el caso de las políticas de enrutamiento GEO, determina si el tráfico debe conmutar por error entre regiones si todos los endpoints de una región están en mal estado. Cuando se define, Cloud DNS siempre dirige las consultas a la región más cercana, aunque todos los endpoints de esa región no estén en buen estado. Si no se define, Cloud DNS dirige las consultas a la región más cercana cuando todos los endpoints de una región no están en buen estado. Las opciones válidas son true y false. El valor predeterminado es false.
    • LOCATION: en el caso de las políticas de GEO, la geolocalización para la que necesitas crear la política, como asia-east1.
    • RRDATA: valor arbitrario asociado al conjunto de registros de recursos, como 198.51.100.5. También puedes introducir varios valores, como rrdata1, rrdata2 y rrdata3, como 198.51.100.1 y 203.0.113.1.

    Conmutación por error

    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": {
            "healthCheck": "https://www.googleapis.com/compute/beta/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"]
                    }]
                }
            }
        }
    }

    Haz los cambios siguientes:

    • PROJECT_ID: el ID del proyecto
    • MANAGED_ZONE: la zona gestionada a la que está afiliado este ResourceRecordSet, como service-zone; el nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada como sufijo.
    • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com.
    • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A.
    • TTL: el TTL, en segundos, en el que la resolución almacena en caché este ResourceRecordSet, como 30.
    • HEALTH_CHECK_NAME: el nombre de la comprobación del estado.
    • TRICKLE_TRAFFIC: es la proporción de tráfico que se debe 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.
    • RRDATA: valor arbitrario asociado al conjunto de registros de recursos, como 198.51.100.5. También puedes introducir varios valores, como rrdata1, rrdata2 y rrdata3, como 198.51.100.1 y 203.0.113.1.
    • ENABLE_FENCING: en el caso de las políticas de enrutamiento GEO, determina si el tráfico debe conmutar por error entre regiones si todos los endpoints de una región están en mal estado. Cuando se define, Cloud DNS siempre dirige las consultas a la región más cercana, aunque todos los endpoints de esa región no estén en buen estado. Si no se define, Cloud DNS dirige las consultas a la región más cercana cuando todos los endpoints de una región no están en buen estado. El ajuste predeterminado es false.
    • LOCATION: en el caso de las políticas de GEO, la geolocalización para la que necesitas crear la política, como asia-east1.

Actualizar 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 Google Cloud consola, ve a la página Zonas de Cloud DNS.

    Ir a las zonas de Cloud DNS

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

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

  4. Cuando hayas hecho los cambios, 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

Geolocalización

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

Geolocalización con geovalla

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

Haz los cambios siguientes:

  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com
  • TTL: el TTL, en segundos, en el que el resolvedor almacena en caché este ResourceRecordSet, como 30

  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A

    Para ver una lista de los tipos de registros admitidos, consulta Seleccionar tipos de registros de recursos.

  • MANAGED_ZONE: la zona gestionada a la que está afiliada esta ResourceRecordSet, como service-zone. El nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada como sufijo.

  • ROUTING_POLICY_TYPE: el tipo de política de enrutamiento.

    Introduce WRR para usar la asignación cíclica ponderada, GEO para usar la geolocalización o FAILOVER para usar las políticas de conmutación por error. No puedes modificar este campo una vez que se haya elegido un tipo para la política. Solo puedes eliminar la política y añadir una nueva con otro tipo.

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

    • En --routing-policy-type=WRR, introduce 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 el peso como un decimal no negativo. La proporción de tráfico que se dirige al destino se calcula a partir de la proporción del peso individual con respecto al total de todos los pesos. Los nombres de las reglas de reenvío son valores aceptables y dan como resultado una comprobación de estado.
    • En --routing-policy-type=GEO, introduce 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. Puedes especificar varias direcciones IP para una sola región añadiendo direcciones IP separadas por comas. Los nombres de las reglas de reenvío son valores aceptables y dan como resultado una comprobación de estado.

    • En --routing-policy-type=FAILOVER, introduce el nombre de la regla de reenvío que has creado con el formato ${region}=${Forwarding rule name}.

  • --enable-geo-fencing: en el caso de las políticas de enrutamiento GEO, determina si el tráfico debe conmutar por error entre regiones si todos los endpoints de una región no están en buen estado. Cuando se configura, Cloud DNS siempre dirige las consultas a la región más cercana, aunque todos los endpoints de esa región no estén en buen estado. Usa --no-enable-geo-fencing para inhabilitar la geovalla. Si no se define, todos los endpoints de una región no estarán en buen estado y Cloud DNS dirigirá las consultas a la región más cercana. El ajuste predeterminado es false.

  • ROUTING_POLICY_PRIMARY_DATA: el objetivo principal que se va a usar para las FAILOVER políticas de enrutamiento. Este destino debe ser una referencia a una o varias reglas de reenvío, como forwarding-rule-1. Mientras 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 a las consultas de este nombre.

  • ROUTING_POLICY_BACKUP_DATA: el destino de la copia de seguridad que se va a usar en las políticas de enrutamiento de FAILOVER. Estos destinos se usan cuando no están operativos todos los destinos especificados en --routing-policy-primary-data. 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: la proporción de tráfico que se debe enviar a los destinos de copia de seguridad aunque los principales estén en buen estado. La relación debe estar entre 0 y 1, como 0.1. El valor predeterminado es 0.

  • --enable-health-checking: habilita la comprobación del 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 los valores rrset.rrdatas o rrset.routingPolicy. Si especificas routingPolicy, debes especificar el nuevo campo routingPolicy por completo.

WRR

Para las políticas de WRR, siga este 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": ["RRDATA"]
                  },
                  {
                      "weight": WEIGHT,
                      "rrdatas": ["RRDATA"]
                  }
            ],
          }
    }
}

Geolocalización

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

      }
  }
}

Haz los cambios siguientes:

  • PROJECT_ID: el ID del proyecto
  • MANAGED_ZONE: la zona gestionada a la que está afiliado este ResourceRecordSet, como service-zone; el nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada como sufijo
  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A
  • TTL: el TTL, en segundos, en el que el resolvedor almacena en caché este ResourceRecordSet, como 30
  • TRICKLE_TRAFFIC: la proporción de tráfico que se debe 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.
  • ENABLE_FENCING: en el caso de las políticas de enrutamiento GEO, determina si el tráfico debe conmutar por error entre regiones si todos los endpoints de una región están en mal estado. Cuando se define, Cloud DNS siempre dirige las consultas a la región más cercana, aunque todos los endpoints de esa región no estén en buen estado. Si no se define, Cloud DNS dirige las consultas a la región más cercana cuando todos los endpoints de una región no están en buen estado. El valor predeterminado es false.
  • LOCATION: para las políticas de GEO, la geolocalización para la que debe actualizar la política, como asia-east1
  • WEIGHT: en el caso de las políticas WRR, una lista delimitada por punto y coma con el formato ${weight_percent}=${rrdatas}, como .8=10.128.1.1;.2=10.130.1.1. Especifica el peso como cualquier número decimal no negativo.
  • RRDATA: valor arbitrario asociado al conjunto de registros de recursos, como 198.51.100.5. También puede introducir varios valores, rrdata1 rrdata2 rrdata3, como 198.51.100.1 203.0.113.1...
  • LOAD_BALANCER_TYPE: el tipo de balanceador de carga, como regionalL4ilb, globalL7ilb o regionalL7ilb. Este ajuste es opcional.
  • IP_ADDRESS: la dirección IP a la que sirve la regla de reenvío
  • PORT_NUMBER: número de puerto
  • IP_PROTOCOL: define el protocolo usado para la comprobació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 has creado la regla de reenvío

Eliminar políticas de enrutamiento de DNS

Para eliminar una política de enrutamiento, debe eliminar el conjunto de registros de recursos que la contiene. Para ello, sigue estos pasos.

Consola

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

    Ir a las zonas de Cloud DNS

  2. Haz clic en la zona de la que quieras eliminar el conjunto de registros de recursos.

  3. En la página Zone details (Detalles de la zona), marque la casilla situada junto al nombre DNS del conjunto de registros de recursos que quiera eliminar.

  4. Haz clic en Eliminar 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 \

Haz los cambios siguientes:

  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes cuyo sufijo es el nombre de DNS de esta zona, como service.example.com

  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A

    Para ver una lista de los tipos de registros admitidos, consulta Seleccionar tipos de registros de recursos.

  • MANAGED_ZONE: la zona gestionada a la que está afiliado este ResourceRecordSet, como service-zone; el nombre de este ResourceRecordSet debe tener el nombre de DNS de la zona gestionada 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

Haz los cambios siguientes:

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

Siguientes pasos