Esta página foi traduzida pela API Cloud Translation.

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

Esta página descreve como configurar políticas de roteamento de DNS e ativar as verificações de integridade usando o Cloud DNS. Antes de usar esta página, familiarize-se com as políticas de roteamento de DNS e as verificações de integridade.

Permissões exigidas para a tarefa

Para executar esta tarefa, são necessárias as seguintes permissões ou papéis do IAM.

Permissões

dns.networks.useHealthSignals para criar uma política com verificações de integridade para balanceadores de carga de rede de passagem internos
dns.changes.create para criar um conjunto de registros de recurso
dns.managedZones.list para listar zonas gerenciadas

Papéis

roles/dns.admin
roles/dns.peer

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

Política de roteamento de round-robin ponderado (WRR)

Política de roteamento de geolocalização
- Política de roteamento de geolocalização com uma fronteira geográfica virtual

Política 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.

Apenas um tipo de política de roteamento pode ser aplicado a um conjunto de registros de recurso por vez. Não é possível combinar políticas de roteamento, exceto ao configurar uma política de roteamento de failover, em que é possível definir uma política de roteamento de geolocalização como backup. O acesso global precisa ser ativado para balanceadores de carga regionais.

Criar políticas de roteamento de DNS para zonas particulares

Antes de criar políticas de roteamento de DNS para zonas particulares, siga as etapas abaixo.

Criar uma zona particular.
Configurado um dos seguintes balanceadores de carga internos:
Crie regras de encaminhamento para o balanceador de carga interno.
Configure a verificação de integridade do balanceador de carga interno.

Para criar políticas de roteamento de DNS para zonas particulares, siga estas etapas.

Console

Inicie a configuração

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

Acessar zonas do Cloud DNS
Clique no nome da zona gerenciada a que você quer adicionar o registro.
Na página Detalhes da zona, clique em Adicionar com a política de roteamento.

Dados base

Opcional: na página Criar conjunto de registros com política de roteamento, em Nome do DNS, insira um subdomínio do nome do DNS, por exemplo, mail. O ponto é adicionado automaticamente.

Importante: adicionar o símbolo de adição (@) neste campo causa falha no registro.
Em Tipo de registro de recurso, selecione uma opção.
Em TTL, insira um valor numérico para o time to live (TTL) do registro de recurso, que é o tempo que ele pode ser armazenado em cache. O valor precisa ser um número inteiro positivo.
Opcional: em Unidade TTL, selecione a unidade de tempo. Por exemplo, minutes. O padrão é definido como minutes.
Clique em Próxima.

Tipo de política de roteamento

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

Dados da política de roteamento

WRR

Em Peso, insira o peso correspondente a essa subseção dos dados do registro de recurso (RR).

O peso precisa ser um número não negativo de 0,0 a 1.000,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. Por exemplo, se o destino A tiver uma ponderação de 25 e o destino B tiver uma ponderação de 75, com um peso total de 100, o Cloud DNS encaminha 25/100 = 0,25 (25 por cento) do tráfego total para o destino A e 75/100= 0,75 (75 por cento) para o destino B.
Na seção Destinos de verificação de integridade IPv4, faça o seguinte:
1. Em Projeto, selecione o projeto em que a regra de encaminhamento existe.
2. Em Regra de encaminhamento, selecione uma regra.
  
  A regra de encaminhamento especifica um endereço IP interno, uma porta e uma das seguintes metas:
  - Um serviço de back-end regional
  - Um proxy HTTPS de destino global ou regional
  - Um proxy TCP de destino regional
Clique em Concluído.
Opcional: para adicionar outro destino verificado de integridade, clique em Adicionar destino.
Opcional: para permitir endereços IPv4 sem verificação de integridade, faça o seguinte:
1. Selecione Permitir endereços IPv4 sem verificação de integridade.
2. Em Endereço IPv4, insira um endereço IPv4.
Opcional: para adicionar outro conjunto de dados de roteamento da política de WRR, clique em Adicionar dados de roteamento.
Clique em Próxima.

