Visão geral

Nesta página, você encontra uma visão geral dos recursos e das funcionalidades do Cloud DNS. Para dar os primeiros passos com o Cloud DNS, consulte o guia de início rápido.

Introdução

O Cloud DNS é um serviço de Sistema de Nome de Domínio (DNS, na sigla em inglês) global, resiliente e de alto desempenho. Com ele, você publica nomes de domínio no DNS global com economia.

Conceitos

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.

Consulte a página Visão geral do DNS para ver a lista de terminologia.

O Cloud DNS disponibiliza zonas de DNS gerenciadas públicas e privadas. 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 VPC especificadas.

Com as zonas particulares, você tem a opção de definir configurações de DNS split horizon. Isso é possível porque essas zonas podem ser criadas com um conjunto diferente de registros DNS específicos para sua rede VPC.

Conceitos do Cloud DNS

A Cloud DNS API foi criada com base em projetos, zonas gerenciadas, conjuntos de registros e alterações feitas nesses conjuntos.

Projeto

Um projeto no Console do Google Cloud é um contêiner de recursos, um domínio para o controle de acesso e o lugar onde o faturamento é configurado e agregado. Cada recurso do Cloud DNS está em um projeto, e é necessário que cada operação desse produto especifique o projeto em que ela atua.

Zonas gerenciadas

A zona gerenciada mantém os registros DNS com o mesmo sufixo do nome de DNS (example.com, por exemplo). Um projeto pode ter várias zonas gerenciadas, mas cada uma precisa ter um nome exclusivo. No Cloud DNS, a zona gerenciada é o recurso que molda uma zona de DNS (em inglês). Todos os registros de uma zona gerenciada são hospedados pelos mesmos servidores de nome operados pelo Google. Esses servidores de nomes respondem a consultas de DNS com relação à sua zona gerenciada de acordo com o modo como você a configurou. Um projeto pode conter diversas zonas gerenciadas. As cobranças são acumuladas por zona, considerando cada dia de existência da zona gerenciada. As zonas gerenciadas são compatíveis com rótulos (em inglês), o que ajuda a organizar o faturamento. O artigo Como gerenciar zonas explica como gerenciar os registros dentro das zonas.

Zonas públicas

Uma zona pública é visível para a Internet. O Cloud DNS tem servidores de nome públicos autoritativos que respondem a consultas sobre zonas públicas, seja qual for o local de origem dessas consultas. É possível criar registros DNS em uma zona pública para publicar o serviço na Internet. Por exemplo, é possível criar o registro a seguir em uma zona pública example.com para seu site público www.example.com.

Nome do DNS	Tipo	TTL (segundos)	Dados
www.example.com	A	300	[public_ip_address]

O Cloud DNS atribui um conjunto de servidores de nomes quando uma zona pública é criada. Para que os registros DNS em uma zona pública sejam resolvidos pela Internet, é preciso atualizar a configuração do servidor de nomes do registro do seu domínio no registrador.

Zonas particulares

Com as zonas particulares, é possível gerenciar nomes de domínio personalizados para máquinas virtuais, balanceadores de carga e outros recursos do Google Cloud, sem expor os dados DNS subjacentes à Internet pública. Uma zona particular é um contêiner de registros DNS que só pode ser consultado por uma ou mais redes VPC autorizadas por você.

As zonas desse tipo só podem ser consultadas por recursos no mesmo projeto em que estão definidas. As redes VPC que você autorizar precisam estar localizadas no mesmo projeto onde a zona particular está. Para substituir essa restrição, configure o peering de DNS com outra rede.

Ao criar ou autorizar a zona particular, você especifica a lista de redes VPC autorizadas que podem consultá-la. Somente redes autorizadas podem consultar a zona particular. Não será possível consultar essa zona se você não especificar nenhuma rede autorizada.

É possível usar zonas particulares com a VPC compartilhada. Para mais informações importantes sobre o uso dessas zonas com redes VPC compartilhadas, consulte a seção correspondente nesta página.

As zonas particulares não são compatíveis com extensões de segurança de DNS (DNSSEC, na sigla em inglês) ou conjuntos de registros de recurso personalizados do tipo NS.

