Visão geral do Cloud DNS

Nesta página, você encontra uma visão geral dos recursos do Cloud DNS. O Cloud DNS é um serviço de Sistema de Nome de Domínio (DNS, na sigla em inglês) global, confiável e de alto desempenho. Com ele, você publica nomes de domínio no DNS global com economia.

O DNS é um banco de dados distribuído hierarquicamente, usado para armazenar endereços IP e outros dados e para procurá-los por nome. Com o Cloud DNS, você publica zonas e registros no DNS sem precisar gerenciar os próprios servidores e software de DNS.

No Cloud DNS, são fornecidas zonas públicas e zonas DNS gerenciadas particulares. Uma zona pública é visível para todos na Internet pública, mas uma zona particular é visível apenas para os usuários em uma ou mais redes de nuvem privada virtual (VPC) especificadas.

Para ver uma lista de terminologia geral de DNS, acesse a visão geral do DNS.

Veja uma lista de termos-chave em que o Cloud DNS é criado em Termos importantes.

Para começar a usar o Cloud DNS, consulte o Início rápido.

Considerações sobre VPC compartilhada

Para usar uma zona privada gerenciada do Cloud DNS, uma zona de encaminhamento do Cloud DNS ou uma zona de peering do Cloud DNS com a VPC compartilhada, é preciso criar a zona no projeto host. Depois, adicione uma ou mais redes VPC compartilhadas à lista de redes autorizadas para essa zona.

Para acessar mais informações, consulte as práticas recomendadas para as zonas particulares do Cloud DNS.

Métodos de encaminhamento de DNS

O Google Cloud oferece encaminhamento de DNS de entrada e saída para zonas particulares. É possível configurar o encaminhamento de DNS criando uma zona de encaminhamento ou uma política de servidor do Cloud DNS. Os dois métodos estão resumidos na tabela a seguir:

Encaminhamento de DNS Métodos do Cloud DNS
Entrada

Crie uma política de servidor de entrada para permitir que um servidor ou cliente DNS local envie solicitações DNS para o Cloud DNS. O cliente ou servidor DNS pode resolver registros de acordo com a ordem de resolução de nomes de uma rede VPC.

Os clientes locais podem resolver registros em zonas particulares, zonas de encaminhamento e zonas de peering para as quais a rede VPC foi autorizada. Os clientes locais usam o Cloud VPN ou o Cloud Interconnect para se conectar à rede VPC.
Saída

É possível configurar VMs em uma rede VPC para:

  • Enviar solicitações de DNS para os servidores de nomes de DNS de sua escolha. Os servidores de nomes podem estar localizados na mesma rede VPC, em uma rede local ou na Internet.
  • Resolver registros hospedados em servidores de nomes configurados como destinos de encaminhamento de uma zona de encaminhamento autorizada para uso pela rede VPC. Para informações sobre como o Google Cloud encaminha o tráfego para o endereço IP de um destino de encaminhamento, consulte Métodos de encaminhamento e métodos de roteamento.
  • Crie uma política de servidor de saída para a rede VPC enviar todas as solicitações DNS de um servidor de nomes alternativo. Ao usar um servidor de nomes alternativo, as VMs na sua rede VPC não poderão mais ser usadas para resolver registros em zonas particulares, zonas de encaminhamento ou zonas de peering do Cloud DNS. Para ver mais detalhes, consulte a ordem de resolução de nomes de VPC.

É possível configurar simultaneamente o encaminhamento DNS de entrada e saída para uma rede VPC. O encaminhamento bidirecional permite que as VMs na sua rede VPC sejam usadas para resolver registros em uma rede no local ou em uma rede hospedada por outro provedor de nuvem. Esse tipo de encaminhamento também permite que os hosts na rede local sejam usados para resolver registros dos recursos do Google Cloud.

O plano de controle do Cloud DNS usa um algoritmo para determinar a capacidade de resposta de um destino de encaminhamento. Às vezes, suas consultas encaminhadas de saída podem resultar em erros SERVFAIL. Para informações sobre como contornar esse problema, consulte Consultas encaminhadas de saída recebem erros de SERVFAIL.

Para informações sobre como aplicar políticas de servidor, consulte Como criar políticas de servidor DNS. Para saber como criar uma zona de encaminhamento, consulte esta página.

Registros PTR para endereços RFC 1918 em zonas particulares

