Gerenciar políticas de roteamento e verificações de integridade de DNS

As políticas de roteamento de DNS direcionam o tráfego com base no tipo de consulta (por exemplo, round-robin ponderado ou geolocalização). Você pode configurar essas políticas criando conjuntos de registros de recurso que contenham valores de política de roteamento específicos. Esses valores determinam como o tráfego é roteado. Por exemplo, em uma política round-robin ponderada, cada conjunto de registros de recursos tem um peso atribuído que afeta a distribuição de tráfego.

Nesta página, você verá como criar, editar e excluir políticas de roteamento de DNS e ativar a verificação de integridade usando o Cloud DNS. Antes de usar esta página, familiarize-se com a visão geral das políticas de DNS.

Para usar políticas de roteamento de DNS, crie um conjunto de registros de recurso e escolha uma das seguintes políticas de roteamento de DNS para aplicar ao conjunto de registros de recurso:

  • Política de roteamento round-robin ponderado (WRR): use o WRR para especificar ponderações diferentes por conjunto de registros de recursos para o nome do DNS. As políticas de roteamento de DNS garantem que o tráfego seja distribuído de acordo com os pesos configurados. Não é possível combinar uma política de roteamento de WRR com uma política de roteamento de geolocalização.

  • Política de roteamento de geolocalização (GEO): use a GEO para especificar geolocalizações de origem e fornecer respostas correspondentes a essas regiões geográficas. A política de roteamento de geolocalização aplica uma correspondência mais próxima para o local de origem quando a origem do tráfego não corresponde exatamente a nenhum item de política.

    A GEO mapeia a origem para DNS público e privado das seguintes maneiras:

    • Para DNS público, será usado o endereço IP de origem ou a subrede do cliente do mecanismo de extensão para DNS (EDNS) da consulta.
    • Para DNS particular, a sub-rede do cliente EDNS não é usada. O local da consulta é o local do sistema que envia os pacotes para a consulta:
      • Para consultas de uma instância de máquina virtual (VM) com uma interface de rede em uma rede VPC, o local da consulta é a região que contém a VM.
      • Para consultas recebidas por um ponto de entrada da política do servidor de entrada, o local da consulta é a região do túnel do Cloud VPN, o anexo da VLAN do Cloud Interconnect ou o dispositivo roteador que recebeu os pacotes para a consulta. A região do endereço IP do ponto de entrada não é relevante. Para mais informações, consulte Rede e região para consultas de entrada na página "Políticas de servidor DNS".

  • Política de roteamento com fronteira geográfica virtual: use a fronteira geográfica virtual para restringir o tráfego a uma geolocalização específica, mesmo que todos os endpoints dessa geolocalização não estejam íntegros. Para informações detalhadas sobre fronteiras geográficas virtuais, consulte Políticas de roteamento por fronteira geográfica virtual.

  • Política de roteamento de failover: use o failover para definir as configurações de backup ativas. Para detalhes, consulte Políticas de roteamento de failover.

As políticas de roteamento de DNS também são compatíveis com vários endereços IP para cada localização geográfica. Quando especificados para uma determinada localização geográfica, vários endereços IP são retornados de acordo com uma política de WRR de ponderação igual. Não é possível combinar uma política de roteamento baseada em área geográfica com uma política de WRR de ponderação personalizada.

Verificações de integridade

O Cloud DNS é compatível com verificações de integridade de balanceadores de carga de rede e de aplicativo internos com acesso global ativado e balanceadores de carga de aplicativo internos entre regiões.

Depois de configurar um balanceador de carga de rede de passagem interno, configure a política de roteamento apropriada no Cloud DNS usando o console do Google Cloud, a CLI gcloud ou a API, especificando o balanceador de carga de rede de passagem interno. Esta etapa envolve a configuração de vários buckets WRR ou GEO, e cada bucket pode conter vários balanceadores de carga de rede de passagem internos.