As solicitações de registros DNS em zonas particulares precisam ser enviadas por meio do servidor de metadados 169.254.169.254, que é o servidor de nomes interno padrão das VMs criadas a partir de imagens do Google. É possível enviar consultas para esse servidor a partir de qualquer VM que utilize uma rede VPC autorizada.

Por exemplo, é possível criar uma zona particular para dev.gcp.example.com com o objetivo de hospedar registros DNS internos para aplicativos experimentais. Veja na tabela a seguir alguns exemplos de registros na zona. Os clientes de banco de dados podem se conectar ao servidor de banco de dados db-01.dev.gcp.example.com usando o nome de DNS interno dele, em vez do endereço IP. Esses clientes resolvem o nome de DNS interno usando o resolvedor de host na VM, que envia a consulta DNS ao servidor de metadados 169.254.169.254. Tal servidor de metadados atua como um resolvedor recursivo para consultar a zona particular.

Nome do DNS	Tipo	TTL (segundos)	Dados
db-01.dev.gcp.example.com	A	5	10.128.1.35
instance-01.dev.gcp.example.com	A	50	10.128.1.10

Zonas de encaminhamento

Trata-se de um tipo de zona particular gerenciada do Cloud DNS que envia solicitações recebidas por ela para os endereços IP dos destinos de encaminhamento. Consulte Encaminhamento de DNS para mais informações.

Zonas de peering

Trata-se de um tipo de zona particular gerenciada do Cloud DNS que segue a ordem de resolução de nomes de outra rede VPC e pode ser usada para resolver os nomes definidos nessa outra rede.

Operações de zona

Todas as mudanças feitas nas zonas gerenciadas no Cloud DNS são registradas no conjunto de operações, que lista as atualizações em tais zonas, como modificações em descrições, no estado das DNSSEC ou na configuração.

Registrador

Um registrador de nomes de domínio (em inglês) é uma organização que gerencia a reserva de nomes de domínio da Internet. Um registrador precisa ser credenciado por um registro de domínio de nível mais alto genérico (gTLD, na sigla em inglês) ou um registro de domínio de nível mais alto com código de país (ccTLD, na sigla em inglês).

DNS interno

O Google Cloud cria automaticamente nomes de DNS interno para VMs, mesmo quando você não usa o Cloud DNS. Para mais informações, consulte a documentação sobre DNS interno.

Subzonas delegadas

O DNS permite que o proprietário de uma zona delegue um subdomínio a um outro servidor de nomes usando registros NS. Os resolvedores seguem esses registros e enviam consultas no subdomínio para o servidor de nomes de destino especificado na delegação.

Observação: as zonas particulares não são compatíveis com a delegação de subdomínios para servidores de nomes diferentes que usam registros NS.

Coleção de conjuntos de registros de recurso

A coleção de conjuntos de registros de recurso armazena o estado atual dos registros DNS que formam uma zona gerenciada. É possível ler essa coleção, mas não modificá-la diretamente. Em vez disso, edite-os criando uma solicitação Change na coleção de mudanças. A coleção de conjuntos de registros de recurso refletirá todas as suas mudanças imediatamente. No entanto, há um atraso entre o momento em que as alterações são feitas na API e o momento em que elas entram em vigor nos seus servidores DNS autoritativos. Consulte Como gerenciar registros para mais detalhes.

Mudanças nos registros de recurso

Para fazer mudanças na coleção de conjuntos de registros de recurso, envie uma solicitação Change que contenha o que será incluído ou excluído. Essas inclusões e exclusões podem ser feitas em massa ou em uma única transação atômica. Elas surtirão efeito simultaneamente em todos os servidores DNS autoritativos.

Por exemplo, se você tiver um registro A como o abaixo:

www  A  203.0.113.1 203.0.113.2

E executar um comando como este:

DEL  www  A  203.0.113.2
ADD  www  A  203.0.113.3

Seu registro ficará como o abaixo após a mudança em massa:

www  A  203.0.113.1 203.0.113.3

ADD e DEL ocorrem simultaneamente.

