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

Las políticas de enrutamiento DNS dirigen el tráfico según el tipo de consulta (por ejemplo, round robin ponderado o ubicación geográfica). Para configurar estas políticas, crea conjuntos de registros de recursos con valores de políticas de enrutamiento específicos. Estos valores determinar cómo se enruta el tráfico. Por ejemplo, en una política de round robin ponderado, cada conjunto de registros de recursos tiene un peso asignado que afecta el tráfico distribución.

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

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

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

  • Política de enrutamiento de ubicación geográfica (GEO): Usa la ubicación geográfica para especificar las ubicaciones geográficas de origen. y proporcionar respuestas correspondientes a esas ubicaciones geográficas. La ubicación geográfica aplica la coincidencia más cercana a la ubicación de origen cuando la fuente del tráfico no coincide de manera exacta con ningún elemento de la política.

    GEO asigna el origen del DNS público y privado de las siguientes maneras:

    • Para el DNS público: la dirección IP de origen o Mecanismo de extensión para DNS (EDNS) se usará la subred del cliente de la consulta.
    • Para el DNS privado, no se usa la subred de cliente de EDNS. En cambio, la ubicación de la consulta es la ubicación del sistema que envía los paquetes para la consulta:
      • Para consultas realizadas desde una instancia de máquina virtual (VM) con una red en una red de VPC, la ubicación de la consulta es la región que contiene la VM.
      • Para consultas recibidas mediante una entrada de la política del servidor entrante punto, el la ubicación de la consulta es la región del túnel de Cloud VPN, adjunto de VLAN de Cloud Interconnect o dispositivo de router que recibió los paquetes para la consulta. La región del punto de entrada La dirección IP no es relevante. Para obtener más información, consulta la sección Redes y región para solicitudes entrantes consultas en las “políticas del servidor DNS” .

  • Política de enrutamiento con geovallado: usa el geovallado para restringir el tráfico a una ubicación geográfica específica, incluso si todos los extremos de esa ubicación geográfica en mal estado. Para obtener información detallada sobre el geovallado, consulta Políticas de enrutamiento de geovallado.

  • Política de enrutamiento de conmutación por error: Usa la conmutación por error para configurar la copia de seguridad activa. parámetros de configuración. Para obtener más información, consulta Políticas de enrutamiento de conmutación por error.

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

Verificaciones de estado

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

Después de configurar un balanceador de cargas de red de transferencia interno, configura el enrutamiento adecuado política en Cloud DNS con la consola de Google Cloud, gcloud CLI o la API, que especifique el balanceador de cargas de red de transferencia interno. Este paso implica la configuración de varios buckets WRR o GEO, y cada bucket puede contienen varios balanceadores de cargas de red de transferencia internos.

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

Para balanceadores de cargas de aplicaciones internos y balanceadores de cargas de aplicaciones internos entre regiones, Cloud DNS realiza verificaciones el estado general del balanceador de cargas de aplicaciones interno y permite que el balanceador de cargas de aplicaciones interno verificar el estado de las instancias de backend.

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

  • Si hay varias direcciones VIP programadas según una política, entonces solo las direcciones VIP en buen estado.

  • Si todas las direcciones VIP programadas para un bucket de políticas están en mal estado, esa línea de política falló. Se aplica el siguiente comportamiento:

    • En el caso de una política WRR, haz lo siguiente: Cloud DNS distribuye el tráfico al siguiente peso saludable bucket.
    • En el caso de una política GEO que no tiene el vallado habilitado, el tráfico cambia a la siguiente ubicación geográfica más cercana.
    • Para una política con geovallado que tenga el cercado habilitado, las direcciones VIP en el bucket geográfico más cercano se devuelven tal como están.
    • En el caso de una política de conmutación por error, Cloud DNS cambia el tráfico al bucket de conmutación por error.
    • Si todos los buckets de políticas están en mal estado, Cloud DNS se comporta como si todos los extremos están en buen estado.

Antes de comenzar

Este procedimiento supone que completaste lo siguiente:

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

Crea políticas de enrutamiento de DNS

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

Console

Inicie 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 política de enrutamiento.

