Visão geral das zonas de DNS

O Cloud DNS é compatível com diferentes tipos de zonas públicas e particulares. Nesta página, você verá detalhes sobre os diferentes tipos de zonas e quando é possível usar uma ou outra.

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 aceita três tipos de destinos e oferece métodos de roteamento padrão ou particular para conectividade.

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 ou um balanceador de carga de rede de passagem interno na mesma VPC rede 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, como um endereço privado RFC 1918, um endereço IP privado não RFC 1918 ou um endereço IP externo reutilizado de modo privado, exceto um endereço IP de destino de encaminhamento proibido. 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, como um endereço privado RFC 1918, um endereço IP privado não RFC 1918 ou um endereço IP externo reutilizado de modo privado, exceto um endereço IP de destino de encaminhamento proibido. 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.

Endereços IP de destino de encaminhamento proibidos

Não é possível usar os seguintes endereços IP para destinos de encaminhamento do Cloud DNS:

  • 169.254.0.0/16
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 224.0.0.0/4
  • 240.0.0.0/4
  • ::1/128
  • ::/128
  • 2001:db8::/32
  • fe80::/10
  • fec0::/10
  • ff00::/8

Ordem de seleção do destino de encaminhamento

O Cloud DNS permite configurar uma lista de destinos de encaminhamento para uma zona de encaminhamento.

Quando você configura dois ou mais destinos de encaminhamento, o Cloud DNS usa um algoritmo interno para selecionar um destino. Esse algoritmo classifica cada destino de encaminhamento.

Para processar uma solicitação, primeiro o Cloud DNS testa uma consulta DNS contatando o destino de encaminhamento com a classificação mais alta. Se esse servidor não responder, o Cloud DNS repetirá a solicitação para o próximo destino de encaminhamento melhor classificado. Se nenhum destino de encaminhamento responder, o Cloud DNS sintetizará uma resposta SERVFAIL.

O algoritmo de classificação é automático, e os seguintes fatores aumentam a classificação de um destino de encaminhamento:

  • O maior número de respostas DNS bem-sucedidas processadas pelo destino de encaminhamento. As respostas DNS bem-sucedidas incluem respostas NXDOMAIN.
  • A menor latência (tempo de retorno) para se comunicar com o destino de encaminhamento.

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.

Para informações sobre como criar zonas de encaminhamento, consulte Criar uma zona de encaminhamento.

Zonas de peering

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.

A zona de peering é visível apenas para redes VPC selecionadas durante a configuração da zona. 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 instruções sobre como criar uma zona de peering, consulte Criar uma zona de peering.

Zonas de pesquisa reversa gerenciadas

Uma zona de pesquisa reversa gerenciada é uma zona particular com um atributo especial que instrui o Cloud DNS a realizar pesquisas de PTR em dados de DNS do Compute Engine.

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 nomes.

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.

Para instruções sobre como criar uma zona de pesquisa reversa gerenciada, consulte Criar uma zona de pesquisa reversa gerenciada.

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 nomes. 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 do myapp.example.com. (observe o ponto final), porque não há uma zona particular para example.com que tenha sido autorizada na rede VPC. Use dig de uma VM do Compute Engine para consultar o servidor de nomes padrão da VM:

    dig myapp.example.com.

    Para detalhes, veja Consultar o nome DNS usando o servidor de metadados.

  • 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
myrecord1.gcp.example.com A 5 10.128.1.35

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

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

As consultas a seguir são determinadas conforme descrito:

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

Vinculação entre projetos

A vinculação entre projetos permite manter a propriedade do namespace de DNS do projeto de serviço, independentemente da propriedade do namespace de DNS de toda a rede VPC.

Uma configuração típica de VPC compartilhada tem projetos de serviço que assumem a propriedade de um aplicativo de máquina virtual (VM), enquanto o projeto host é proprietário da rede VPC e da infraestrutura da rede. Muitas vezes, um namespace DNS é criado no namespace da rede VPC para corresponder aos recursos do projeto de serviço. Para essa configuração, pode ser mais fácil delegar a administração do namespace DNS de cada projeto de serviço para os administradores de cada projeto de serviço (que geralmente são departamentos ou empresas diferentes). A vinculação entre projetos permite separar a propriedade do namespace DNS do projeto de serviço da propriedade do namespace DNS de toda a rede VPC.