Formato do número de série SOA

Os números de série de registros SOA criados em zonas gerenciadas do Cloud DNS aumentam conforme uma função monótona a cada mudança transacional nos conjuntos de registros de uma zona usando o comando gcloud dns record-sets transaction. É possível mudar manualmente o número de série de um registro SOA para um número arbitrário. No entanto, inclua uma data no formato ISO 8601, como recomendado na RFC 1912. Por exemplo, no registro SOA a seguir:

ns-gcp-private.googledomains.com. cloud-dns-hostmaster.google.com. [serial number] 21600 3600 259200 300

É possível mudar o número de série diretamente no Console do Google Cloud, bastando inserir o valor desejado no terceiro campo delimitado por espaços do registro.

Política de servidor DNS

Com uma política de servidor DNS, você tem acesso aos serviços de resolução de nomes fornecidos pelo Google Cloud em uma rede VPC com encaminhamento de entrada. Além disso, é possível mudar a ordem da resolução de nomes de VPC com o encaminhamento de saída.

Domínios, subdomínios e delegação

Subdomínios são, na maior parte, apenas registros na zona gerenciada do domínio pai. Os subdomínios que são delegados pela criação de registros de servidor de nomes (NS, na sigla em inglês) na zona do domínio pai também precisam ter as próprias zonas. Crie zonas gerenciadas para domínios pai no Cloud DNS antes de criar qualquer zona para os subdomínios delegados. Faça isso mesmo se você hospedar o domínio pai em outro serviço DNS. Se você tem várias zonas de subdomínio, mas não criou a zona pai, talvez seja complicado criá-la quando quiser transferi-la para o Cloud DNS.

DNSSEC

As extensões de segurança do Sistema de Nome de Domínio (DNSSEC, na sigla em inglês) são um conjunto de extensões da Internet Engineering Task Force (IETF) para o DNS, que autenticam respostas a pesquisas de nomes de domínio. Elas não fornecem proteções de privacidade para as pesquisas, mas impedem que invasores manipulem as respostas a solicitações de DNS.

Coleção de DNSKEYs

A coleção de DNSKEYs contém o estado atual dos registros DNSKEY usados para assinar uma zona gerenciada habilitada para DNSSEC. Só é possível ler essa coleção. Todas as mudanças nas DNSKEYs são feitas pelo Cloud DNS. A coleção de DNSKEYs tem todas as informações que os registradores de domínio exigem para ativar o protocolo de segurança DNSSEC.

Ordem da resolução de nomes VPC

Cada rede VPC fornece serviços de resolução de nomes de DNS para as instâncias de VM que a utilizam. Quando as VMs usam o próprio servidor de metadados, 169.254.169.254, como servidor de nomes, o Google Cloud pesquisa registros DNS na seguinte ordem:

1. Se uma política de DNS que especifica um servidor de nomes alternativo para encaminhamento de saída tiver sido configurada para a rede VPC, o Google Cloud encaminhará todas as consultas DNS apenas para esse servidor. Consulte a seção sobre encaminhamento de DNS de saída usando um servidor de nomes alternativo para mais detalhes.
2. O Google Cloud consulta os serviços de resolução de nomes a seguir, em ordem, usando a correspondência com base no sufixo mais longo:
   • O Google Cloud consulta todas as zonas particulares de encaminhamento gerenciadas do Cloud DNS que foram autorizadas para a rede VPC, enviando solicitações para os endereços IP dos destinos de encaminhamento.
   • O Google Cloud consulta todas as zonas particulares gerenciadas do Cloud DNS que foram autorizadas para a rede VPC em busca dos registros nessas zonas. Isso inclui zonas de peering.
   • O Google Cloud pesquisa os registros do DNS interno do Compute Engine criados automaticamente para o projeto.
3. O Google Cloud consulta as zonas disponíveis publicamente, seguindo o início da zona de autoridade (SOA, na sigla em inglês) configurado corretamente. Isso inclui zonas públicas do Cloud DNS.

Registros PTR em zonas particulares

Registros PTR para endereços RFC 1918