Nos balanceadores de carga de rede de passagem interna, o Cloud DNS verifica as informações de integridade nas instâncias de back-end individuais do balanceador de carga para determinar se o balanceador de carga está íntegro ou não. O Cloud DNS aplica um limite padrão de 20% e, se pelo menos 20% das instâncias de back-end estiverem íntegras, o endpoint do balanceador de carga será considerado íntegro. As políticas de roteamento de DNS marcam o endpoint como íntegro ou não íntegro com base nesse limite, roteando o tráfego corretamente.

Para balanceadores de carga de aplicativo internos e balanceadores de carga de aplicativo internos entre regiões, o Cloud DNS verifica a integridade geral do balanceador de carga de aplicativo interno e permite que o próprio balanceador de carga de aplicativo interno verifique a integridade das instâncias de back-end.

Quando o endpoint é marcado como não íntegro, podem ocorrer as seguintes condições:

  • Se houver vários endereços VIP programados com uma política, somente endereços VIP íntegros serão retornados.

  • Se todos os endereços VIP programados em um bucket de políticas não estiverem íntegros, essa linha de política falhará. O comportamento a seguir se aplica:

    • Para uma política WRR, o Cloud DNS distribui o tráfego para o próximo bucket de peso íntegro.
    • Para uma política GEO que não tem a fronteira ativada, o tráfego alterna para a próxima região geográfica mais próxima.
    • Para uma política especificada com o isolamento ativado, os endereços VIP no bucket geográfico mais próximo são retornados como estão.
    • Para uma política de failover, o Cloud DNS alterna o tráfego para o bucket de failover.
    • Se todos os buckets de política não estiverem íntegros, o Cloud DNS vai se comportar como se todos os endpoints estivessem íntegros.

Antes de começar

Para este procedimento, é necessário que você tenha concluído o seguinte:

  1. Criou uma zona gerenciada e concluiu os pré-requisitos para criar uma zona.
  2. Configurado um dos seguintes balanceadores de carga internos:
  3. Crie regras de encaminhamento para o balanceador de carga interno.
  4. Configure a verificação de integridade do balanceador de carga interno.

Criar políticas de roteamento de DNS

Para criar um conjunto de registros de recursos e aplicar uma política de roteamento a ele, siga estas etapas.

Console

Inicie a configuração

  1. No Console do Google Cloud, acesse a página Zonas do Cloud DNS.

    Acessar zonas do Cloud DNS

  2. Clique no nome da zona gerenciada a que você quer adicionar o registro.

  3. Na página Detalhes da zona, clique em Adicionar com a política de roteamento.

Dados base

  1. Em Criar conjunto de registros com política de roteamento, no Nome do DNS insira o subdomínio da zona de DNS, por exemplo, mail. O ponto é adicionado automaticamente no final.

  2. Selecione o Tipo de registro de recurso, por exemplo, A.

  3. No campo TTL, insira um valor numérico para o time to live (TTL) do registro de recursos, que é o tempo que ele pode ser armazenado em cache. Esse valor precisa ser um número inteiro positivo.

  4. No menu Unidade TTL, selecione a unidade de tempo. Por exemplo, 30 minutes.

  5. Clique em Próxima.

Tipo de política de roteamento

  1. Na lista Política de roteamento, selecione Round-robin ponderado, Geolocalização ou Failover.
  2. Clique em Próxima.