Para realizar pesquisas inversas com registros PTR personalizados em endereços RFC 1918 (em inglês), crie uma zona particular do Cloud DNS que seja, pelo menos, tão específica quanto uma das zonas a seguir. Isso é uma consequência da correspondência de sufixo mais longo descrita na ordem de resolução de nome da VPC.

Veja abaixo alguns exemplos de zonas:

  • 10.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 16.172.in-addr.arpa., 17.172.in-addr.arpa., ... até 31.172.in-addr.arpa.

Se você criar uma zona privada do Cloud DNS para endereços RFC 1918, os registros PTR personalizados criados para VMs nessa zona serão modificados pelos registros PTR que o DNS interno cria automaticamente. Isso ocorre porque os registros PTR do DNS internos são criados na lista anterior de zonas mais específicas.

Por exemplo, suponha que você tenha criado uma zona particular gerenciada para in-addr.arpa. com o seguinte registro PTR para uma VM com endereço IP 10.1.1.1:

1.1.1.10.in-addr.arpa. -> test.example.domain

As consultas de PTR para 1.1.1.10.in-addr.arpa. são respondidas pela zona de DNS interno 10.in-addr.arpa. mais específica. O registro PTR na zona particular do Cloud DNS para test.example.domain é ignorado.

Para modificar os registros PTR do DNS internos criados automaticamente para as VMs, crie seus registros PTR personalizados em uma zona particular que seja pelo menos tão específica quanto uma das zonas apresentadas nesta seção. Por exemplo, se você criar o registro PTR a seguir em uma zona particular para 10.in-addr.arpa., ele modificará o que foi gerado automaticamente: 1.1.1.10.in-addr.arpa. -> test.example.domain

Se você só precisar substituir uma parte de um bloco de rede, crie zonas particulares inversas do Cloud DNS mais específicas. Por exemplo, uma zona particular para 5.10.in-addr.arpa. pode ser usada para manter registros PTR que modificam registros DNS PTR internos que são criados automaticamente para VMs com endereços IP no intervalo de endereços 10.5.0.0/16.

Tipos de registro DNS compatíveis

O Cloud DNS aceita os seguintes tipos de registro.

Tipo de registro Descrição
A

Registro de endereço, que mapeia nomes de host para os respectivos endereços IPv4.
AAAA

Registro de endereço IPv6, que mapeia nomes de host para os respectivos endereços IPv6.

CAA

Autorização da autoridade de certificação (CA, na sigla em inglês), que especifica quais CAs têm permissão para criar certificados para um domínio.
CNAME

Registro de nome canônico, que especifica nomes de alias.

O Cloud DNS não é compatível com a resolução de CNAMEs recursivamente em diferentes zonas particulares gerenciadas (pesquisa CNAME). Para mais detalhes, consulte O registro CNAME definido em uma zona particular não funciona.
DNSKEY

A chave DNSSEC de outro operador para transferência segura. Esse tipo de conjunto de registros só pode ser adicionado a uma zona com DNSSEC ativo no estado de transferência.

DS

A impressão digital da chave DNSSEC para zona delegada segura. Esse tipo de conjunto de registros não ativa o DNSSEC para uma zona delegada, a menos que você habilite e ative o DNSSEC para ela.

IPSECKEY

Chaves públicas e dados do gateway do túnel IPSEC para clientes com recursos de IPSEC para permitir a criptografia oportunista.

MX

Registro de troca de e-mail, que encaminha solicitações para servidores de e-mail.
NAPTR

Registro PTR da autoridade de nomenclatura, definido pela referência RFC 3403 (em inglês).
NS

Registro do servidor de nomes, que delega uma zona DNS a um servidor autoritativo.
PTR

Registro PTR, muitas vezes usado para buscas DNS reverso.
SOA

Registro SOA, que especifica informações autoritativas sobre uma zona de DNS. Um registro de recurso SOA é gerado para você ao criar sua zona gerenciada. É possível modificar o registro conforme necessário. Por exemplo, alterar o número de série para um número arbitrário a fim de dar suporte ao controle de versão baseado em data.

SPF

Registro do framework de política do remetente, um tipo de registro obsoleto usado antigamente em sistemas de validação de e-mail. Em vez disso, use um registro TXT.

SRV

Registro de localizador de serviços, que é usado por alguns serviços de voz sobre IP (VoIP), protocolos de mensagem instantânea e outros aplicativos.