Como consequência da correspondência com base no prefixo mais longo, descrita na seção sobre ordem de resolução de nomes de VPC, para realizar pesquisas inversas com registros PTR personalizados para endereços RFC 1918 (em inglês), é necessário criar uma zona particular do Cloud DNS que seja pelo menos tão específica quanto uma das seguintes:

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

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

Por exemplo, imagine que você criou uma zona particular gerenciada para in-addr.arpa. com o seguinte registro PTR para uma instância de 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 do Compute Engine mais específica de 10.in-addr.arpa.. O registro PTR na zona particular do Cloud DNS para test.example.domain é ignorado.

Para modificar os registros PTR do DNS interno do Compute Engine 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

Também é possível criar zonas particulares inversas do Cloud DNS mais específicas, caso você precise substituir apenas uma parte de um bloco de rede. Por exemplo, uma zona particular para 5.10.in-addr.arpa. pode ser usada para manter os registros PTR que modificam todos aqueles do DNS interno do Compute Engine que foram criados automaticamente para as VMs com endereços IP no intervalo de endereços 10.5.0.0/16.

Registros PTR para endereços não RFC 1918

Os registros PTR para endereços não RFC 1918 não entram em conflito com os registros PTR DNS internos do Compute Engine criados automaticamente.

Devido à ordem de resolução de nomes de VPC, as zonas particulares são consultadas antes das zonas disponíveis publicamente na Internet.

Por exemplo, suponha que, na Internet pública, a consulta PTR IN 2.2.0.192.in-addr.arpa retorne example.com, mas você queira modificar essa resposta com instâncias de VM em uma ou mais de suas redes VPC. Para fazer isso, crie uma zona particular com o nome de DNS in-addr.arpa e inclua o seguinte registro PTR nela:

2.2.0.192.in-addr.arpa -> test.com

Quando as VMs que residem nas redes VPC autorizadas fizerem essa consulta de zona particular para PTR IN 2.2.0.192.in-addr.arpa, elas receberão a resposta test.com, em vez de example.com.

Registros PTR em zonas públicas

Para consultar endereços não RFC 1918 em uma zona pública do Cloud DNS, delegue a parte do espaço in-addr.arpa delegado na raiz do seu bloco de IPs aos servidores de nomes do Cloud DNS.

Para mais informações sobre a configuração do DNS reverso em geral, acesse este link (em inglês). No entanto, observe que as etapas exatas para configurar o DNS reverso variam de acordo com o operador de registros (em inglês).

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 (busca de CNAME). Consulte o guia de solução de problemas para mais detalhes.
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 esse registro conforme necessário. Por exemplo, mudar o número de série para um valor arbitrário a fim de ser compatível com o controle de versões 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, protocolos de mensagem instantânea e outros aplicativos.
SSHFP	Impressão digital para clientes SSH com a função de validar as chaves públicas de servidores SSH.
TLSA	Registro de autenticação para clientes TLS com a função de 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. Por exemplo: "Hello world" "Bye world"

Consulte Como gerenciar registros para saber como trabalhar com registros DNS.

Registros DNS curinga

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

DNSSEC

O Cloud DNS aceita DNSSEC gerenciada, 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.

Você pode ativar o DNSSEC para uma zona gerenciada com este comando:

gcloud dns managed-zones update my-zone --dnssec-state on

Também é possível ativar o DNSSEC para zonas recém-criadas:

gcloud dns managed-zones create my-zone \
    --description "Signed Zone" --dns-name myzone.example --dnssec-state=on

É possível especificar também uma série de parâmetros de DNSSEC, se as configurações padrão não forem apropriadas para sua implantação.

Encaminhamento de DNS

É possível configurar o encaminhamento de DNS entre os servidores de nomes internos do Google Cloud e os que pertencem a terceiros. Quando você define o encaminhamento bidirecional, as instâncias na sua rede VPC podem pesquisar endereços de hosts em redes locais ou de várias nuvens. Além disso, os hosts nas redes vinculadas podem procurar endereços de recursos na sua rede VPC.

O Google Cloud é compatível com o encaminhamento de DNS das seguintes maneiras:

• As redes VPC são compatíveis com o encaminhamento de DNS de entrada e saída com o uso de políticas de servidor DNS. As solicitações de entrada precisam ser provenientes dos sistemas nas redes conectadas ao VPC pelo Cloud Interconnect ou túnel do Cloud VPN, como um data center local.

• As zonas particulares gerenciadas do Cloud DNS são compatíveis com o encaminhamento de DNS de saída por meio de zonas de encaminhamento.

Observação: as zonas públicas gerenciadas do Cloud DNS não são compatíveis com o encaminhamento. Elas são apenas zonas autoritativas.

O exemplo a seguir ilustra duas redes VPC, prod e dev, em que o encaminhamento de DNS foi configurado:

Encaminhamento de DNS com servidores DNS locais (clique para ampliar)

• A rede dev está conectada a um data center local na Europa com um túnel do Cloud VPN usando roteamento dinâmico.
• A rede prod está conectada a data centers locais na Ásia, na Europa e nos EUA com túneis do Cloud VPN usando roteamento dinâmico.
• Todas as redes foram configuradas para usar o roteamento dinâmico global.
• Todos os três data centers estão conectados uns aos outros. Os endereços IP usados por cada rede VPC e local são RFC 1918 e não se sobrepõem.
• Os servidores BIND locais estão localizados em cada data center local. Esses servidores de nomes são configurados com redundância para exibir a zona corp.example.com.
• Você criou políticas de DNS para as redes dev e prod do Cloud VPN para possibilitar o encaminhamento de saída aos servidores de nomes locais.
• As VMs no Google Cloud usam o próprio servidor de metadados, 169.254.169.254, para resolver o DNS interno do Google Cloud, todas as zonas particulares autorizadas do Cloud DNS das respectivas redes dev ou prod, as zonas de DNS públicas e a zona corp.example.com local.

Limitações do encaminhamento de DNS

Não é possível atingir os destinos de uma zona de encaminhamento de maneira intermediária por meio do peering de rede VPC.

Imagine a seguinte configuração: seu ambiente local é conectado a duas redes VPC, vpc-net-a e vpc-net-b, por meio de túneis do Cloud VPN ou usando o Cloud Interconnect. As duas redes VPC são conectadas usando o peering de rede VPC e estão configuradas para trocar rotas personalizadas. Se você criar uma zona de encaminhamento em vpc-net-b com destinos na rede local, o encaminhamento de DNS não funcionará. Se quiser verificar isso, faça o seguinte teste:

• Consulte o servidor de metadados 169.254.169.254 em busca de um registro definido na zona de encaminhamento. Essa consulta falhará.
• Consulte o destino do encaminhamento diretamente em busca do mesmo registro. Essa consulta será bem-sucedida.

A solução é criar uma zona de peering do Cloud DNS em vpc-net-b que tenha como destino vpc-net-a e uma zona de encaminhamento em vpc-net-a que tenha como destino os servidores de nomes locais. Você tem a opção de conectar vpc-net-a e vpc-net-b ao ambiente local por meio de anexos ou túneis. No entanto, escolha apenas uma das redes para encaminhar consultas ao ambiente local. A outra rede precisa estar pareada por DNS à rede VPC designada para fazer o encaminhamento ao ambiente local.

Política de servidor DNS

Com a política de servidor DNS, é possível configurar o encaminhamento de DNS de entrada e saída em uma rede VPC. Essa política pode ser aplicada a uma determinada rede VPC.

Consulte Como usar políticas de servidor DNS para instruções detalhadas.

Encaminhamento de DNS de entrada

Cada rede VPC fornece serviços de resolução de nomes de DNS para as instâncias de VM que a utilizam. Quando as VMs usam o próprio servidor de metadados, 169.254.169.254, como servidor de nomes, o Google Cloud pesquisa registros DNS de acordo com a ordem de resolução de nomes da VPC.

Por padrão, os serviços de resolução de nomes da rede VPC não estão disponíveis fora dessa rede. É possível disponibilizá-los para sistemas em redes locais conectadas pelo Cloud VPN ou Cloud Interconnect. Basta criar uma política de DNS para ativar o encaminhamento de DNS de entrada para a rede VPC. Quando ativado, os sistemas nas redes conectadas podem consultar um endereço IP interno na rede VPC para usar os serviços de resolução de nomes.