Geolocalização

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.
Em Região de origem, selecione uma região de origem válida do Google Cloud.
Na seção Destinos de verificação de integridade IPv4, faça o seguinte:
1. Em Projeto, selecione o projeto em que a regra de encaminhamento existe.
2. Em Regra de encaminhamento, selecione uma regra.
  
  A regra de encaminhamento especifica um endereço IP interno, uma porta e uma das seguintes metas:
  - Um serviço de back-end regional
  - Um proxy HTTPS de destino global ou regional
  - Um proxy TCP de destino regional
Clique em Concluído.
Opcional: para adicionar outro destino verificado de integridade, clique em Adicionar destino.
Opcional: para permitir endereços IPv4 sem verificação de integridade, faça o seguinte:
1. Selecione Permitir endereços IPv4 sem verificação de integridade.
2. Em Endereço IPv4, insira um endereço IPv4.
Opcional: para adicionar um conjunto de dados de roteamento de outra política de geolocalização, clique em Adicionar dados de roteamento.
Clique em Próxima.

Failover

Na seção Destinos principais verificados quanto à integridade, faça o seguinte:
1. Em Projeto, selecione o projeto em que a regra de encaminhamento existe.
2. Em Regra de encaminhamento, selecione uma regra.
  
  A regra de encaminhamento especifica um endereço IP interno, uma porta e uma das seguintes metas:
  - Um serviço de back-end regional
  - Um proxy HTTPS de destino global ou regional
  - Um proxy TCP de destino regional
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. Em Região de origem, selecione uma região de origem válida do Google Cloud.
3. Na seção Destinos de verificação de integridade IPv4, faça o seguinte:
  1. Em Projeto, selecione o projeto em que a regra de encaminhamento existe.
  2. Em Regra de encaminhamento, selecione uma regra.
    
    A regra de encaminhamento especifica uma das seguintes opções:
    - Um endereço IP interno, uma porta e um serviço de back-end regional
    - Um proxy HTTP(S)
    - Um proxy TCP
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.
Clique em Concluído.
Opcional: para adicionar outro destino verificado de integridade, clique em Adicionar destino.
Opcional: para permitir endereços IPv4 sem verificação de integridade, faça o seguinte:
1. Selecione Permitir endereços IPv4 sem verificação de integridade.
2. Em Endereço IPv4, insira um endereço IPv4.
Opcional: para adicionar outro conjunto de dados de roteamento da política de geolocalização de backup, clique em Adicionar dados de roteamento.
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.
Clique em Próxima.

Revisar e criar

Clique em Revisar.
Revise seu conjunto de registros do Cloud DNS com a configuração da política de roteamento.
Clique em Criar.

gcloud

Para um conjunto de registros de recurso, você define uma política de roteamento (routingPolicy) ou dados DNS (rrdatas), não ambos. Para alternar entre uma política de roteamento e dados DNS, atualize o conjunto de registros de recurso. Por exemplo, para mudar um conjunto de registros de recurso que contém dados de DNS (rrdatas) para conter uma política de roteamento (routingPolicy), exclua rrdatas e adicione routingPolicy ao mesmo conjunto de registros de recurso.

Para criar políticas de roteamento de DNS para zonas particulares, siga estas etapas.

Execute o gcloud dns record-sets createcomando:

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

Substitua:

RRSET_NAME: o nome de DNS que corresponde às consultas recebidas com o nome DNS desta zona como sufixo, por exemplo, service.example.com.
TTL: o TTL, em segundos, em que o resolvedor armazena em cache ResourceRecordSet, como 30.
RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A. Para uma lista de tipos de registro com suporte, consulte Tipos de registro com suporte para políticas de roteamento de DNS.
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.
ROUTING_POLICY_DATA: insira uma lista delimitada por ponto e vírgula no formato ${weight_percent}:${rrdatas}, como .8=203.0.113.1;.2=198.51.100.1. Especifique a ponderação como um 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.
--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.

