Esta página foi traduzida pela API Cloud Translation.

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

Nesta página, descrevemos como configurar políticas de roteamento de DNS e ativar verificações de integridade usando o Cloud DNS. Antes de usar esta página, familiarize-se com Políticas de roteamento de DNS e 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 recurso e escolha as seguintes políticas de roteamento de DNS para aplicar ao conjunto de registros de recurso:

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 um failover política de roteamento. Nesse caso, você pode definir uma política de roteamento de geolocalização como backup. O acesso global precisa estar 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, conclua a etapas seguintes.

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 instruções 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, para Nome do DNS, digite um subdomínio do nome DNS. Por exemplo, exemplo: mail. O ponto final é adicionado automaticamente.

Importante: adicionar o sinal de arroba (@) a este campo faz com que o registro a falhar.
Em Tipo de registro de recurso, selecione uma opção.
Em TTL, insira um valor numérico para o valor time to live (TTL) que é o tempo que ele pode ser armazenado em cache. O valor precisa ser um número inteiro positivo.
Opcional: em Unidade de TTL, selecione a unidade de tempo, por exemplo, minutes O padrão é definido como minutes.
Clique em Next.

Tipo de política de roteamento

Em Política de roteamento, selecione Round-robin ponderado. Geolocation ou failover.
Clique em Next.

Dados da política de roteamento

WRR

Em Peso, insira o peso correspondente ao dos dados do registro de recurso (RR).

Esse peso precisa ser um número não negativo de 0,0 a 1.000,0. Proporção de o tráfego roteado para a meta é calculado a partir da proporção de peso sobre o total em todos os pesos. Por exemplo, se o destino A tem um peso de 25 e o objetivo B tem um peso de 75, com um peso total de 100, o Cloud DNS encaminha 25/100 = 0,25 (25%) do total para segmentar A e 75/100= 0, 75 (75%) para B.
Na seção Destinos de verificação de integridade IPv4, faça o seguinte:
1. Em Projeto, selecione o projeto em que o encaminhamento regra existe.
2. Em Regra de encaminhamento, selecione uma regra de encaminhamento.
  
  A regra de encaminhamento especifica um endereço IP interno, uma porta e um dos seguintes destinos:
  - 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 com verificação 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, digite um endereço IPv4.
Opcional: para adicionar outro conjunto de dados de roteamento de políticas de WRR, clique em Adicionar dados de roteamento.
Clique em Next.

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 dessa geolocalização não estejam íntegros.
Em Região de origem, selecione um Google Cloud válido região de origem.
Na seção Destinos de verificação de integridade IPv4, faça o seguinte:
1. Em Projeto, selecione o projeto em que o encaminhamento regra existe.
2. Em Regra de encaminhamento, selecione uma regra de encaminhamento.
  
  A regra de encaminhamento especifica um endereço IP interno, uma porta e um dos seguintes destinos:
  - 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 com verificação 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, digite um endereço IPv4.
Opcional: para adicionar um conjunto de outros dados de roteamento da política de geolocalização, clique em Adicionar dados de roteamento.
Clique em Next.

Failover

Na seção Principais destinos com verificação de integridade, faça o seguinte:
1. Em Projeto, selecione o projeto em que o encaminhamento regra existe.
2. Em Regra de encaminhamento, selecione uma regra de encaminhamento.
  
  A regra de encaminhamento especifica um endereço IP interno, uma porta e um dos seguintes destinos:
  - 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. Ativando a fronteira geográfica virtual restringe o tráfego a uma geolocalização específica mesmo que todos os endpoints dessa geolocalização não estejam íntegros.
2. Em Região de origem, selecione um Google Cloud válido região de origem.
3. Na seção Destinos de verificação de integridade IPv4, faça o seguinte:
  1. Em Projeto, selecione o projeto em que o encaminhamento regra existe.
  2. Em Regra de encaminhamento, selecione uma regra de encaminhamento.
    
    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 com verificação 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, digite um endereço IPv4.