Para configurar uma política que permita o encaminhamento de DNS de entrada à rede VPC, consulte estas informações. Quando configurado, o Google Cloud aloca um endereço IP interno em uma sub-rede (em uma região) da sua rede VPC para servir como um proxy para solicitações DNS de entrada. É possível especificar uma região ou deixar que o Google Cloud escolha automaticamente. Cada política de encaminhamento de DNS de entrada aloca um único endereço IP de proxy para solicitações desse tipo. No entanto, esse único endereço IP serve apenas como ponto de entrada para os serviços de resolução de nomes da rede VPC. Depois, configure os servidores de nomes locais para realizar encaminhamentos ao endereço de proxy conforme necessário.

Importante: as políticas de DNS para solicitações de entrada não são compatíveis com redes legadas. Elas são compatíveis apenas com redes VPC.

Ordem de resolução de nomes da rede VPC usando um servidor de nomes alternativo

É possível mudar a ordem de resolução de nomes VPC ao criar uma política de DNS que especifique uma lista de servidores de nomes alternativos. Ao fazer isso, os servidores de nomes alternativos se tornam a única origem consultada pelo Google Cloud para todas as solicitações de DNS enviadas pelas VMs na VPC por meio do servidor de metadados 169.254.169.254.

Consulte Como criar uma política de DNS que permita um servidor de nomes alternativo para saber como definir uma política de DNS para o encaminhamento de saída. Se você especificar servidores de nomes alternativos usando endereços IP RFC 1918, eles precisarão ser endereços IP internos de outras VMs do Google Cloud na sua rede VPC ou sistemas na sua rede local conectada à rede VPC por meio do Cloud VPN ou do Cloud Interconnect. Por outro lado, se você usar endereços IP públicos para especificar esses servidores, eles precisarão ser acessíveis na Internet.

Importante: uma política de DNS que ativa o encaminhamento de saída desativa a resolução das zonas particulares gerenciadas do Cloud DNS e do DNS interno do Compute Engine.

Encaminhamento de DNS de saída para um endereço IP não RFC 1918

Beta

Esta é uma versão Beta do encaminhamento de DNS para endereços não RFC 1918. Ela não é coberta por SLAs ou políticas de suspensão de uso e está sujeita a alterações incompatíveis com versões anteriores.

Por padrão, o encaminhamento de DNS envia consultas para destinos por meio de um caminho privado ou público. O caminho privado usa as redes do Google Cloud, enquanto o caminho público passa pela Internet. Não é possível configurar o caminho que de fato será utilizado. O Cloud DNS seleciona automaticamente esse caminho com base no intervalo de endereços IP de destino do encaminhamento. Se o destino for um endereço RFC 1918, a consulta será enviada por uma rede privada. Mas se for um endereço não RFC 1918, ela será enviada pela Internet.

O Cloud DNS permite forçar um caminho de consulta privado para qualquer endereço IP. Para fazer isso, crie ou atualize uma zona de encaminhamento com um ou mais destinos privados.

Zonas de encaminhamento de DNS

Além de um servidor de nomes alternativo, outra forma de encaminhamento de DNS de saída está disponível por meio da definição de uma zona de encaminhamento. Isso tem configuração semelhante a uma zona particular porque está associado a um nome DNS e pode ser vinculado a várias redes. No entanto, a zona de encaminhamento não contém registros. Todas as consultas correspondentes de uma zona de encaminhamento são enviadas a um conjunto de servidores DNS de destino. Como é o caso com o servidor de nomes alternativo, o destino é uma lista de endereços IP.

O sistema tenta resolver o nome usando todos os servidores de nomes de destino. No exemplo acima, as consultas correspondentes são encaminhadas para todos ou um subconjunto dos destinos 172.16.1.28, 172.16.4.34 e 172.16.8.50. O sistema pode alterar a estratégia de resolução de acordo com a capacidade de resposta do servidor e as mudanças nas condições da rede.