Geolocalização

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

Substitua:

RRSET_NAME: o nome de DNS que corresponde às consultas recebidas com o nome DNS desta zona como sufixo, por exemplo, service.example.com.
TTL: o TTL, em segundos, em que o resolvedor armazena em cache ResourceRecordSet, como 30.
RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A. Para uma lista de tipos de registro com suporte, consulte Tipos de registro com suporte para políticas de roteamento de DNS.
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.
ROUTING_POLICY_DATA: insira uma lista delimitada por ponto e vírgula no 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.
--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.

Geolocalização com fronteira geográfica virtual

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

Substitua:

RRSET_NAME: o nome de DNS que corresponde às consultas recebidas com o nome DNS desta zona como sufixo, por exemplo, service.example.com.
TTL: o TTL, em segundos, em que o resolvedor armazena em cache ResourceRecordSet, como 30.
RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A. Para uma lista de tipos de registro com suporte, consulte Tipos de registro com suporte para políticas de roteamento de DNS.
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.
ROUTING_POLICY_DATA: insira uma lista delimitada por ponto e vírgula no 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.
--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.
--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.

Failover

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

Substitua:

RRSET_NAME: o nome de DNS que corresponde às consultas recebidas com o nome DNS desta zona como sufixo, por exemplo, service.example.com.
TTL: o TTL, em segundos, em que o resolvedor armazena em cache ResourceRecordSet, como 30.
RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A. Para uma lista de tipos de registro com suporte, consulte Tipos de registro com suporte para políticas de roteamento de DNS.
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.
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_TYPE: para as políticas de roteamento FAILOVER, o tipo de política de roteamento usado pelos dados de backup. Elas devem ser GEO.
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 é definido como 0.
--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.
--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.

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

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, em que o resolvedor armazena essa ResourceRecordSet em cache, como 30
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 Observação: é preciso especificar o peso como um número 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.
LOAD_BALANCER_TYPE: o tipo de balanceador de carga, como regionalL4ilb, globalL7ilb ou regionalL7ilb. Essa configuração é opcional.
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

Geolocalização

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

      }
  }
}

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, em que o resolvedor armazena essa ResourceRecordSet em cache, como 30
LOCATION: para políticas de GEO, a geolocalização para que você precisa criar a política, como asia-east1
LOAD_BALANCER_TYPE: o tipo de balanceador de carga, como regionalL4ilb, globalL7ilb ou regionalL7ilb. Essa configuração é opcional.
IP_ADDRESS: o endereço IP que a regra de encaminhamento veicula.
PORT_NUMBER: o número da porta do balanceador de carga interno
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

Failover

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_ID"
          "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, em 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.
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.
PORT_NUMBER: o número da porta do balanceador de carga interno
REGION: a região em que você criou a regra de encaminhamento
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
Observação:é preciso especificar o peso como um número 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.
RRDATA: 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...

Criar políticas de roteamento de DNS para zonas públicas (pré-lançamento)

Para criar políticas de roteamento de DNS para zonas públicas, siga estas etapas.

Console

Inicie a configuração

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

Acessar zonas do Cloud DNS
Clique no nome da zona gerenciada a que você quer adicionar o registro.
Na página Detalhes da zona, clique em Adicionar com a política de roteamento.

Dados base

Opcional: na página Criar conjunto de registros com política de roteamento, em Nome do DNS, insira um subdomínio do nome do DNS preenchido previamente, por exemplo, mail. O ponto é adicionado automaticamente.

Importante: adicionar o símbolo de adição (@) neste campo causa falha no registro.
Em Tipo de registro de recurso, selecione uma opção.
Em TTL, insira um valor numérico para o time to live (TTL) do registro de recurso, que é o tempo que ele pode ser armazenado em cache. Esse valor precisa ser um número inteiro positivo.
Opcional: em Unidade TTL, selecione a unidade de tempo. Por exemplo, minutes. O padrão é definido como minutes.
Clique em Próxima.

Tipo de política de roteamento

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