Dados da política de roteamento

  1. Se você selecionou Round-robin ponderado, na seção Dados de roteamento de políticas de round-robin ponderado, faça o seguinte:

    1. No campo Peso, insira o peso correspondente a essa subseção dos dados do registro de recurso (RR). Essa ponderação precisa ser um número não negativo de 0,0 a 1000,0. A proporção de tráfego roteado para o destino é calculada a partir da proporção da ponderação individual sobre o total em todas as ponderações.

    2. Na seção Adicionar destino verificado quanto à integridade, faça o seguinte:

      1. Na lista Projeto, selecione o projeto em que a regra de encaminhamento existe.
      2. Na lista Tipo, selecione Balanceador de carga de rede de passagem interna, Balanceador de carga de aplicativo interno ou Balanceador de carga de aplicativo interno entre regiões.

      3. Na lista Regra de encaminhamento, selecione uma regra.

        A regra de encaminhamento especifica um endereço IP interno, uma porta e um serviço de back-end regional ou um proxy HTTP(S). Para que o Cloud DNS funcione com verificações de integridade, é preciso ativar o acesso global para o balanceador de carga interno.

    3. Para permitir endereços IPv4 sem verificação de integridade, selecione Permitir endereços IPv4 sem verificação de integridade.

    4. No campo Endereço IPv4, digite um endereço IPv4.

  2. Se você selecionou Geolocalização, faça o seguinte:

    1. Em Cercas geográficas, selecione Desativada ou Ativada. Ativar a fronteira geográfica virtual restringe o tráfego a uma geolocalização específica, mesmo que todos os endpoints dela estejam não íntegros.
    2. No menu Região de origem, selecione uma região válida para o Google Cloud, como asia-east1.

    3. Na seção Adicionar destino verificado quanto à integridade, faça o seguinte:

      1. Na lista Projeto, selecione o projeto em que a regra de encaminhamento existe.
      2. Na lista Tipo, selecione Balanceador de carga de rede de passagem interna, Balanceador de carga de aplicativo interno ou Balanceador de carga de aplicativo interno entre regiões.

      3. Na lista Regra de encaminhamento, selecione uma regra.

        A regra de encaminhamento especifica um endereço IP interno, uma porta e um serviço de back-end regional ou um proxy HTTP(S). Para que o Cloud DNS funcione com verificações de integridade, é preciso ativar o acesso global para o balanceador de carga interno.

    4. Para permitir endereços IPv4 sem verificação de integridade, selecione Permitir endereços IPv4 sem verificação de integridade.

    5. No campo Endereço IPv4, digite um endereço IPv4.

  3. Se você selecionou Failover, faça o seguinte:

    1. No campo Trickle traffic (%), insira a porcentagem do tráfego enviado aos destinos de failover, independentemente do status da verificação de integridade dos destinos principais.

    2. Na seção Destinos principais, faça o seguinte:

      1. Na lista Projeto, selecione o projeto em que a regra de encaminhamento existe.
      2. Na lista Tipo, selecione Balanceador de carga de rede de passagem interna, Balanceador de carga de aplicativo interno ou Balanceador de carga de aplicativo interno entre regiões.

      3. Na lista Regra de encaminhamento, selecione uma regra.

        A regra de encaminhamento especifica um endereço IP interno, uma porta e um serviço de back-end regional ou um proxy HTTP(S). Para que o Cloud DNS funcione com verificações de integridade, é preciso ativar o acesso global para o balanceador de carga interno.

    3. Na seção Política de geolocalização de backup, faça o seguinte:

      1. Em Cercas geográficas, selecione Desativada ou Ativada. Ativar a fronteira geográfica virtual restringe o tráfego a uma geolocalização específica, mesmo que todos os endpoints dela estejam não íntegros.
      2. No menu Região de origem, selecione uma região válida para o Google Cloud, como asia-east1.

      3. Na seção Adicionar destino verificado quanto à integridade, faça o seguinte:

        1. Na lista Projeto, selecione o projeto em que a regra de encaminhamento existe.
        2. Na lista Tipo, selecione Balanceador de carga de rede de passagem interna, Balanceador de carga de aplicativo interno ou Balanceador de carga de aplicativo interno entre regiões.
        3. Na lista Regra de encaminhamento, selecione uma regra.

        Quando nenhum dos endereços IP primários estiver íntegro, o tráfego será processado automaticamente de acordo com a política de geolocalização de backup.

    4. Para permitir endereços IPv4 sem verificação de integridade, selecione Permitir endereços IPv4 sem verificação de integridade.

    5. No campo Endereço IPv4, digite um endereço IPv4.

  4. Clique em Próxima.

Revisar e criar

  1. Clique em Revisar.
  2. Revise seu conjunto de registros do Cloud DNS com a configuração da política de roteamento.
  3. Opcional: clique em Linha de comentário equivalente para ver o comando da CLI gcloud e criar esse conjunto de registros com política de roteamento.
  4. Clique em Criar.

gcloud