Datos base

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

  2. Selecciona el Tipo de registros del recursos, por ejemplo, A.

  3. En el campo TTL, ingresa un valor numérico para el tiempo de actividad del registro de recursos. Este valor indica el tiempo que se puede almacenar en caché. El valor debe ser un número entero positivo.

  4. En el menú Unidad TTL, selecciona la unidad de tiempo, por ejemplo, 30 minutes.

  5. Haz clic en Siguiente.

Tipo de política de enrutamiento

  1. En la lista Política de enrutamiento, selecciona Round robin ponderado. Geolocation o Failover.
  2. Haz clic en Siguiente.

Datos de la política de enrutamiento

  1. Si seleccionaste Round robin ponderado, en el Datos de enrutamiento de la política de round robin ponderado, haz lo siguiente:

    1. En el campo Peso, ingresa el peso correspondiente. de los datos de registro de recursos (RR). Esta ponderación debe ser un número no negativo de 0.0 a 1,000.0. Proporción de tráfico enrutado con respecto al objetivo se calcula a partir de la proporción del peso individual sobre el total en todas las ponderaciones.

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

      1. En la lista de Proyectos, selecciona el proyecto en el que se existe una regla de firewall.
      2. En la lista Tipo, selecciona Balanceador de cargas de red de transferencia interno. balanceador de cargas de aplicaciones interno o balanceador de cargas de aplicaciones interno entre regiones.

      3. En la lista Regla de reenvío, selecciona una.

        La regla de reenvío especifica una dirección IP interna, un puerto y un servicio de backend regional o un proxy HTTP(S). Para Cloud DNS para trabajar con verificaciones de estado, debes habilitar el acceso global para el balanceador de cargas interno.

    3. Para permitir direcciones IPv4 sin verificación de estado, Selecciona Permitir direcciones IPv4 sin verificación de estado.

    4. En el campo Dirección IPv4, ingresa una dirección IPv4.

  2. Si seleccionaste Ubicación geográfica, haz lo siguiente:

    1. En Geovallado, selecciona Inhabilitado o Habilitado. Habilitando El geovallado restringe el tráfico a una ubicación geográfica específica incluso si todos los extremos de la ubicación geográfica están en mal estado.
    2. En el menú Región de origen, selecciona una cuenta de Google Cloud válida. región de origen, como asia-east1.

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

      1. En la lista de Proyectos, selecciona el proyecto en el que se existe una regla de firewall.
      2. En la lista Tipo, selecciona Balanceador de cargas de red de transferencia interno. balanceador de cargas de aplicaciones interno o balanceador de cargas de aplicaciones interno entre regiones.

      3. En la lista Regla de reenvío, selecciona una.

        La regla de reenvío especifica una dirección IP interna, un puerto y un servicio de backend regional o un proxy HTTP(S). Para que Cloud DNS funcione con las verificaciones de estado, debes habilitar el acceso global para el balanceador de cargas interno.

    4. Para permitir direcciones IPv4 sin verificación de estado, Selecciona Permitir direcciones IPv4 sin verificación de estado.

    5. En el campo Dirección IPv4, ingresa una dirección IPv4.

  3. Si seleccionaste Conmutación por error, haz lo siguiente:

    1. En el campo Tráfico de goteo (%), ingresa el porcentaje de el tráfico enviado a los destinos de conmutación por error, sin importar el estado de la verificación de estado de los destinos principales.

    2. En la sección Objetivos principales, sigue estos pasos:

      1. En la lista de Proyectos, selecciona el proyecto en el que se existe una regla de firewall.
      2. En la lista Tipo, selecciona Balanceador de cargas de red de transferencia interno. balanceador de cargas de aplicaciones interno o balanceador de cargas de aplicaciones interno entre regiones.

      3. En la lista Regla de reenvío, selecciona una.

        La regla de reenvío especifica una dirección IP interna, un puerto y un servicio de backend regional o un proxy HTTP(S). Para Cloud DNS funcione con verificaciones de estado, debes habilitar acceso global para el balanceador de cargas interno.

    3. En la sección Política de ubicación geográfica de la copia de seguridad, haz lo siguiente:

      1. En Geovallado, selecciona Inhabilitado o Habilitado. Habilitando El geovallado restringe el tráfico a una ubicación geográfica específica incluso si todos los extremos de la ubicación geográfica están en mal estado.
      2. En el menú Región de origen, selecciona una cuenta de Google Cloud válida. región de origen, como asia-east1.

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

        1. En la lista de Proyectos, selecciona el proyecto en el que se existe una regla de firewall.
        2. En la lista Tipo, selecciona Balanceador de cargas de red de transferencia interno. balanceador de cargas de aplicaciones interno o balanceador de cargas de aplicaciones interno entre regiones.
        3. En la lista Regla de reenvío, selecciona una.

        Cuando todas las direcciones IP principales están en mal estado, el tráfico automáticamente de acuerdo con la política de ubicación geográfica de copias de seguridad.

    4. Para permitir direcciones IPv4 sin verificación de estado, Selecciona Permitir direcciones IPv4 sin verificación de estado.

    5. En el campo Dirección IPv4, ingresa una dirección IPv4.

  4. Haz clic en Siguiente.