Quando as condições de encaminhamento de várias zonas se sobrepõem, a zona com a maior correspondência em uma consulta supera as outras. Por exemplo, vamos supor que um servidor DNS contenha três zonas de encaminhamento:

• Zona de encaminhamento 1: onprem.example.com, destino: 172.16.8.40
• Zona de encaminhamento 2: dev.onprem.example.com, destino: 172.16.8.50
• Zona de encaminhamento 3: prod.onprem.example.com, destino: 172.16.8.60

Uma consulta para mysvc.onprem.example.com é encaminhada a 172.16.8.40 de acordo com a zona 1. Uma consulta para mysvc.dev.onprem.example.com é encaminhada a 172.16.8.50 de acordo com a zona 2. Por fim, uma consulta para mysvc.prod.onprem.example.com é encaminhada a 172.16.8.60 de acordo com a zona 3.

Consulte Como criar zonas de encaminhamento para mais instruções.

Observação: o Cloud DNS armazena em cache os resultados das consultas de saída encaminhadas por até 60 segundos ou pela duração dos TTLs dos registros (o que for menor), desde que os servidores de nomes de destino estejam acessíveis. Se eles ficarem inacessíveis, os resultados dessas consultas serão armazenados em cache pelo período do TTL. Isso se aplica tanto às consultas encaminhadas por meio de zonas de encaminhamento quanto àquelas encaminhadas para servidores de nomes alternativos por meio de políticas de servidor DNS.

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.

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

Uma vez autorizados, os recursos do Google Cloud na rede consumidora de DNS podem realizar pesquisas de registros no namespace da zona de peering, como se estivessem na rede produtora de DNS. Essas pesquisas seguem a ordem de resolução de nomes da rede produtora de DNS. Assim, 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 produtora 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 DNS de saída tiver sido configurada na rede produtora de DNS

Limitações do peering de DNS

Tenha em mente os seguintes pontos 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 do Google Cloud.
• O peering de DNS e o peering de rede VPC são serviços diferentes. O primeiro pode ser usado em conjunto com o peering de rede VPC, mas este não é obrigatório.
• O encaminhamento de DNS não funciona por meio do peering de rede VPC.
• Somente redes com peering direto podem se comunicar. O peering intermediário não é aceito.

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

Casos de uso

Exemplo de SaaS

Um provedor de SaaS (produtor) quer conceder ao cliente SaaS (consumidor) acesso a um serviço hospedado em uma rede com peering. O produtor cria uma rede que hospeda o serviço e, em seguida, faz peering com a rede do consumidor. O produtor também quer fornecer os nomes do DNS que os consumidores usam para acessar o serviço.

O consumidor pode conceder ao produtor o uso de uma conta de serviço para a criação uma zona de peering na rede consumidora. O produtor também concede a essa conta de serviço o papel dns.peer na própria rede. Assim, as solicitações provenientes da zona de peering podem alcançar a zona de resolução. Como alternativa, o produtor pode instruir o consumidor sobre como definir a configuração correta.

Configuração intraorganizacional

É possível que uma zona privada gerenciada do Cloud DNS seja autorizada para uso por várias redes VPC no mesmo projeto. No entanto, talvez seja necessário compartilhar uma zona DNS entre vários projetos em sua organização.

É possível usar o peering de DNS para atender a essa necessidade: crie uma única zona privada gerenciada autorizada para uma rede de produtor. Em seguida, crie um número suficiente de zonas de peering para o mesmo namespace autorizado para cada uma das redes consumidoras nos diferentes projetos. Configure cada zona de peering para usar a mesma rede produtora. Assim, os recursos do Google Cloud nas redes consumidoras seguirão a ordem de resolução de nomes da rede produtora. Isso permite que eles resolvam registros no namespace de qualquer zona particular gerenciada autorizada para a rede produtora.

O que aprender a seguir sobre zonas de peering

Acesse Como configurar zonas de peering para mais instruções.

Zonas particulares e VPC compartilhada

Para usar zonas particulares com uma VPC compartilhada, crie sua zona particular no projeto host e inclua a rede VPC compartilhada apropriada na lista de redes autorizadas para essa zona.