Dados da política de roteamento

WRR

Em Peso, insira o peso correspondente a essa subseção dos dados do registro de recurso (RR).

O peso precisa ser um número não negativo de 0,0 a 1.000,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. Por exemplo, se o destino A tiver uma ponderação de 25 e o destino B tiver uma ponderação de 75, com um peso total de 100, o Cloud DNS encaminha 25/100 = 0,25 (25 por cento) do tráfego total para o destino A e 75/100= 0,75 (75 por cento) para o destino B.
Na seção Endereços IP externos, faça o seguinte:
1. Em Endereço IP , insira um endereço IP externo.
2. Opcional: para selecionar um endereço IP externo de um recurso do Google Cloud no projeto atual, clique em Selecionar.
3. Para ativar a verificação de integridade, selecione Verificação de integridade 1.
4. Opcional: para adicionar outro endereço IP externo, clique em Adicionar endereço IP.
5. Clique em Concluído.
Se você tiver ativado a verificação de integridade na etapa anterior, na lista Verificação de integridade, selecione uma verificação de integridade ou crie uma nova, seguindo estas etapas.
1. Clique em Criar uma nova verificação de integridade.
2. Em Nome, digite um nome para a verificação de integridade.
3. Opcional: em Descrição, insira uma descrição para a verificação de integridade.
4. Em Regiões de origem, selecione três regiões do Google Cloud em que você quer enviar verificações de integridade.
5. Opcional: na lista Protocolo, selecione um protocolo.
6. Em Port, digite um número de porta.
  
  O protocolo e o número da porta determinam como o Cloud DNS envia as sondagens de verificação de integridade.
7. Opcional: para configurar a verificação de integridade com base em conteúdo, em Resposta, forneça uma string de resposta esperada, cada uma com até 1.024 caracteres ASCII (byte único) de comprimento.
8. Opcional: para ativar os registros de verificação de integridade, em Registros, selecione Ativado.
9. Em Intervalo de verificação, insira o intervalo de tempo em segundos entre as sondagens de verificação de integridade. O intervalo de verificação é o tempo desde o início de uma sondagem emitida por uma sonda até o início da próxima sondagem emitida pela mesma sonda.
10. Em Tempo limite, digite o tempo em segundos que você quer que o Google Cloud aguarde uma resposta a uma sondagem.
11. Em Limite íntegro, insira o número de resultados de sondagem bem-sucedidos consecutivos para que um back-end seja considerado íntegro.
12. Em Limite não íntegro, insira o número de resultados de sondagem falhados consecutivos para que um back-end seja considerado não íntegro.
13. Clique em Criar.
Clique em Próximo.

Geolocalização

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.
Em Região de origem, selecione uma região de origem válida do Google Cloud.
Na seção Endereços IP externos, faça o seguinte:
1. Em Endereço IP , insira um endereço IP externo.
2. Opcional: para selecionar um endereço IP externo de um recurso do Google Cloud no projeto atual, clique em Selecionar.
3. Para ativar a verificação de integridade, selecione Verificação de integridade 1.
4. Opcional: para adicionar outro endereço IP externo, clique em Adicionar endereço IP.
5. Clique em Concluído.
Se você tiver ativado a verificação de integridade na etapa anterior, na lista Verificação de integridade, selecione uma verificação de integridade ou crie uma nova, seguindo estas etapas.
1. Clique em Criar uma nova verificação de integridade.
2. Em Nome, digite um nome para a verificação de integridade.
3. Opcional: em Descrição, insira uma descrição para a verificação de integridade.
4. Em Regiões de origem, selecione três regiões do Google Cloud em que você quer enviar verificações de integridade.
5. Opcional: na lista Protocolo, selecione um protocolo.
6. Em Port, digite um número de porta.
  
  O protocolo e o número da porta determinam como o Cloud DNS envia as sondagens de verificação de integridade.