SSHFP

Impressão digital para que clientes SSH possam validar as chaves públicas de servidores SSH.

TLSA

Registro de autenticação para que clientes TLS possam validar certificados de servidores X.509.
TXT

Registro de texto, que pode conter texto arbitrário ou ser usado para definir dados legíveis por máquina, como informações de segurança ou para prevenção de abusos.

Um registro TXT pode conter uma ou mais strings de texto. O tamanho máximo de cada string individual é de 255 caracteres (em inglês). Agentes de e-mail e outros agentes de software concatenam várias strings. Coloque cada string entre aspas.

Para trabalhar com registros DNS, consulte Como gerenciar registros.

Registros DNS curinga

Registros curinga são aceitos para todos os tipos de registro, exceto para de NS.

DNSSEC

O Cloud DNS aceita DNSSEC gerenciado, que protege os domínios contra spoofing e ataques de envenenamento de cache. Quando você usa um resolvedor de validação como o DNS público do Google, o DNSSEC fornece uma autenticação forte (mas não criptografia) para pesquisas de domínio. Para mais informações sobre o DNSSEC, consulte Como gerenciar a configuração da DNSSEC.

Zonas de encaminhamento

Com as zonas de encaminhamento do Cloud DNS, é possível configurar servidores de nomes de destino para zonas particulares específicas. Usar uma zona de encaminhamento é uma maneira de implementar o encaminhamento de DNS de saída da sua rede VPC.

Uma zona de encaminhamento do Cloud DNS é um tipo especial de zona particular do Cloud DNS. Em vez de criar registros dentro da zona, especifique um conjunto de destinos de encaminhamento. Cada destino de encaminhamento é um endereço IP de um servidor DNS, localizado na sua rede VPC ou em uma rede local conectada à sua rede VPC pelo Cloud VPN ou pelo Cloud Interconnect.

Destinos de encaminhamento e métodos de roteamento

O Cloud DNS é compatível com três tipos de destinos e oferece métodos padrão ou particular para rotear o tráfego para eles.

Destino de encaminhamento Descrição Roteamento padrão compatível Compatibilidade com roteamento privado Origem das solicitações
Tipo 1 Um endereço IP interno de uma VM do Google Cloud na mesma rede VPC autorizada a usar a zona de encaminhamento Somente endereços IP RFC 1918: o tráfego sempre é roteado por uma rede VPC autorizada. Qualquer endereço IP interno, incluindo endereços IP privados não RFC 1918 e endereços IP públicos reutilizados de forma privada, o tráfego sempre é roteado por uma rede VPC autorizada. 35.199.192.0/19
Tipo 2 Um endereço IP de um sistema local, conectado à rede VPC autorizada a consultar a zona de encaminhamento, usando a VPN do Cloud ou o Cloud Interconnect. Somente endereços IP RFC 1918: o tráfego sempre é roteado por uma rede VPC autorizada. Qualquer endereço IP interno, incluindo endereços IP privados não RFC 1918 e endereços IP públicos reutilizados de forma privada, o tráfego sempre é roteado por uma rede VPC autorizada. 35.199.192.0/19
Tipo 3 Um endereço IP externo de um servidor de nomes de DNS acessível para a Internet ou o endereço IP externo de um recurso do Google Cloud; por exemplo, o endereço IP externo de uma VM em outra rede VPC. Somente endereços IP externos roteáveis pela Internet: o tráfego sempre é encaminhado para a Internet ou para o endereço IP externo de um recurso do Google Cloud. O roteamento particular não é compatível. Verifique se o roteamento privado não está selecionado. Intervalos de origem do DNS público do Google

É possível escolher um dos dois métodos de roteamento a seguir ao adicionar o destino de encaminhamento à zona de encaminhamento:

  • Roteamento padrão: encaminha o tráfego por meio de uma rede VPC autorizada ou pela Internet, com base no fato de o destino de encaminhamento ser ou não um endereço IP RFC 1918. Se o destino de encaminhamento for um endereço IP RFC 1918, o Cloud DNS o classificará como um destino Tipo 1 ou Tipo 2 e encaminhará as solicitações por meio de uma rede VPC autorizada. Se o destino não for um endereço IP RFC 1918, o Cloud DNS o classificará como Tipo 3 na expectativa de que o destino fique acessível pela Internet.

  • Roteamento privado: sempre encaminha o tráfego por meio de uma rede VPC autorizada, independentemente do endereço IP de destino (RFC 1918 ou não). Consequentemente, apenas os destinos Tipo 1 e Tipo 2 são compatíveis.

