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:
|
É 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 |
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:
Para enviar tráfego para os destinos do Tipo 1, o Cloud DNS usa rotas de sub-rede criadas automaticamente. Para responder, as segmentações de tipo 1 usam uma rota de retorno especial para respostas do Cloud DNS.
Para enviar tráfego para os destinos do Tipo 2, o Cloud DNS pode usar rotas dinâmicas personalizadas ou rotas estáticas personalizadas, exceto para rotas estáticas personalizadas com tags de rede. Para responder, os destinos de encaminhamento do Tipo 2 usam rotas na sua rede local.
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
avpc-net-b
. Você configurouvpc-net-a
para exportar rotas personalizadas evpc-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ê autorizouvpc-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:
- Crie uma zona de peering do Cloud DNS autorizada para
vpc-net-b
que tenha como destinovpc-net-a
. - 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 destinovpc-net-b
e, em seguida, criar uma zona de peering emvpc-net-b
que tenha como destinovpc-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 paragcp.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 paragcp.example.com
se sobrepõem porquedev.gcp.example.com
é um subdomínio degcp.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 zonagcp.example.com
. As consultas paradatabase.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 paraexample.com
que tenha sido autorizada para a rede VPC.O servidor de metadados resolve o registro
myapp.gcp.example.com
usando a zona particular autorizadagcp.example.com
, porquegcp.example.com
é o maior sufixo comum entre o nome do registro solicitado e as zonas particulares autorizadas disponíveis. Se não houver registro paramyapp.gcp.example.com
definido na zona particulargcp.example.com
, a resposta seráNXDOMAIN
, mesmo se houver um registro paramyapp.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 autorizadadev.gcp.example.com
. Se não houver registro paramyapp.dev.gcp.example.com
na zonadev.gcp.example.com
, a resposta seráNXDOMAIN
, mesmo se houver um registro paramyapp.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 particulargcp.example.com
, porquegcp.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 retorna10.128.1.35
. - Uma consulta para
foo.gcp.example.com
feita na Internet retorna104.198.6.142
. - Uma consulta para
bar.gcp.example.com
de uma VM na sua rede VPC retorna um erroNXDOMAIN
, porque não há registro debar.gcp.example.com
na zona particulargcp.example.com
. - Uma consulta para
bar.gcp.example.com
feita na Internet retorna104.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:
O Cloud DNS usa rotas de sub-rede criadas automaticamente para enviar tráfego aos servidores de nomes alternativos do Tipo 1. Os servidores de nomes do tipo 1 usam uma rota de retorno especial para respostas do Cloud DNS para responder.
O Cloud DNS pode usar rotas dinâmicas personalizadas ou rotas estáticas personalizadas, exceto para rotas estáticas personalizadas com tags de rede, para enviar tráfego aos servidores de nomes alternativos do Tipo 2. Os servidores de nomes tipo 2 usam rotas na rede local para responder.
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
- Para começar a usar o Cloud DNS, consulte o Início rápido.
- Para registrar e configurar seu domínio, consulte o tutorial Como configurar um domínio usando o Cloud DNS.
- Para saber mais sobre as bibliotecas de clientes da API, consulte Amostras e bibliotecas.
- Para achar soluções de problemas comuns que podem ser encontrados ao usar o Cloud DNS, consulte Solução de problemas.