Um ResourceRecordSet pode conter routingPolicy ou rrdatas, mas não ambos. É possível alterar entre rrdatas ou routingPolicy ao atualizar ResourceRecordSets. Por exemplo, se você quiser atualizar um ResourceRecordSet que contém rrdatas, você pode excluir os rrdatas e adicionar umaroutingPolicy ao mesmo ResourceRecordSet.

Para criar um ResourceRecordSet e aplicar uma política de roteamento a ele, siga estas etapas.

Execute o gcloud dns record-sets create comando.

Para políticas geográficas

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 com fronteiras geográficas virtuais

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 failover

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

Substitua:

  • RRSET_NAME: o nome de DNS que corresponde às consultas recebidas com o nome DNS desta zona como seu sufixo, por exemplo, service.example.com
  • TTL: o TTL em segundos que o resolvedor armazena essa ResourceRecordSet em cache, como 30

  • RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A.

    Para ver uma lista de tipos de registro compatíveis, consulte Selecionar tipos de registro de recurso.

  • MANAGED_ZONE: a zona gerenciada a que ResourceRecordSet está afiliado, como service-zone. O nome desse ResourceRecordSet precisa ter o nome DNS da zona gerenciada como sufixo

  • ROUTING_POLICY_TYPE: o tipo de política de roteamento

    Digite WRR para o round-robin ponderado, GEO para localização geográfica ou FAILOVER para políticas de failover. Não é possível modificar esse campo depois que uma política tem um tipo escolhido. Você só pode excluir a política e adicionar uma nova com o tipo diferente.

  • ROUTING_POLICY_DATA: os dados da política de roteamento

    • Para --routing-policy-type=WRR, insira uma lista delimitada por ponto e vírgula do formato ${weight_percent}:${rrdatas}, como .8=203.0.113.1;.2=198.51.100.1. Especifique a ponderação como qualquer decimal não negativo. A proporção de tráfego roteado para o destino é calculada a partir da proporção da ponderação individual sobre o total em todas as ponderações. Os nomes das regras de encaminhamento são valores aceitáveis e resultam em verificação de integridade.
    • Para --routing-policy-type=GEO, insira uma lista delimitada por ponto e vírgula do formato ${region}=${IP_address}, como asia-east1=198.51.100.1;us-central1=203.0.113.1. É possível especificar vários endereços IP para uma única região adicionando endereços IP separados por vírgula. Os nomes das regras de encaminhamento são valores aceitáveis e resultam em verificação de integridade.

    • Em --routing-policy-type=FAILOVER, insira o nome da regra de encaminhamento que você criou no formato ${region}=${Forwarding rule name}.

    É necessário especificar o tipo de política de roteamento e os dados da política de roteamento. Se você especificar uma, a outra sinalização terá que ser preenchida.

  • --enable-geo-fencing: para políticas de roteamento de GEO, isso determina se o tráfego deve fazer failover entre as regiões se todos os endpoints de uma região não estiverem íntegros. Quando definido, o Cloud DNS sempre direciona as consultas para a região mais próxima, mesmo que todos os endpoints dessa região não estejam íntegros. Use --no-enable-geo-fencing para desativar a fronteira geográfica virtual. Quando não definido, o Cloud DNS direciona as consultas para a próxima região mais próxima quando todos os endpoints de uma região não estiverem íntegros. O padrão é false.

  • ROUTING_POLICY_PRIMARY_DATA: o destino principal a ser usado para políticas de roteamento FAILOVER. Esse destino precisa ser uma referência a uma ou mais regras de encaminhamento, como forwarding-rule-1. Contanto que pelo menos uma dessas regras de encaminhamento esteja íntegra, os endereços IP de todas as regras de encaminhamento íntegras serão usados para responder às consultas desse nome.

  • ROUTING_POLICY_BACKUP_DATA: o destino de backup a ser usado para as políticas de roteamento de FAILOVER. Esses destinos são usados quando todas as regras de encaminhamento especificadas em --routing-policy-primary-data não estão íntegras. O Cloud DNS só é compatível com destinos de backup baseados em localização geográfica. O formato desse campo corresponde ao de --routing-policy-data quando --routing-policy-type = 'GEO', como asia-east1=forwarding-rule-2.

  • ROUTING_POLICY_BACKUP_DATA_TYPE: para as políticas de roteamento FAILOVER, o tipo de política de roteamento usado pelos dados de backup. Elas devem ser GEO.

  • BACKUP_DATA_TRICKLE_RATIO: a proporção de tráfego a ser enviada aos destinos de backup, mesmo quando as primárias estão íntegras. A proporção precisa estar entre 0 e 1, como 0.1. O padrão é 0.

  • --enable-health-checking: a sinalização para ativar a verificação de integridade. Ao usar essa sinalização, é necessário fornecer o nome da regra de encaminhamento em vez do endereço IP no campo --routing-policy-data.