Para acessar um destino de encaminhamento do Tipo 1 ou Tipo 2, o Cloud DNS usa rotas na rede VPC autorizada, em que o cliente DNS está localizado. Essas rotas definem um caminho seguro para o destino de encaminhamento:

Veja mais orientações sobre os requisitos de rede para destinos do Tipo 1 e Tipo 2 em Requisitos de rede de destino de encaminhamento.

Como usar zonas de encaminhamento

Nas VMs em uma rede VPC, é possível usar uma zona de encaminhamento do Cloud DNS nos casos a seguir:

  • A rede VPC foi autorizada a usar a zona de encaminhamento do Cloud DNS. É possível autorizar várias redes VPC no mesmo projeto a usar a zona de encaminhamento.
  • O sistema operacional convidado de cada VM na rede VPC usa o servidor de metadados da VM, 169.254.169.254, como seu servidor de nomes.

Como sobrepor zonas de encaminhamento

Como as zonas de encaminhamento do Cloud DNS são um tipo de zona particular gerenciada por esse serviço, é possível criar várias zonas que se sobrepõem. As VMs configuradas conforme descrito acima resolvem um registro de acordo com a ordem de resolução de nome da VPC, usando a zona com o sufixo maior. Para mais informações, acesse Zonas sobrepostas.

Como armazenar em cache e encaminhar zonas

O Cloud DNS armazena em cache as respostas de consultas enviadas para as zonas de encaminhamento do Cloud DNS. O Cloud DNS mantém um cache de respostas de destinos de encaminhamento acessíveis para os mais curtos dos períodos a seguir:

  • 60 segundos
  • A duração do time to live (TTL) do registro

Quando todos os destinos de encaminhamento de uma zona de encaminhamento se tornam inacessíveis, o Cloud DNS mantém seu cache dos registros solicitados anteriormente nessa zona durante o TTL de cada registro.

Quando usar o peering

O Cloud DNS não pode usar roteamento transitivo para se conectar a um destino de encaminhamento. Para ilustrar uma configuração inválida, considere o cenário a seguir:

  • Você usou o Cloud VPN ou o Cloud Interconnect para conectar uma rede local a uma rede VPC chamada vpc-net-a.

  • Você usou o peering de rede VPC para conectar a rede VPC vpc-net-a a vpc-net-b. Você configurou vpc-net-a para exportar rotas personalizadas e vpc-net-b para importá-las.

  • Você criou uma zona de encaminhamento com destinos de encaminhamento localizados na rede local à que vpc-net-a está conectado. Você autorizou vpc-net-b a usar essa zona de encaminhamento.

Resolver um registro em uma zona veiculada pelos destinos de encaminhamento falhará nesse cenário, mesmo que haja conectividade de vpc-net-b com a rede local. Para demonstrar essa falha, execute os testes a seguir a partir de uma VM em vpc-net-b:

  • Consulte o servidor de metadados da VM, 169.254.169.254, para um registro definido na zona de encaminhamento. É esperado que essa consulta falhe, porque o Cloud DNS não é compatível com roteamento transitivo para destinos de encaminhamento. Para usar uma zona de encaminhamento, uma VM precisa ser configurada para usar o servidor de metadados dela.

  • Consulte o destino do encaminhamento diretamente em busca do mesmo registro. Embora o Cloud DNS não use esse caminho, essa consulta demonstra que a conectividade transitiva é bem-sucedida.

Use uma zona de peering do Cloud DNS para corrigir esse cenário inválido:

  1. Crie uma zona de peering do Cloud DNS autorizada para vpc-net-b que tenha como destino vpc-net-a.
  2. Crie uma zona de encaminhamento autorizada para vpc-net-a com destinos de encaminhamento que sejam servidores de nomes locais.

Essas etapas podem ser executadas em qualquer ordem. Depois de concluí-las, as instâncias do Compute Engine em vpc-net-a e vpc-net-b podem consultar os destinos de encaminhamento no local.

Peering de DNS