Revisa y crea

  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. Opcional: Haz clic en Línea de comentario equivalente para ver el gcloud CLI para crear este conjunto de registros con enrutamiento .
  4. Haz clic en Crear.

gcloud

Un ResourceRecordSet puede contener routingPolicy o rrdatas, pero no ambos. Se puede cambiar entre rrdatas o routingPolicy durante la actualización ResourceRecordSets. Por ejemplo, si quieres actualizar un ResourceRecordSet que contiene rrdatas, puedes borrar el rrdatas y agregar un routingPolicy en el mismo ResourceRecordSet.

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

Ejecuta el gcloud dns record-sets create kubectl:

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

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

Para políticas de WRR

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

Para políticas 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

Para políticas de conmutación por error

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

Reemplaza lo siguiente:

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

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

    Para obtener una lista de los tipos de registros compatibles, consulta Selecciona tipos de registros de recursos.

  • MANAGED_ZONE: Es la zona administrada a la que ResourceRecordSet está afiliada, por ejemplo, service-zone. El nombre de este ResourceRecordSet debe tener el nombre de DNS del como sufijo de la zona administrada

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

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

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

    • En --routing-policy-type=WRR, ingresa una lista delimitada por punto y coma en el formato ${weight_percent}:${rrdatas}, como .8=203.0.113.1;.2=198.51.100.1. Especifica el peso como un valor decimal no negativo. Se calcula la proporción del tráfico enrutado al objetivo de la proporción entre el peso individual y el total de todos los pesos. Los nombres de las reglas de reenvío son valores aceptables y dan como resultado la verificación de estado.
    • En --routing-policy-type=GEO, ingresa una lista delimitada por punto y coma 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 separados por comas. Los nombres de las reglas de reenvío son valores aceptables y dan como resultado la verificación de estado.

    • En --routing-policy-type=FAILOVER, ingresa el nombre del reenvío regla de firewall que creaste con el formato ${region}=${Forwarding rule name}.

    Debes especificar el tipo y la política de enrutamiento de datos no estructurados. Si especificas una, no puedes dejar la otra marca sin propagar.

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

  • ROUTING_POLICY_PRIMARY_DATA: Es el destino principal que se usará. para las políticas de enrutamiento de FAILOVER. Este destino debe hacer referencia a una o más reglas de reenvío, como forwarding-rule-1 Siempre y cuando 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 usan para responder consultas de este nombre.

  • ROUTING_POLICY_BACKUP_DATA: Es el destino de la copia de seguridad que se usará. para las políticas de enrutamiento de FAILOVER. Estos objetivos se usan cuando las reglas de reenvío especificadas en --routing-policy-primary-data son en mal estado. Cloud DNS solo admite destinos de copia de seguridad basados en la ubicación geográfica. El formato de este campo coincide con el de --routing-policy-data cuando --routing-policy-type = 'GEO', como asia-east1=forwarding-rule-2.

  • ROUTING_POLICY_BACKUP_DATA_TYPE: para el enrutamiento FAILOVER de políticas, 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 entre el tráfico y enviar a los destinos de copia de seguridad, incluso cuando los primarios están en buen estado. La proporción Debe estar comprendido entre 0 y 1, como 0.1. El valor predeterminado es 0.

  • --enable-health-checking: Es la marca para habilitar la verificación de estado. Cuando usa esta marca, debes proporcionar el nombre de la regla de reenvío en lugar del Dirección IP en el campo --routing-policy-data.