Opcional: para adicionar outro conjunto de roteamento da política de geolocalização de backup dados, 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 Next.

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 de 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 alterar um recurso conjunto de registros que contém dados de DNS (rrdatas) para, em vez disso, conter um 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 instruções 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 DNS que corresponde ao consultas com o nome do DNS dessa zona como sufixo, como 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 dispositivos com suporte tipos de registro, consulte Tipos de registro compatíveis com políticas de roteamento de DNS.
MANAGED_ZONE: a zona gerenciada em que esta A conta ResourceRecordSet é afiliada à empresa service-zone, por exemplo. O nome ResourceRecordSet precisa ter o mesmo nome DNS do zona gerenciada como sufixo.
ROUTING_POLICY_DATA: insira um valor delimitado por ponto e vírgula lista no formato ${weight_percent}:${rrdatas}, como .8=203.0.113.1;.2=198.51.100.1 Especifique o peso como uma 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 DNS que corresponde ao consultas com o nome do DNS dessa zona como sufixo, como 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 dispositivos com suporte tipos de registro, consulte Tipos de registro compatíveis com políticas de roteamento de DNS.
MANAGED_ZONE: a zona gerenciada em que esta A conta ResourceRecordSet é afiliada à empresa service-zone, por exemplo. O nome ResourceRecordSet precisa ter o mesmo nome DNS do zona gerenciada como sufixo.
ROUTING_POLICY_DATA: insira um valor delimitado por ponto e vírgula lista 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 DNS que corresponde ao consultas com o nome do DNS dessa zona como sufixo, como 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 dispositivos com suporte tipos de registro, consulte Tipos de registro compatíveis com políticas de roteamento de DNS.
MANAGED_ZONE: a zona gerenciada em que esta A conta ResourceRecordSet é afiliada à empresa service-zone, por exemplo. O nome ResourceRecordSet precisa ter o mesmo nome DNS do zona gerenciada como sufixo.
ROUTING_POLICY_DATA: insira um valor delimitado por ponto e vírgula lista 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 está definido, O Cloud DNS direciona as consultas para o região quando todos os endpoints dela não forem í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 DNS que corresponde ao consultas com o nome do DNS dessa zona como sufixo, como 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 dispositivos com suporte tipos de registro, consulte Tipos de registro compatíveis com políticas de roteamento de DNS.
MANAGED_ZONE: a zona gerenciada em que esta A conta ResourceRecordSet é afiliada à empresa service-zone, por exemplo. O nome ResourceRecordSet precisa ter o mesmo nome DNS do 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 está definido, O Cloud DNS direciona as consultas para o região quando todos os endpoints dela não forem í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 em cache este ResourceRecordSet, 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 especificar o peso como qualquer valor decimal Observação: você deve especificar o peso como um valor não negativo número 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 o encaminhamento. regra

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 em cache este ResourceRecordSet, 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 da carga interna balanceador
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 em cache este ResourceRecordSet, 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 da carga interna balanceador
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 próxima 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 especificar o peso como qualquer valor decimal
Observação:é necessário especificar o peso como um valor não negativo número 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, para Nome do DNS, digite um subdomínio do nome do DNS pré-preenchido. Por exemplo, exemplo: mail. O ponto final é adicionado automaticamente.

Importante: adicionar o sinal de arroba (@) a este campo faz com que o registro a falhar.
Em Tipo de registro de recurso, selecione uma opção.
Em TTL, insira um valor numérico para o valor time to live (TTL), que é a quantidade de tempo que eles podem ser armazenados em cache. Esse valor precisa ser um número inteiro positivo.
Opcional: em Unidade de TTL, selecione a unidade de tempo, por exemplo, minutes O padrão é definido como minutes.
Clique em Next.

Tipo de política de roteamento

Em Política de roteamento, selecione Round-robin ponderado. Geolocation ou failover.
Clique em Next.

Dados da política de roteamento

WRR

Em Peso, insira o peso correspondente ao dos dados do registro de recurso (RR).

Esse peso precisa ser um número não negativo de 0,0 a 1.000,0. Proporção de o tráfego roteado para a meta é calculado a partir da proporção de peso sobre o total em todos os pesos. Por exemplo, se o destino A tem um peso de 25 e o objetivo B tem um peso de 75, com um peso total de 100, o Cloud DNS encaminha 25/100 = 0,25 (25%) do total para segmentar A e 75/100= 0, 75 (75%) para B.
Na seção Endereços IP externos, faça o seguinte:
1. Em Endereço IP , digite um endereço IP externo.
2. Opcional: para selecionar um endereço IP externo de uma instância do Google Cloud recurso 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ê ativou a verificação de integridade na etapa anterior, na seção Verificação de integridade, selecione uma verificação ou crie uma nova seguindo estas etapas.
1. Clique em Criar 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 integridade verificação.
4. Em Regiões de origem, selecione três opções do Google Cloud regiões de onde você quer enviar sondagens de verificação de integridade.
5. Opcional: na lista Protocolo, selecione um protocolo.
6. Em Porta, digite um número de porta.
  
  O protocolo e o número da porta determinam como o Cloud DNS envia as sondagens da verificação de integridade.