Com o peering de DNS, é possível enviar solicitações para registros provenientes do namespace de uma zona a outra rede VPC. Por exemplo, um provedor de SaaS pode conceder a um cliente SaaS acesso aos registros DNS que ele gerencia.

Para fazer um peering de DNS, você precisa criar uma zona de peering do Cloud DNS e configurá-la para executar buscas DNS na rede VPC em que os registros do namespace dessa zona estão disponíveis. A rede VPC em que a zona de peering de DNS executa buscas é chamada de rede do produtor de DNS.

Para usar o peering de DNS, é necessário autorizar uma rede a usar uma zona de peering. A rede VPC autorizada a usar a zona de peering é chamada de rede consumidora de DNS.

Depois que os recursos do Google Cloud na rede consumidora de DNS forem autorizados, eles poderão realizar pesquisas de registros no namespace da zona de peering, como se estivessem na rede produtora de DNS. As pesquisas por registros no namespace da zona de peering seguem a ordem de resolução de nomes da rede produtora de DNS.

Portanto, os recursos do Google Cloud na rede consumidora de DNS podem pesquisar registros no namespace da zona a partir das seguintes origens disponíveis na rede do produtor de DNS:

  • As zonas particulares gerenciadas do Cloud DNS autorizadas para uso da rede produtora de DNS
  • As zonas de encaminhamento gerenciadas do Cloud DNS autorizadas para uso da rede do produtor de DNS.
  • Os nomes de DNS interno do Compute Engine na rede produtora de DNS.
  • Um servidor de nomes alternativo, se uma política de servidor de saída tiver sido configurada na rede produtora de DNS.

Limitações e pontos-chave de peering de DNS

Tenha em mente o seguinte ao configurar o peering de DNS:

  • O peering de DNS é um relacionamento unidirecional. Ele permite que os recursos do Google Cloud na rede consumidora de DNS pesquisem registros no namespace da zona de peering, como se esses recursos estivessem na rede produtora de DNS.
  • As redes produtoras e consumidoras de DNS precisam ser redes VPC.
  • Embora as redes de produtor e consumidor de DNS normalmente façam parte da mesma organização, o peering de DNS entre organizações também é aceito.
  • O peering de DNS e o peering de rede VPC são serviços diferentes. O peering de DNS pode ser usado com o peering de rede VPC, mas este último não é necessário para o peering de DNS.
  • O peering de DNS transitivo é compatível, mas apenas por meio de um salto transitivo. Em outras palavras, não pode haver mais de três redes VPC (com a rede no meio sendo o salto transitivo). Por exemplo, é possível criar uma zona de peering em vpc-net-a que tenha como destino vpc-net-b e, em seguida, criar uma zona de peering em vpc-net-b que tenha como destino vpc-net-c.
  • Se você estiver usando o peering de DNS para segmentar uma zona de encaminhamento, a rede VPC de destino com a zona de encaminhamento precisará conter uma VM, um anexo da VLAN ou um túnel do Cloud VPN localizado na mesma região em que VM de origem que usa a zona de peering de DNS. Para detalhes sobre essa limitação, consulte Como encaminhar consultas de VMs em uma rede VPC consumidora para uma rede VPC produtora que não esteja funcionando.

Para criar uma zona de peering, é preciso ter o papel de IAM par de DNS no projeto que contém a rede produtora de DNS.

Zonas sobrepostas

Duas zonas se sobrepõem quando o nome de domínio de origem de uma delas é idêntico ou é um subdomínio da origem da outra. Exemplo:

  • Uma zona para gcp.example.com e outra para gcp.example.com se sobrepõem, porque os nomes de domínio são idênticos.
  • Uma zona para dev.gcp.example.com e uma zona para gcp.example.com se sobrepõem porque dev.gcp.example.com é um subdomínio de gcp.example.com.

Regras para sobrepor zonas

O Cloud DNS aplica as regras a seguir para zonas sobrepostas:

  • A sobreposição de zonas públicas não é permitida nos mesmos servidores de nomes do Cloud DNS. Quando você cria zonas sobrepostas, o Cloud DNS tenta colocá-las em servidores de nomes diferentes. Se isso não for possível, o Cloud DNS falhará na criação da zona sobreposta.

  • Uma zona particular pode se sobrepor a qualquer zona pública.

  • As zonas particulares no escopo de diferentes redes VPC podem se sobrepor umas às outras. Por exemplo, duas redes VPC podem ter uma VM de banco de dados chamada database.gcp.example.com em uma zona gcp.example.com. As consultas para database.gcp.example.com recebem respostas diferentes de acordo com os registros da zona definidos na zona autorizada para cada rede VPC.

  • Duas zonas particulares que tenham sido autorizadas para serem acessíveis a partir da mesma rede VPC não podem ter origens idênticas, a menos que uma seja subdomínio da outra. O servidor de metadados usa a correspondência de sufixo mais longa para determinar qual origem será consultada em busca de registros em uma determinada zona.