A figura a seguir mostra uma configuração típica de VPC compartilhada com peering de DNS.

Uma configuração de VPC compartilhada com peering de DNS.
Uma configuração de VPC compartilhada com peering de DNS (clique para ampliar)

Na figura a seguir, mostramos uma configuração usando a vinculação entre projetos. O Cloud DNS permite que cada projeto de serviço crie e seja proprietário das zonas DNS, mas ainda o vincule à rede compartilhada que é a proprietária do projeto host. Isso proporciona uma melhor autonomia e um limite de permissão mais preciso para a administração da zona de DNS.

Uma configuração com vinculação entre projetos.
Configuração com vinculação entre projetos (clique para ampliar)

A vinculação entre projetos oferece o seguinte:

  • Administradores e usuários de projetos de serviço podem criar e gerenciar zonas próprias de DNS.
  • Não é necessário criar uma rede VPC de marcador de posição.
  • Os administradores do projeto host não precisam gerenciar o projeto de serviço.
  • Os papéis do IAM ainda se aplicam no nível do projeto.
  • Todas as zonas do DNS estão diretamente associadas à rede VPC compartilhada.
  • A resolução de DNS em qualquer ambiente está prontamente disponível. Qualquer VM na rede VPC compartilhada pode resolver zonas associadas.
  • Não há limite de salto transitivo. Você pode gerenciá-lo em um design hub e spoke.

Para ver instruções sobre como criar uma zona com esse recurso ativado, consulte Criar uma zona de vinculação entre projetos.

Zonas zonais do Cloud DNS

O Cloud DNS zonal permite criar zonas DNS particulares com escopo apenas para uma zona do Google Cloud. As zonas zonais do Cloud DNS são criadas para o GKE quando você escolhe um escopo de cluster.

O serviço padrão do Cloud DNS é global por natureza, e os nomes DNS são visíveis globalmente em sua rede VPC. Essa configuração expõe seu serviço a interrupções globais. O Cloud DNS zonal é um novo serviço particular do Cloud DNS que existe em cada zona do Google Cloud. O domínio de falha está contido nessa zona do Google Cloud. As zonas particulares zonais do Cloud DNS não são afetadas quando ocorrem interrupções globais. Qualquer interrupção zonal do Google Cloud afeta apenas essa zona específica e as zonas do Cloud DNS nessa zona. Qualquer recurso criado em um serviço zonal só é visível para essa zona do Google Cloud.

Para saber como configurar uma zona com escopo de cluster do Cloud DNS, consulte Configurar uma zona com escopo de cluster do GKE.

Suporte zonal do Cloud DNS

A tabela a seguir lista os recursos do Cloud DNS que são compatíveis com os serviços zonais do Cloud DNS.

Recurso ou funcionalidade Disponível no Cloud DNS global Disponível no Cloud DNS por zona
Zonas públicas gerenciadas
Zonas particulares gerenciadas (com escopo de rede ou VPC)
Zonas particulares gerenciadas (escopo do GKE)
Zonas de encaminhamento1
Zonas de peering
Zonas de pesquisa reversa gerenciadas
Crie alterações ou gerencie registros2
Zonas do Diretório de serviços
Políticas
Políticas de resposta (escopo da rede)
Políticas de resposta (escopo do cluster do GKE)
Regras da política de resposta

1O Cloud DNS por zona é compatível apenas com zonas de encaminhamento no escopo de um cluster do GKE.

2O controlador do GKE substitui todas as alterações nos registros quando é reiniciado.

Faturamento para zonas zonais do Cloud DNS

O faturamento para zonas zonais e políticas de resposta do Cloud DNS funciona da mesma maneira que as contrapartes globais.

A seguir