7. Opcional: para configurar a verificação de integridade baseada em conteúdo, em Resposta: forneça uma string de resposta esperada, cada uma com até 1.024 ASCII (byte único) caracteres.
8. Opcional: para ativar os registros de verificação de integridade, em Registros, selecione Ativada.
9. Em Intervalo de verificação, insira o intervalo de tempo em segundos. entre sondagens de verificação de integridade. O intervalo de verificação é a quantidade tempo desde o início de uma sondagem emitida por uma sonda até início da próxima sondagem emitida pela mesma sonda.
10. Para Tempo limite, insira o tempo em segundos que você quer o Google Cloud aguardar a resposta de uma sondagem.
11. Em Limite íntegro, insira o número de erros resultados de sondagem bem-sucedidos para que um back-end seja considerado íntegro.
12. Em Limite não íntegro, insira o número de erros com falha 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. Ativando a fronteira geográfica virtual restringe o tráfego a uma geolocalização específica mesmo que todos os endpoints dessa geolocalização não estejam íntegros.
Em Região de origem, selecione um Google Cloud válido região de origem.
Na seção Endereços IP externos, faça o seguinte:
1. Em Endereço IP , digite um endereço IP externo.
2. Opcional: para selecionar um endereço IP externo de uma instância do Google Cloud recurso 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ê ativou a verificação de integridade na etapa anterior, na seção Verificação de integridade, selecione uma verificação ou crie uma nova seguindo estas etapas.
1. Clique em Criar 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 o verificação de integridade.
4. Em Regiões de origem, selecione três opções do Google Cloud regiões de onde você quer enviar sondagens de verificação de integridade.
5. Opcional: na lista Protocolo, selecione um protocolo.
6. Em Porta, digite um número de porta.
  
  O protocolo e o número da porta determinam como o Cloud DNS envia as sondagens da verificação de integridade.
7. Opcional: para configurar a verificação de integridade baseada em conteúdo, em Resposta: forneça uma string de resposta esperada, cada uma com até 1.024 ASCII (byte único) caracteres.
8. Opcional: para ativar os registros de verificação de integridade, em Registros, selecione Ativada.
9. Em Intervalo de verificação, insira o intervalo de tempo em segundos. entre sondagens de verificação de integridade. O intervalo de verificação é a quantidade tempo desde o início de uma sondagem emitida por uma sonda até início da próxima sondagem emitida pela mesma sonda.
10. Para Tempo limite, insira o tempo em segundos que você quer o Google Cloud aguardar a resposta de uma sondagem.
11. Em Limite íntegro, insira o número de erros resultados de sondagem bem-sucedidos para que um back-end seja considerado íntegro.
12. Em Limite não íntegro, insira o número de erros com falha 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, para Endereço IP, insira o endereço IP externo primário que está íntegro este registro foi verificado.
Opcional:para selecionar um endereço IP externo primário de um Google Cloud recurso no projeto atual, clique em Selecionar.
Opcional: para adicionar outro endereço IP externo principal, clique em Adicionar destino. Quando as DNSSEC estão ativadas, só é possível adicionar uma conta principal destino de endereço IP externo .
Na seção Política de geolocalização de backup, faça o seguinte:
1. Em Cercas geográficas, selecione Desativada ou Ativada. Ativando a fronteira geográfica virtual restringe o tráfego a uma geolocalização específica mesmo que todos os endpoints dessa geolocalização não estejam íntegros.
2. Em Região de origem, selecione um Google Cloud válido região de origem.
3. Na seção Endereços IP externos, faça o seguinte:
  1. Em Endereço IP , digite um endereço IP externo.
  2. Opcional: para selecionar um endereço IP externo de uma instância do Google Cloud recurso 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, na seção Verificação de integridade, selecione uma verificação de integridade.