Exemplos de resolução de consulta

O Google Cloud resolve as zonas do Cloud DNS conforme descrito na ordem de resolução de nome da VPC. Ao determinar a zona para consultar um determinado registro, o Cloud DNS tenta encontrar uma zona que corresponda ao máximo do registro solicitado possível (maior correspondência de sufixo).

A menos que você tenha especificado um servidor de nomes alternativo em uma política de servidor de saída, primeiro o Google Cloud tentará encontrar um registro na zona particular, de encaminhamento ou de peering, autorizada para sua rede VPC antes de procurar o registro em uma zona pública.

Veja nos exemplos abaixo a ordem que o servidor de metadados usa ao consultar registros DNS. Para cada um desses exemplos, suponha que você criou duas zonas particulares, gcp.example.com e dev.gcp.example.com, e autorizou o acesso a elas a partir da mesma rede VPC. O Google Cloud processa as consultas DNS das VMs em uma rede VPC da seguinte maneira:

  • O servidor de metadados usa servidores de nomes públicos para resolver um registro para myapp.example.com, porque não há zona particular para example.com que tenha sido autorizada para a rede VPC.

  • O servidor de metadados resolve o registro myapp.gcp.example.com usando a zona particular autorizada gcp.example.com, porque gcp.example.com é o maior sufixo comum entre o nome do registro solicitado e as zonas particulares autorizadas disponíveis. Se não houver registro para myapp.gcp.example.com definido na zona particular gcp.example.com, a resposta será NXDOMAIN, mesmo se houver um registro para myapp.gcp.example.com definido em uma zona pública.

  • Da mesma forma, as consultas para myapp.dev.gcp.example.com são resolvidas de acordo com os registros na zona particular autorizada dev.gcp.example.com. Se não houver registro para myapp.dev.gcp.example.com na zona dev.gcp.example.com, a resposta será NXDOMAIN, mesmo se houver um registro para myapp.dev.gcp.example.com em outra zona particular ou pública.

  • As consultas para myapp.prod.gcp.example.com serão resolvidas de acordo com os registros na zona particular gcp.example.com, porque gcp.example.com é o maior sufixo comum entre o registro DNS solicitado e as zonas particulares disponíveis.

Exemplo de DNS split horizon

É possível usar uma combinação de zonas públicas e particulares em uma configuração de DNS split horizon. Com as zonas particulares, é possível definir respostas diferentes para uma consulta do mesmo registro quando a consulta se origina de uma VM dentro de uma rede VPC autorizada. O DNS split horizon é útil sempre que você precisa fornecer registros diferentes para as mesmas consultas DNS, dependendo da rede VPC de origem.

Considere o exemplo de split horizon a seguir:

  • Você criou uma zona pública, gcp.example.com, e configurou o registrador dela para usar servidores de nomes do Cloud DNS.
  • Você criou uma zona particular, gcp.example.com, e autorizou sua rede VPC a acessar essa zona.

Na zona particular, você criou um único registro, como mostrado na tabela a seguir.

Record Tipo TTL (segundos) Dados
foo.gcp.example.com A 5 10.128.1.35

Na zona pública, você criou dois registros:

Record Tipo TTL (segundos) Dados
foo.gcp.example.com A 5 104.198.6.142
bar.gcp.example.com A 50 104.198.7.145

As consultas a seguir são determinadas conforme descrito:

  • Uma consulta para foo.gcp.example.com de uma VM na sua rede VPC retorna 10.128.1.35.
  • Uma consulta para foo.gcp.example.com feita na Internet retorna 104.198.6.142.
  • Uma consulta para bar.gcp.example.com de uma VM na sua rede VPC retorna um erro NXDOMAIN, porque não há registro de bar.gcp.example.com na zona particular gcp.example.com.
  • Uma consulta para bar.gcp.example.com feita na Internet retorna 104.198.7.145.