Zonas sobrepostas

Um projeto pode ter várias zonas gerenciadas 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. Por exemplo, dev.gcp.example.com e gcp.example.com são 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, a criação de zonas sobrepostas falhará.

A sobreposição entre zonas públicas e privadas é permitida.

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 na zona gcp.example.com. As consultas para database.gcp.example.com receberão respostas diferentes de acordo com os registros de zona definidos para as respectivas redes VPC. Para mais informações, consulte DNS split horizon.

Resolução de consultas com zonas sobrepostas

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 maior sufixo para determinar qual origem será consultada em busca de registros em uma determinada zona.

Veja nos exemplos abaixo a ordem que o servidor de metadados usa ao consultar registros DNS. Em cada um desses exemplos, imagine 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. Então, o Google Cloud processa as consultas DNS provenientes das VMs na rede VPC:

• O servidor de metadados usa servidores de nomes públicos para resolver myapp.example.com porque não há uma zona particular para example.com.
• O servidor de metadados resolve myapp.gcp.example.com usando a zona particular gcp.example.com, porque gcp.example.com é o sufixo comum mais longo entre o registro DNS solicitado e as zonas particulares disponíveis. A resposta NXDOMAIN será retornada se não houver um registro para myapp.gcp.example.com definido na zona particular gcp.example.com, mesmo que exista um registro para myapp.gcp.example.com definido em um servidor de nomes público.
• Da mesma forma, as consultas para myapp.dev.gcp.example.com serão resolvidas de acordo com os registros na zona particular dev.gcp.example.com. A resposta NXDOMAIN será retornada se não houver um registro para myapp.dev.gcp.example.com na zona dev.gcp.example.com, mesmo que exista 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 sufixo comum mais longo entre o registro DNS solicitado e as zonas particulares disponíveis.

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 ao mesmo registro quando ela é proveniente de uma VM dentro de uma VPC autorizada. O DNS split horizon será útil se você tiver redes VPC separadas para desenvolvimento, negócios e produção:

• Defina uma zona particular e autorize o acesso a partir de uma rede VPC de desenvolvimento. Assim, as consultas provenientes das VMs nessa rede em busca de registros DNS na zona serão direcionadas para outras VMs na mesma rede.
• Defina uma segunda zona particular que atenda aos mesmos registros DNS (nomes) com respostas diferentes, autorizando o acesso de uma rede de negócios.
• Defina uma terceira zona pública que exiba os mesmos registros DNS com respostas públicas adequadas para a produção.

Por exemplo, imagine que você criou uma zona pública e outra privada para gcp.example.com. Você configurou o registrador de gcp.example.com para usar servidores de nomes do Cloud DNS, para que sua zona pública esteja acessível na Internet. Além disso, você autorizou o acesso à zona particular a partir da sua rede VPC.

Na zona particular, você criou um único registro:

Nome do DNS	Tipo	TTL (segundos)	Dados
foo.gcp.example.com	A	5	10.128.1.35

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

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

Veja nos exemplos abaixo como as consultas aos registros DNS são resolvidas:

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

Controle de acesso

Controle de acesso geral

É 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 mudanças, eles precisam estar listados como editor ou owner na seção "Permissões" do Console do Cloud. O nível de permissão para visualização concede acesso somente leitura aos registros do Cloud DNS.

Essas permissões também se aplicam às contas de serviço que podem ser usadas 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 de administrador de DNS ou leitor de DNS podem gerenciar ou visualizar as zonas gerenciadas em todos os projetos a que eles têm acesso.

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

Desempenho e tempo

O Cloud DNS usa o método anycast (em inglês) para exibir 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 cache do resolvedor de nomes DNS é controlado pelo valor de time to live (TTL) que você especifica para seus registros. Esse valor é especificado em segundos. 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ê vai alterar para serviços que exigem uma janela menor, altere o valor de TTL para um valor menor 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 nomes DNS.

Próximas etapas

• Para dar os primeiros passos com o Cloud DNS, consulte o guia de início rápido.
• Saiba mais sobre nossas bibliotecas de cliente de API.