API

Use o método resourceRecordSets.create.

Para políticas geográficas

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 das políticas geográficas

Na opção de failover, o Cloud DNS só é compatível com 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"
             ]
           }
         ]
       }
     },
   }
}

Substitua:

  • PROJECT_ID: o ID do projeto
  • MANAGED_ZONE: a zona gerenciada à qual este ResourceRecordSet está afiliado, como service-zone; o nome deste ResourceRecordSet precisa ter o nome DNS da zona gerenciada como sufixo
  • RRSET_NAME: o nome de DNS que corresponde às consultas recebidas com o nome DNS desta zona como seu sufixo, por exemplo, service.example.com
  • RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A.
  • TTL: o TTL em segundos que o resolvedor armazena essa ResourceRecordSet em cache, como 30
  • TRICKLE_TRAFFIC: a proporção de tráfego a ser enviada aos destinos de backup, mesmo quando as primárias estiverem íntegras; a proporção precisa estar entre 0 e 1, como 0.1.
  • ENABLE_FENCING: para políticas de roteamento de GEO, isso determina se o tráfego deve fazer failover entre regiões se todos os endpoints de uma região não estiverem íntegros. Quando definido, o Cloud DNS sempre direciona as consultas para a região mais próxima, mesmo que todos os endpoints dessa região não estejam íntegros. Quando não definido, o Cloud DNS direciona as consultas para a região mais próxima quando todos os endpoints de uma região não estiverem íntegros. O padrão é false.
  • LOCATION: para políticas de GEO, a geolocalização para que você precisa criar a política, como asia-east1
  • WEIGHT: para políticas WRR, uma lista delimitada por ponto e vírgula no formato ${weight_percent}=${rrdatas}, como .8=10.128.1.1;.2=10.130.1.1 especifique o peso como qualquer decimal não negativo
  • RR_DATA: um valor arbitrário associado ao conjunto de registros de recursos, como 198.51.100.5; também é possível inserir vários valores, rrdata1 rrdata2 rrdata3, como 198.51.100.1 203.0.113.1...
  • LOAD_BALANCER_TYPE: o tipo de balanceador de carga, como regionalL4ilb
  • IP_ADDRESS: o endereço IP que a regra de encaminhamento veicula.
  • PORT_NUMBER: o número da porta
  • IP_PROTOCOL: define o protocolo usado para a verificação de integridade. as opções válidas são tcp e udp
  • NETWORK_URL: o URL da rede a que esta regra de encaminhamento se aplica.
  • REGION: a região em que você criou a regra de encaminhamento

Atualizar políticas de roteamento de DNS

Para atualizar a política de roteamento de um conjunto de registros de recurso, siga estas etapas.

Console

  1. No console do Google Cloud, acesse a página Zonas do Cloud DNS.

    Acessar zonas do Cloud DNS

  2. Clique na zona em que você quer atualizar a política de roteamento do conjunto de registros de recurso.

  3. Na página Detalhes da zona, ao lado do conjunto de registros de recursos que você quer atualizar, clique em Editar.

  4. Depois de fazer as atualizações necessárias, clique em Salvar.

gcloud

Execute o comando gcloud dns record-sets update:

Para políticas geográficas

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 com fronteiras geográficas virtuais

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 failover

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