Políticas do servidor DNS

É possível configurar uma política de servidor DNS para cada rede VPC. A política pode especificar encaminhamento de DNS de entrada, encaminhamento de DNS de saída ou ambos. Nesta seção, a política de servidor de entrada se refere a uma política que permite o encaminhamento do DNS de entrada. Política do servidor de saída refere-se a um método possível para implementar o encaminhamento de DNS de saída. É possível que uma política seja de servidor de entrada e de servidor de saída se os recursos de ambas forem implementados.

Para mais informações, consulte Como aplicar políticas de servidor do Cloud DNS.

Política do servidor de entrada

Cada rede VPC fornece serviços de resolução de nome DNS para as VMs que a utilizam. Quando uma VM usa o servidor de metadados, 169.254.169.254, como servidor de nomes, o Google Cloud procura registros DNS de acordo com a ordem de resolução de nome da VPC.

Por padrão, os serviços de resolução de nome de uma rede VPC, feitos por meio da ordem de resolução de nome, estão disponíveis apenas para essa rede VPC. É possível criar uma política de servidor de entrada na sua rede VPC para disponibilizar esses serviços de resolução de nomes para uma rede local conectada usando o Cloud VPN ou o Cloud Interconnect.

Quando você cria uma política de servidor de entrada, o Cloud DNS pega um endereço IP interno do intervalo principal de endereços IP de cada sub-rede usada pela rede VPC. Por exemplo, se você tiver uma rede VPC que contém duas sub-redes na mesma região e uma terceira sub-rede em uma região diferente, três endereços IP são reservado para encaminhamento de entrada. O Cloud DNS usa esses endereços IP internos como pontos de acesso para solicitações de DNS de entrada.

Pontos de entrada da política do servidor de entrada

Os endereços IP internos regionais usados pelo Cloud DNS para a política de servidor de entrada funcionam como pontos de entrada para os serviços de resolução de nomes da rede VPC. Para usar a política de servidor de entrada, configure seus sistemas locais ou servidores de nomes para encaminhar consultas DNS ao endereço IP do proxy localizado na mesma região que o túnel do Cloud VPN ou o anexo da VLAN que conecta sua rede local à rede VPC.

Para informações sobre como criar políticas de servidor de entrada, consulte Como criar uma política de servidor de entrada.

Política de servidor de saída

É possível alterar a ordem de resolução de nomes de VPC criando uma política de servidor de saída que especifique uma lista de servidores de nomes alternativos. Quando você especifica servidores de nomes alternativos para uma rede VPC, esses servidores são os únicos que o Google Cloud consulta ao lidar com solicitações DNS de VMs na rede VPC configuradas para usar os servidores de metadados (169.254.169.254).

Para informações sobre como criar políticas de servidor de saída, consulte Como criar uma política de servidor de saída.

Servidores de nomes alternativos e métodos de roteamento

O Cloud DNS é compatível com três tipos de servidores de nomes alternativos e oferece métodos de roteamento padrão e particular para rotear o tráfego para eles.

Servidores de nomes alternativos são definidos na tabela a seguir:

Servidor de nomes alternativo Descrição Roteamento padrão compatível Compatibilidade com roteamento privado Origem das solicitações
Tipo 1 Um endereço IP interno de uma VM do Google Cloud na mesma rede VPC em que a política do servidor de saída está definida Somente endereços IP RFC 1918: o tráfego sempre é roteado por uma rede VPC autorizada. Qualquer endereço IP interno, incluindo endereços IP privados não RFC 1918 e endereços IP públicos reutilizados de forma privada, o tráfego sempre é roteado por uma rede VPC autorizada. 35.199.192.0/19
Tipo 2 Um endereço IP de um sistema local, conectado à rede VPC com a política do servidor de saída, usando a VPN do Cloud ou o Cloud Interconnect. Somente endereços IP RFC 1918: o tráfego sempre é roteado por uma rede VPC autorizada. Qualquer endereço IP interno, incluindo endereços IP privados não RFC 1918 e endereços IP públicos reutilizados de forma privada, o tráfego sempre é roteado por uma rede VPC autorizada. 35.199.192.0/19
Tipo 3 Um endereço IP externo de um servidor de nomes de DNS acessível para a Internet ou o endereço IP externo de um recurso do Google Cloud; por exemplo, o endereço IP externo de uma VM em outra rede VPC. Somente endereços IP externos roteáveis pela Internet: o tráfego sempre é encaminhado para a Internet ou para o endereço IP externo de um recurso do Google Cloud. O roteamento particular não é compatível. Intervalos de origem do DNS público do Google