API

Usa el método resourceRecordSets.create.

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

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

        }
     }
}

Para políticas de WRR

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

Para FAILOVER para políticas de ubicación geográfica

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

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

Reemplaza lo siguiente:

  • PROJECT_ID: El ID del proyecto
  • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, como service-zone; el nombre de este ResourceRecordSet debe tener el nombre de DNS del administrado zone como sufijo.
  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes con el nombre DNS de esta zona como sufijo, por ejemplo, service.example.com.
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A.
  • TTL: el TTL en segundos que el agente de resolución almacena en caché este ResourceRecordSet, como 30.
  • TRICKLE_TRAFFIC: la proporción entre el tráfico y enviar a los destinos de copia de seguridad incluso cuando los primarios están en buen estado la proporción debe estar comprendido entre 0 y 1, p. ej., 0.1
  • ENABLE_FENCING: Para GEO políticas de enrutamiento, esta determina si el tráfico debe conmutarse por error entre regiones si los extremos 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, incluso si todos los endpoints de esa no están en buen estado. Si no se establece, Cloud DNS dirige las consultas a la siguiente región más cercana cuando los extremos de una región están en mal estado. El valor 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
  • WEIGHT: para las políticas WRR, una lista delimitada por punto y coma en el formato ${weight_percent}=${rrdatas}, como .8=10.128.1.1;.2=10.130.1.1; especificar la ponderación como cualquier valor no negativo decimal
  • RR_DATA: un valor arbitrario asociado con el conjunto de registros de recursos, como 198.51.100.5, también puedes ingresar varios valores, rrdata1 rrdata2 rrdata3, como 198.51.100.1 203.0.113.1...
  • LOAD_BALANCER_TYPE: Es el tipo de balanceador de cargas, como regionalL4ilb
  • IP_ADDRESS: la dirección IP a la que la regla de reenvío sirve
  • PORT_NUMBER es el número de puerto.
  • IP_PROTOCOL: Define el protocolo que se usa para la salud. verificar; las opciones válidas son tcp y udp
  • NETWORK_URL: La URL de la red a la que se redirecciona se aplica la regla
  • REGION: Es la región en la que creaste el reenvío. regla

Actualiza las políticas de enrutamiento de DNS

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

Console

  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 configuración de enrutamiento de correo.

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

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

gcloud

Ejecuta el comando gcloud dns record-sets update:

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

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

Para políticas de WRR

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

Para políticas 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

Para políticas de conmutación por error

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

Reemplaza lo siguiente:

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

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

    Para obtener una lista de los tipos de registros compatibles, consulta Selecciona tipos de registros de recursos.

  • MANAGED_ZONE: Es la zona administrada a la que ResourceRecordSet está afiliada, por ejemplo, service-zone. El nombre de este ResourceRecordSet debe tener el nombre de DNS del como sufijo de la zona administrada

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

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

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

    • En --routing-policy-type=WRR, ingresa una lista delimitada por punto y coma en el formato ${weight_percent}:${rrdatas}, como .8=203.0.113.1;.2=198.51.100.1. Especifica el peso como un valor decimal no negativo. Se calcula la proporción del tráfico enrutado al objetivo de la proporción entre el peso individual y el total de todos los pesos. Los nombres de las reglas de reenvío son valores aceptables y dan como resultado la verificación de estado.
    • En --routing-policy-type=GEO, ingresa una lista delimitada por punto y coma 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 separados por comas. Los nombres de las reglas de reenvío son valores aceptables y dan como resultado la verificación de estado.

    • En --routing-policy-type=FAILOVER, ingresa el nombre del reenvío regla de firewall que creaste con el formato ${region}=${Forwarding rule name}.

    Debes especificar el tipo y la política de enrutamiento de datos no estructurados. Si especificas una, no puedes dejar la otra marca sin propagar.

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

  • ROUTING_POLICY_PRIMARY_DATA: Es el destino principal que se usará. para las políticas de enrutamiento de FAILOVER. Este destino debe hacer referencia a una o más reglas de reenvío, como forwarding-rule-1 Siempre y cuando 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 usan para responder consultas de este nombre.

  • ROUTING_POLICY_BACKUP_DATA: Es el destino de la copia de seguridad que se usará. para las políticas de enrutamiento de FAILOVER. Estos objetivos se usan cuando las reglas de reenvío especificadas en --routing-policy-primary-data son en mal estado. Cloud DNS solo admite destinos de copia de seguridad basados en la ubicación geográfica. El formato de este campo coincide con el de --routing-policy-data cuando --routing-policy-type = 'GEO', como asia-east1=forwarding-rule-2.

  • BACKUP_DATA_TRICKLE_RATIO: la proporción entre el tráfico y sin enviar a los destinos de copia de seguridad incluso cuando los primarios están en buen estado. La proporción Debe estar comprendido entre 0 y 1, como 0.1. El valor predeterminado es 0.

  • --enable-health-checking: Habilita la verificación de estado del reenvío. que se proporcionan como datos de registro de recursos a --routing-policy-data.