Se você não tiver uma verificação de integridade, crie uma nova verificação.
1. Clique em Criar 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 integridade verificação.
4. Em Regiões de origem, selecione três opções do Google Cloud regiões de onde você quer enviar sondagens de verificação de integridade.
5. Opcional: na lista Protocolo, selecione um protocolo.
6. Em Porta, digite um número de porta.
O protocolo e o número da porta determinam como o Cloud DNS envia as sondagens da verificação de integridade.
1. Opcional: para configurar a verificação de integridade baseada em conteúdo, em Resposta: forneça uma string de resposta esperada, cada uma com até 1.024 ASCII (byte único) caracteres.
2. Opcional: para ativar os registros de verificação de integridade, em Registros, selecione Ativada.
3. Em Intervalo de verificação, insira o intervalo de tempo em segundos. entre sondagens de verificação de integridade. O intervalo de verificação é a quantidade tempo desde o início de uma sondagem emitida por uma sonda até início da próxima sondagem emitida pela mesma sonda.
4. Para Tempo limite, insira o tempo em segundos que você quer o Google Cloud aguardar a resposta de uma sondagem.
5. Em Limite íntegro, insira o número de erros resultados de sondagem bem-sucedidos para que um back-end seja considerado íntegro.
6. Em Limite não íntegro, insira o número de erros com falha para que um back-end seja considerado não íntegro.
7. Clique em Criar.
No campo Tráfego do Trickle (%), digite a porcentagem do o tráfego enviado aos destinos de failover, seja qual for a verificação de integridade o status dos alvos principais.
Na lista Verificação de integridade, selecione uma opção.
Clique em Next.

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 em políticas de roteamento de DNS para zonas públicas, e criar 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 desde o início da conexão de um sistema de sondagem de verificação de integridade ao início do próxima. As unidades são informadas em segundos. O CHECK_INTERVAL o valor precisa estar entre 30 e 300 segundos.
- SOURCE_REGIONS: uma lista separada por vírgulas de Regiões do Google Cloud de onde você quer enviar verificação de integridade sondagens.
- PORT_NUMBER: o número da porta da verificação de integridade solicitações.
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 DNS que corresponde ao consultas recebidas com o nome do DNS dessa zona como sufixo, como como service.example.com.
- TTL: o TTL, em segundos, em que o o resolvedor armazena em cache esse ResourceRecordSet, como 30.
- RRSET_TYPE: o tipo de registro de recurso. desse ResourceRecordSet, como A.
- MANAGED_ZONE: a zona gerenciada em que esta A conta ResourceRecordSet é afiliada à empresa service-zone, por exemplo. O nome ResourceRecordSet precisa ter o mesmo nome DNS de a 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 o peso como uma decimal não negativo. O peso deve ser um número não negativo de 0 para 1000.
- HEALTH_CHECK_NAME: o nome do sistema de saúde. verifique se você criou 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 DNS que corresponde ao consultas recebidas com o nome do DNS dessa zona como sufixo, como como service.example.com.
- TTL: o TTL, em segundos, em que o o resolvedor armazena em cache esse ResourceRecordSet, como 30.
- RRSET_TYPE: o tipo de registro de recurso. desse ResourceRecordSet, como A.
- MANAGED_ZONE: a zona gerenciada em que esta A conta ResourceRecordSet é afiliada à empresa service-zone, por exemplo. O nome ResourceRecordSet precisa ter o mesmo nome DNS do 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 uma vírgula. Nomes de regras de encaminhamento são valores aceitáveis e resultam em uma verificação de integridade.
- HEALTH_CHECK_NAME: o nome do sistema de saúde. verifique se você criou 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 DNS que corresponde ao consultas recebidas com o nome do DNS dessa zona como sufixo, como como service.example.com.
- TTL: o TTL, em segundos, em que o o resolvedor armazena em cache esse ResourceRecordSet, como 30.
- RRSET_TYPE: o tipo de registro de recurso. desse ResourceRecordSet, como A.
- MANAGED_ZONE: a zona gerenciada em que esta A conta ResourceRecordSet é afiliada à empresa service-zone, por exemplo. O nome ResourceRecordSet precisa ter o mesmo nome DNS de a 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. Você pode especificar vários endereços IP para uma única região adicionando endereços separados por vírgula. Os nomes das regras de encaminhamento são valores aceitáveis e resultam em uma verificação de integridade.
- HEALTH_CHECK_NAME: o nome do sistema de saúde. verifique se você criou 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 todas os endpoints dessa região não estiverem íntegros. Usar --no-enable-geo-fencing para desativar a fronteira geográfica virtual. Quando não estiver definido, O Cloud DNS direciona as consultas para o região quando todos os endpoints dela não forem íntegros. Isso 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 DNS que corresponde ao consultas recebidas com o nome do DNS dessa zona como sufixo, como como service.example.com.
- TTL: o TTL, em segundos, em que o o resolvedor armazena esse ResourceRecordSet em cache, como 30
- RRSET_TYPE: o tipo de registro de recurso. desse ResourceRecordSet, como A.
- MANAGED_ZONE: a zona gerenciada em que esta A conta ResourceRecordSet é afiliada à empresa service-zone, por exemplo. O nome ResourceRecordSet precisa ter o mesmo nome DNS de a zona gerenciada como sufixo.
- ROUTING_POLICY_PRIMARY_DATA: o principal. destino a ser usado para políticas de roteamento FAILOVER. Esse destino deve ser uma referência a uma ou mais regras de encaminhamento, como forwarding-rule-1: Enquanto pelo menos um desses encaminhamentos regras de encaminhamento estão íntegras, os endereços IP de todas as instâncias são usadas para responder a consultas por esse nome.
- ROUTING_POLICY_BACKUP_DATA: o backup destino a ser usado para políticas de roteamento FAILOVER. Essas metas são usada quando todas as regras de encaminhamento especificadas na --routing-policy-primary-data não estão íntegros. O Cloud DNS só é compatível com destinos de backup baseados em localização geográfica. A o formato deste campo corresponde ao de --routing-policy-data quando --routing-policy-type = 'GEO', como asia-east1=forwarding-rule-2
- ROUTING_POLICY_BACKUP_DATA_TYPE: para FAILOVER, o tipo de política de roteamento que usos de dados de backup. Precisa ser GEO.
- BACKUP_DATA_TRICKLE_RATIO: a proporção de tráfego a ser enviado aos destinos de backup, mesmo quando estejam saudáveis. A proporção precisa estar entre 0 e 1, como 0.1. O padrão é definido como 0.
- HEALTH_CHECK_NAME: o nome do sistema de saúde. verifique se você criou na etapa anterior.