7. Opcional: para configurar a verificação de integridade com base em conteúdo, em Resposta, forneça uma string de resposta esperada, cada uma com até 1.024 caracteres ASCII (byte único) de comprimento.
8. Opcional: para ativar os registros de verificação de integridade, em Registros, selecione Ativado.
9. Em Intervalo de verificação, insira o intervalo de tempo em segundos entre as sondagens de verificação de integridade. O intervalo de verificação é o tempo desde o início de uma sondagem emitida por uma sonda até o início da próxima sondagem emitida pela mesma sonda.
10. Em Tempo limite, digite o tempo em segundos que você quer que o Google Cloud aguarde uma resposta a uma sondagem.
11. Em Limite íntegro, insira o número de resultados de sondagem bem-sucedidos consecutivos para que um back-end seja considerado íntegro.
12. Em Limite não íntegro, insira o número de resultados de sondagem falhados consecutivos para que um back-end seja considerado não íntegro.
13. Clique em Criar.
Clique em Próximo.

Failover

Na seção Destino do endereço IP externo principal, em Endereço IP, insira o endereço IP externo principal que foi verificado quanto à integridade para este registro.
Opcional:para selecionar um endereço IP externo principal de um recurso do Google Cloud no projeto atual, clique em Selecionar.
Opcional: para adicionar outro endereço IP externo principal, clique em Adicionar destino. Quando o DNSSEC está ativado, você só pode adicionar um destino de endereço IP externo principal .
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. Em Região de origem, selecione uma região de origem válida do Google Cloud.
3. Na seção Endereços IP externos, faça o seguinte:
  1. Em Endereço IP , insira um endereço IP externo.
  2. Opcional: para selecionar um endereço IP externo de um recurso do Google Cloud no projeto atual, clique em Selecionar.
  3. Para ativar a verificação de integridade, selecione Verificação de integridade 1.
  4. Opcional: para adicionar outro endereço IP externo, clique em Adicionar endereço IP.
4. Clique em Concluído.
Se você ativou a verificação de integridade na etapa anterior, selecione uma verificação de integridade na lista Verificação de integridade.

Se você não tiver uma verificação de integridade, crie uma.
1. Clique em Criar uma nova verificação de integridade.
2. Em Nome, digite um nome para a verificação de integridade.
3. Opcional: em Descrição, insira uma descrição para a verificação de integridade.
4. Em Regiões de origem, selecione três regiões do Google Cloud em que você quer enviar verificações de integridade.
5. Opcional: na lista Protocolo, selecione um protocolo.
6. Em Port, digite um número de porta.
O protocolo e o número da porta determinam como o Cloud DNS envia as sondagens de verificação de integridade.
1. Opcional: para configurar a verificação de integridade com base em conteúdo, em Resposta, forneça uma string de resposta esperada, cada uma com até 1.024 caracteres ASCII (byte único) de comprimento.
2. Opcional: para ativar os registros de verificação de integridade, em Registros, selecione Ativado.
3. Em Intervalo de verificação, insira o intervalo de tempo em segundos entre as sondagens de verificação de integridade. O intervalo de verificação é o tempo desde o início de uma sondagem emitida por uma sonda até o início da próxima sondagem emitida pela mesma sonda.
4. Em Tempo limite, digite o tempo em segundos que você quer que o Google Cloud aguarde uma resposta a uma sondagem.
5. Em Limite íntegro, insira o número de resultados de sondagem bem-sucedidos consecutivos para que um back-end seja considerado íntegro.
6. Em Limite não íntegro, insira o número de resultados de sondagem falhados consecutivos para que um back-end seja considerado não íntegro.
7. Clique em Criar.
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.
Na lista Verificação de integridade, selecione uma verificação.
Clique em Próxima.

Revisar e criar

Clique em Revisar.
Revise seu conjunto de registros do Cloud DNS com a configuração da política de roteamento.
Clique em Criar.

gcloud

Para criar políticas de roteamento de DNS para zonas públicas, siga estas etapas.

Para ativar a verificação de integridade nas políticas de roteamento de DNS para zonas públicas, crie uma verificação de integridade para endpoints externos.