Substitua:

  • RRSET_NAME: o nome de DNS que corresponde às consultas recebidas com o nome DNS desta zona como seu sufixo, por exemplo, service.example.com
  • TTL: o TTL em segundos que o resolvedor armazena essa ResourceRecordSet em cache, como 30

  • RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A.

    Para ver uma lista de tipos de registro compatíveis, consulte Selecionar tipos de registro de recurso.

  • MANAGED_ZONE: a zona gerenciada a que ResourceRecordSet está afiliado, como service-zone. O nome desse ResourceRecordSet precisa ter o nome DNS da zona gerenciada como sufixo

  • ROUTING_POLICY_TYPE: o tipo de política de roteamento

    Digite WRR para o round-robin ponderado, GEO para localização geográfica ou FAILOVER para políticas de failover. Não é possível modificar esse campo depois que uma política tem um tipo escolhido. Você só pode excluir a política e adicionar uma nova com o tipo diferente.

  • ROUTING_POLICY_DATA: os dados da política de roteamento

    • Para --routing-policy-type=WRR, insira uma lista delimitada por ponto e vírgula do formato ${weight_percent}:${rrdatas}, como .8=203.0.113.1;.2=198.51.100.1. Especifique a ponderação como qualquer decimal não negativo. A proporção de tráfego roteado para o destino é calculada a partir da proporção da ponderação individual sobre o total em todas as ponderações. Os nomes das regras de encaminhamento são valores aceitáveis e resultam em verificação de integridade.
    • Para --routing-policy-type=GEO, insira uma lista delimitada por ponto e vírgula do formato ${region}=${IP_address}, como asia-east1=198.51.100.1;us-central1=203.0.113.1. É possível especificar vários endereços IP para uma única região adicionando endereços IP separados por vírgula. Os nomes das regras de encaminhamento são valores aceitáveis e resultam em verificação de integridade.

    • Em --routing-policy-type=FAILOVER, insira o nome da regra de encaminhamento que você criou no formato ${region}=${Forwarding rule name}.

    É necessário especificar o tipo de política de roteamento e os dados da política de roteamento. Se você especificar uma, a outra sinalização terá que ser preenchida.

  • --enable-geo-fencing: para políticas de roteamento de GEO, isso determina se o tráfego deve fazer failover entre as regiões se todos os endpoints de uma região não estiverem íntegros. Quando definido, o Cloud DNS sempre direciona as consultas para a região mais próxima, mesmo que todos os endpoints dessa região não estejam íntegros. Use --no-enable-geo-fencing para desativar a fronteira geográfica virtual. Quando não definido, o Cloud DNS direciona as consultas para a próxima região mais próxima quando todos os endpoints de uma região não estiverem íntegros. O padrão é false.

  • ROUTING_POLICY_PRIMARY_DATA: o destino principal a ser usado para políticas de roteamento FAILOVER. Esse destino precisa ser uma referência a uma ou mais regras de encaminhamento, como forwarding-rule-1. Contanto que pelo menos uma dessas regras de encaminhamento esteja íntegra, os endereços IP de todas as regras de encaminhamento íntegras serão usados para responder às consultas desse nome.

  • ROUTING_POLICY_BACKUP_DATA: o destino de backup a ser usado para as políticas de roteamento de FAILOVER. Esses destinos são usados quando todas as regras de encaminhamento especificadas em --routing-policy-primary-data não estão íntegras. O Cloud DNS só é compatível com destinos de backup baseados em localização geográfica. O formato desse campo corresponde ao de --routing-policy-data quando --routing-policy-type = 'GEO', como asia-east1=forwarding-rule-2.

  • BACKUP_DATA_TRICKLE_RATIO: a proporção de tráfego a ser enviada aos destinos de backup, mesmo quando as primárias estão íntegras. A proporção precisa estar entre 0 e 1, como 0.1. O padrão é 0.

  • --enable-health-checking: ativa a verificação de integridade das regras de encaminhamento fornecidas como rrdata para --routing-policy-data.

API

Use o método resourceRecordSets.patch. Especifique apenas rrset.rrdatas ou rrset.routingPolicy. Se você especificar routingPolicy, será necessário especificar o novo campo routingPolicy inteiro.