API

Para ativar a verificação de integridade em 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 em que esta ResourceRecordSet é afiliada a service-zone, por exemplo. o nome de ResourceRecordSet deve ter o nome DNS do zona gerenciada como sufixo.
- RRSET_NAME: o nome DNS que corresponde ao consultas com o nome do DNS dessa zona como sufixo, como service.example.com.
- TTL: o TTL, em segundos, em que o resolvedor armazena esse valor em cache ResourceRecordSet, 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 especificar o peso como qualquer valor decimal. Observação: você deve especificar o peso como um valor não negativo número 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 recurso. conjunto de registros, como 198.51.100.5; você também pode inserir várias 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 em que esta ResourceRecordSet é afiliada a service-zone, por exemplo. o nome de ResourceRecordSet deve ter o nome DNS do zona gerenciada como sufixo.
- RRSET_NAME: o nome DNS que corresponde ao consultas com o nome do DNS dessa zona como sufixo, como 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 esse valor em cache ResourceRecordSet, 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 próxima 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 é false.
- LOCATION: para GEO políticas, a geolocalização para de que você precisa para criar a política, como asia-east1.
- RRDATA: um valor arbitrário associado ao recurso. conjunto de registros, como 198.51.100.5; você também pode inserir várias 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 em que esta ResourceRecordSet é afiliada a service-zone, por exemplo. o nome de ResourceRecordSet deve ter o nome DNS do zona gerenciada como sufixo.
- RRSET_NAME: o nome DNS que corresponde ao consultas com o nome do DNS dessa zona como sufixo, como 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 esse valor em cache ResourceRecordSet, como 30.
- HEALTH_CHECK_NAME: o nome da verificação de integridade.
- TRICKLE_TRAFFIC: a proporção de tráfego para envie aos destinos de backup mesmo quando os primários estiverem íntegros. a proporção precisa estar entre 0 e 1, como 0.1.
- RRDATA: um valor arbitrário associado ao recurso. conjunto de registros, como 198.51.100.5; você também pode inserir várias valores, rrdata1,rrdata2,rrdata3, como 198.51.100.1, 203.0.113.1.
- ENABLE_FENCING: para políticas de roteamento GEO, este determina se o tráfego precisa fazer failover entre regiões se todas dos endpoints de uma região não estão í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 próxima região mais próxima quando todos os endpoints de uma região não estiverem íntegros. A configuração padrão para isso é false.
- LOCATION: para GEO políticas, a geolocalização para de que você precisa para 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 recurso, 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 o conjunto de registros de recursos política de roteamento.
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 esse valor em cache ResourceRecordSet, 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 o peso como uma 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, o rrdata para "WRR" ou "GEO" pode ser RFC 1035 (em inglês) format de 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 se tornar não íntegra, O Cloud DNS monitora o status de integridade da regra de encaminhamento e remove a regra de encaminhamento dos resultados.
--enable-geo-fencing: para políticas de roteamento GEO, isso determina se o tráfego deve fazer o failover entre regiões se todos os endpoints de uma ou região não estiverem íntegras. 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 consultas para a região mais próxima. A configuração padrão para isso é 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 esse valor em cache ResourceRecordSet, 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 próxima 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 especificar o peso como qualquer valor decimal
Observação:é necessário especificar o peso como um valor não negativo número 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, você precisa excluir o conjunto de registros de recurso 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.