Execute o 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
```
Substitua:
- PROTOCOL: o protocolo usado para a verificação de integridade. As opções válidas são http, https, ssl ou tcp.
- HEALTH_CHECK_NAME: o nome da verificação de integridade.
- CHECK_INTERVAL: o tempo entre o início da conexão de um sistema de sondagem de verificação de integridade e o início da próxima. As unidades são informadas em segundos. O valor CHECK_INTERVAL precisa estar entre 30 e 300 segundos.
- SOURCE_REGIONS: uma lista separada por vírgulas de regiões do Google Cloud em que você quer enviar verificações de integridade.
- PORT_NUMBER: o número da porta para solicitações de verificação de integridade.
Para criar um ResourceRecordSet e aplicar uma política de roteamento a ele, execute o 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
```
Substitua:
- RRSET_NAME: o nome de DNS que corresponde às consultas recebidas com o nome DNS desta zona como sufixo, por exemplo, service.example.com.
- TTL: o TTL, em segundos, em que o resolvedor armazena essa ResourceRecordSet em cache, como 30.
- RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A.
- 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.
- ROUTING_POLICY_DATA: os dados da política de roteamento. Insira uma lista delimitada por ponto e vírgula no formato ${weight_percent}:${rrdatas}, como .8=203.0.113.1;.2=198.51.100.1. Especifique a ponderação como um decimal não negativo. O peso precisa ser um número não negativo de 0 a 1000.
- HEALTH_CHECK_NAME: o nome da verificação de integridade criada na etapa anterior.
Geolocalização
```
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
```
Substitua:
- RRSET_NAME: o nome de DNS que corresponde às consultas recebidas com o nome DNS desta zona como sufixo, por exemplo, service.example.com.
- TTL: o TTL, em segundos, em que o resolvedor armazena essa ResourceRecordSet em cache, como 30.
- RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A.
- 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.
- ROUTING_POLICY_DATA: os dados da política de roteamento. Insira uma lista delimitada por ponto e vírgula no formato ${region}=${IP_address},${IP_address}, como asia-east1=198.51.100.1;us-central1=203.0.113.1, 203.0.113.2. É 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.
- HEALTH_CHECK_NAME: o nome da verificação de integridade criada na etapa anterior.
Geolocalização com fronteira geográfica virtual
```
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
```
Substitua:
- RRSET_NAME: o nome de DNS que corresponde às consultas recebidas com o nome DNS desta zona como sufixo, por exemplo, service.example.com.
- TTL: o TTL, em segundos, em que o resolvedor armazena essa ResourceRecordSet em cache, como 30.
- RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A.
- 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.
- ROUTING_POLICY_DATA: os dados da política de roteamento. Insira uma lista delimitada por ponto e vírgula no 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.
- HEALTH_CHECK_NAME: o nome da verificação de integridade criada na etapa anterior.
  
  --enable-geo-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. 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.
Failover
```
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
```
Substitua:
- RRSET_NAME: o nome de DNS que corresponde às consultas recebidas com o nome DNS desta zona como sufixo, por exemplo, service.example.com.
- TTL: o TTL, em segundos, em que o resolvedor armazena essa ResourceRecordSet em cache, como 30
- RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A.
- 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.
- 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 políticas de roteamento 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 políticas de roteamento FAILOVER, o tipo de política de roteamento usado pelos dados de backup. Precisa ser GEO.
- BACKUP_DATA_TRICKLE_RATIO: a proporção de tráfego a ser enviada aos destinos de backup, mesmo quando os primários estão íntegros. A proporção precisa estar entre 0 e 1, como 0.1. O padrão é definido como 0.
- HEALTH_CHECK_NAME: o nome da verificação de integridade criada na etapa anterior.

API

Para ativar a verificação de integridade nas políticas de roteamento de DNS para zonas públicas, use o método healthChecks.insert.
Para criar um ResourceRecordSet e aplicar uma política de roteamento a ele, use o 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"]
                    }
                }]
            }
        }
    }
  