Para políticas GEO, use o seguinte 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 políticas WRR, use o seguinte 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"]
                     }
               ],
            }
      }
}

Substitua:

  • PROJECT_ID: o ID do projeto
  • MANAGED_ZONE: a zona gerenciada à qual este ResourceRecordSet está afiliado, como service-zone; o nome deste ResourceRecordSet precisa ter o nome DNS da zona gerenciada como sufixo
  • RRSET_NAME: o nome de DNS que corresponde às consultas recebidas com o nome DNS desta zona como seu sufixo, por exemplo, service.example.com
  • RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A.
  • TTL: o TTL em segundos que o resolvedor armazena essa ResourceRecordSet em cache, como 30
  • TRICKLE_TRAFFIC: a proporção de tráfego a ser enviada aos destinos de backup, mesmo quando as primárias estiverem íntegras; a proporção precisa estar entre 0 e 1, como 0.1.
  • ENABLE_FENCING: para políticas de roteamento de GEO, isso determina se o tráfego deve fazer failover entre regiões se todos os endpoints de uma região não estiverem íntegros. Quando definido, o Cloud DNS sempre direciona as consultas para a região mais próxima, mesmo que todos os endpoints dessa região não estejam íntegros. Quando não definido, o Cloud DNS direciona as consultas para a região mais próxima quando todos os endpoints de uma região não estiverem íntegros. O padrão é false.
  • LOCATION: para políticas de GEO, a geolocalização para que você precisa criar a política, como asia-east1
  • WEIGHT: para políticas WRR, uma lista delimitada por ponto e vírgula no formato ${weight_percent}=${rrdatas}, como .8=10.128.1.1;.2=10.130.1.1 especifique o peso como qualquer decimal não negativo
  • RR_DATA: um valor arbitrário associado ao conjunto de registros de recursos, como 198.51.100.5; também é possível inserir vários valores, rrdata1 rrdata2 rrdata3, como 198.51.100.1 203.0.113.1...
  • LOAD_BALANCER_TYPE: o tipo de balanceador de carga, como regionalL4ilb
  • IP_ADDRESS: o endereço IP que a regra de encaminhamento veicula.
  • PORT_NUMBER: o número da porta
  • IP_PROTOCOL: define o protocolo usado para a verificação de integridade. as opções válidas são tcp e udp
  • NETWORK_URL: o URL da rede a que esta regra de encaminhamento se aplica.
  • REGION: a região em que você criou a regra de encaminhamento

Excluir políticas de roteamento de DNS

Para excluir uma política de roteamento, você precisa excluir o conjunto de registros de recurso que contém a política de roteamento. Para fazer isso, siga estas etapas.

Console

  1. No Console do Google Cloud, acesse a página Zonas do Cloud DNS.

    Acessar zonas do Cloud DNS

  2. Clique na zona em que você quer excluir o conjunto de registros de recursos.

  3. Na página Detalhes da zona, marque a caixa de seleção ao lado do nome do conjunto de registros de recursos que você quer excluir.

  4. Clique em Excluir conjuntos de registros.

gcloud

Execute o comando gcloud dns record-sets delete:

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

Substitua:

  • RRSET_NAME: o nome de DNS que corresponde às consultas recebidas com o nome DNS desta zona como seu sufixo, por exemplo, service.example.com

  • RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A.

    Para ver uma lista de tipos de registros compatíveis, consulte Como selecionar tipos de registro de recurso.

  • MANAGED_ZONE: a zona gerenciada à qual este ResourceRecordSet está afiliado, como service-zone; o nome deste ResourceRecordSet precisa ter o nome DNS da zona gerenciada como sufixo

API

Use o método resourceRecordSets.delete.

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

Substitua:

  • PROJECT_ID: o ID do projeto
  • MANAGED_ZONE: a zona gerenciada à qual este ResourceRecordSet está afiliado, como my-zone-name; o nome deste ResourceRecordSet precisa ter o nome DNS da zona gerenciada como sufixo
  • RRSET_NAME: o nome de DNS que corresponde às consultas recebidas com o nome DNS desta zona como seu sufixo, por exemplo, test.example.com
  • RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A.

A seguir