Escolha um dos seguintes métodos de roteamento ao especificar o servidor de nomes alternativo de uma política de servidor de saída:

  • Roteamento padrão: encaminha o tráfego por meio de uma rede VPC autorizada ou pela Internet, com base no fato de o servidor de nomes alternativo ser ou não um endereço IP RFC 1918. Se o servidor de nomes alternativo for um endereço IP RFC 1918, o Cloud DNS o classificará como um servidor de nomes do Tipo 1 ou Tipo 2 e encaminhará as solicitações por meio de uma rede VPC autorizada. Se o servidor de nomes alternativo não for um endereço IP RFC 1918, o Cloud DNS o classificará como Tipo 3 na expectativa de que o servidor de nomes fique acessível pela Internet.

  • Roteamento particular: sempre encaminha o tráfego por meio de uma rede VPC autorizada, independentemente do endereço IP do servidor de nomes alternativo (RFC 1918 ou não). Consequentemente, somente os servidores de nomes do Tipo 1 e Tipo 2 são compatíveis.

Para acessar um servidor de nomes alternativo do Tipo 1 ou Tipo 2, o Cloud DNS usa rotas na rede VPC autorizada, em que o cliente DNS está localizado. Essas rotas definem um caminho seguro para o servidor de nomes:

Veja mais orientações sobre os requisitos de rede para servidores de nomes do Tipo 1 e Tipo 2 nos requisitos de rede do servidor de nomes alternativo.

Controle de acesso

É possível gerenciar os usuários que têm permissão para fazer mudanças nos seus registros DNS na página IAM e Admin no Console do Google Cloud. Para que os usuários sejam autorizados a fazer alterações, eles precisam ter o papel Editor (roles/editor) ou Proprietário (roles/owner) na seção Permissões do Console do Cloud. O papel de Visualizador (roles/viewer) concede acesso somente leitura aos registros do Cloud DNS.

Essas permissões também se aplicam às contas de serviço que você pode usar para gerenciar seus serviços DNS.

Controle de acesso para zonas gerenciadas

Os usuários com os papéis de proprietário do projeto ou editor do projeto podem gerenciar ou visualizar as zonas gerenciadas nesse projeto específico.

Os usuários com os papéis administrador de DNS ou leitor de DNS (roles/dns.admin ou roles/dns.reader) podem gerenciar ou visualizar as zonas gerenciadas em todos os projetos aos que têm acesso.

Proprietários de projetos, editores, administradores de DNS e leitores de DNS podem visualizar a lista de zonas particulares aplicadas a qualquer rede VPC no projeto atual.

Desempenho e tempo

O Cloud DNS usa o Anycast para atender às suas zonas gerenciadas de diversos locais no mundo todo, garantindo alta disponibilidade. As solicitações são automaticamente encaminhadas para o local mais próximo, o que reduz a latência e melhora o desempenho das buscas de nomes autoritativos para seus usuários.

Propagação de alterações

As alterações são propagadas em dois estágios. Primeiro, a alteração enviada por meio da API ou da ferramenta de linha de comando precisa ser enviada para os servidores DNS autoritativos do Cloud DNS. Depois, os resolvedores de nomes DNS precisam usar essas alterações quando o cache dos registros expirar.

O valor de time to live (TTL) definido para seus registros, especificado em segundos, controla o cache do resolvedor de DNS. Por exemplo, se você definir um valor de TTL de 86400 (o número de segundos em 24 horas), os resolvedores de nomes DNS são instruídos a armazenar os registros em cache por 24 horas. Alguns resolvedores de nomes DNS ignoram o valor de TTL ou usam um valor próprio, que pode atrasar a propagação completa dos registros.

Se você está planejando fazer alterações em serviços que exigem uma janela restrita, convém alterar o TTL para um valor mais curto antes de fazer a alteração. Essa abordagem pode ajudar a reduzir a janela de armazenamento em cache e garantir uma alteração mais rápida para suas novas configurações de registro. Depois da alteração, retorne o valor de TTL para o valor anterior para reduzir a carga dos resolvedores de DNS.

A seguir