API

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

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

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

        }
     }
}

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

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

Reemplaza lo siguiente:

  • PROJECT_ID: El ID del proyecto
  • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, como service-zone; el nombre de este ResourceRecordSet debe tener el nombre de DNS del administrado zone como sufijo.
  • RRSET_NAME: el nombre de DNS que coincide con las consultas entrantes con el nombre DNS de esta zona como sufijo, por ejemplo, service.example.com.
  • RRSET_TYPE: el tipo de registro de recursos de este ResourceRecordSet, como A.
  • TTL: el TTL en segundos que el agente de resolución almacena en caché este ResourceRecordSet, como 30.
  • TRICKLE_TRAFFIC: la proporción entre el tráfico y enviar a los destinos de copia de seguridad incluso cuando los primarios están en buen estado la proporción debe estar comprendido entre 0 y 1, p. ej., 0.1
  • ENABLE_FENCING: Para GEO políticas de enrutamiento, esta determina si el tráfico debe conmutarse por error entre regiones si extremos 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, incluso si todos los endpoints de esa no están en buen estado. Si no se establece, Cloud DNS dirige las consultas a la siguiente región más cercana cuando los extremos de una región están en mal estado. El valor predeterminado es false.
  • LOCATION: para las políticas GEO, la ubicación geográfica de en la que necesitas actualizar la política, como asia-east1
  • WEIGHT: para las políticas WRR, una lista delimitada por punto y coma en el formato ${weight_percent}=${rrdatas}, como .8=10.128.1.1;.2=10.130.1.1; especificar la ponderación como cualquier valor no negativo decimal
  • RR_DATA: un valor arbitrario asociado con el conjunto de registros de recursos, como 198.51.100.5, también puedes ingresar varios valores, rrdata1 rrdata2 rrdata3, como 198.51.100.1 203.0.113.1...
  • LOAD_BALANCER_TYPE: Es el tipo de balanceador de cargas, como regionalL4ilb
  • IP_ADDRESS: la dirección IP a la que la regla de reenvío sirve
  • PORT_NUMBER es el número de puerto.
  • IP_PROTOCOL: Define el protocolo que se usa para la salud. verificar; las opciones válidas son tcp y udp
  • NETWORK_URL: La URL de la red a la que se redirecciona se aplica la regla
  • REGION: Es la región en la que creaste el reenvío. regla

Borra políticas de enrutamiento de DNS

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

Console

  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 a el 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 con el nombre DNS de esta zona como sufijo, por ejemplo, service.example.com.

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

    Para obtener una lista de los tipos de registros compatibles, consulta Selecciona tipos de registros de recursos.

  • MANAGED_ZONE: la zona administrada con la que está afiliado este ResourceRecordSet, como service-zone; el nombre de este ResourceRecordSet debe tener el nombre de DNS del administrado zone como sufijo.

API

Usa el método resourceRecordSets.delete:

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

Reemplaza lo siguiente:

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

¿Qué sigue?