```
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 sufixo, por exemplo, service.example.com.
- TTL: o TTL, em segundos, em que o resolvedor armazena essa ResourceRecordSet em cache, como 30.
- RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A.
- HEALTH_CHECK_NAME: o nome da verificação de integridade.
- 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. Observação: é preciso especificar o peso como um número 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.
- RRDATA: 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.
Geolocalização
```
    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"]
                    }
                }]
            }
        }
    }
  
```
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 sufixo, por exemplo, service.example.com.
- RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A.
- TTL: o TTL, em segundos, em que o resolvedor armazena essa ResourceRecordSet em cache, como 30.
- HEALTH_CHECK_NAME: o nome da verificação de integridade.
- 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. As opções válidas são true e false. A configuração padrão para isso é false.
- LOCATION: para políticas de GEO, a geolocalização para que você precisa criar a política, como asia-east1.
- RRDATA: 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.
Failover
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": {
            "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"]
                    }]
                }
            }
        }
    }
  
```
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 sufixo, por exemplo, service.example.com.
- RRSET_TYPE: o tipo de registro de recurso desse ResourceRecordSet, como A.
- TTL: o TTL, em segundos, em que o resolvedor armazena essa ResourceRecordSet em cache, como 30.
- HEALTH_CHECK_NAME: o nome da verificação de integridade.
- TRICKLE_TRAFFIC: 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.
- RRDATA: 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.
- ENABLE_FENCING: para políticas de roteamento de GEO, isso determina se o tráfego precisa 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. A configuração padrão é false.
- LOCATION: para políticas de GEO, a geolocalização para que você precisa criar a política, como asia-east1.

Atualizar políticas de roteamento de DNS

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

Console

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

Acessar zonas do Cloud DNS
Clique na zona em que você quer atualizar a política de roteamento do conjunto de registros de recursos.
Na página Detalhes da zona, ao lado do conjunto de registros de recursos que você quer atualizar, clique em Editar.
Depois de fazer as atualizações, clique em Salvar.

gcloud

Execute o gcloud dns record-sets updatecomando:

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

Geolocalização

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

Geolocalização com fronteira geográfica virtual

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

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, em 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 à qual este ResourceRecordSet está afiliado, como service-zone; o nome deste 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 um 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}.
  
  Observação:quando as verificações de integridade estão desativadas, os rrdata para "WRR" ou "GEO" podem ser RFC 1035 no formato DNS "rrdata".
  Quando as verificações de integridade estão ativadas, o rrdata é uma referência a uma regra de encaminhamento. O Cloud DNS usa o endereço IP da regra de encaminhamento como o rrdata. Se ela não estiver íntegra, o Cloud DNS monitora o status de integridade da regra de encaminhamento e a remove dos resultados.
--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, todos os endpoints de uma região não estão íntegros, e o Cloud DNS direciona as consultas para a região mais próxima. A configuraçã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.

WRR

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": ["RRDATA"]
                  },
                  {
                      "weight": WEIGHT,
                      "rrdatas": ["RRDATA"]
                  }
            ],
          }
    }
}

Geolocalização

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

      }
  }
}

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, em 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
Observação:é preciso especificar o peso como um número 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.
RRDATA: 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, globalL7ilb ou regionalL7ilb. Essa configuração é opcional.
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, é necessário excluir o conjunto de registros de recursos que contém a política de roteamento. Para fazer isso, siga estas etapas.

Console

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

Acessar zonas do Cloud DNS
Clique na zona em que você quer excluir o conjunto de registros de recursos.
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.
Clique em Excluir conjuntos de registros.

gcloud

Execute o gcloud dns record-sets deletecomando:

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

Para trabalhar com zonas gerenciadas, consulte Criar, modificar e excluir zonas.
Para achar soluções de problemas comuns que podem ser encontrados ao usar o Cloud DNS, consulte Solução de problemas.
Para uma visão geral do Cloud DNS, consulte Visão geral do Cloud DNS.