Visão geral

Nesta página, você encontra uma visão geral dos recursos do Cloud DNS. Para começar a usar 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, confiável 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 softwares de DNS.

Conceitos gerais de DNS

Para ver uma lista com a terminologia geral do DNS, consulte RFC 7719.

No Cloud DNS, são oferecidas zonas DNS gerenciadas públicas e particulares. Uma zona pública é visível para a Internet pública, mas uma zona particular é visível apenas a partir de uma ou mais redes VPC especificadas.

Com as zonas particulares, você define configurações DNS split horizon. Isso é possível porque essas zonas podem ser criadas com um conjunto diferente de registros DNS específicos para a 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 do console do Google Cloud Platform é um contêiner para recursos, um domínio para controle de acesso e o local onde o faturamento é configurado e integrado. Cada recurso do Cloud DNS está em um projeto, e cada operação do Cloud DNS precisa especificar em que projeto ela opera.

Zonas gerenciadas

A zona gerenciada armazena os registros de DNS para o mesmo sufixo de nome DNS (example.com, por exemplo). Um projeto pode ter várias zonas gerenciadas, mas cada projeto precisa ter um nome exclusivo. No Cloud DNS, a zona gerenciada é o recurso que molda uma zona DNS. 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 se acumulam para cada zona considerando cada dia de existência da zona gerenciada. As zonas gerenciadas aceitam marcadores, que você pode usar para ajudar a organizar seu faturamento. O artigo Como gerenciar zonas explica como gerenciar 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, crie o registro a seguir em uma zona pública example.com do site público www.example.com.

Nome 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

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

Uma zona particular só pode ser consultada por recursos no mesmo projeto em que está definida. 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 privadas com a VPC compartilhada. Para 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).

As solicitações de registros DNS em zonas privadas 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 de qualquer VM que utilize uma rede VPC autorizada.

Por exemplo, é possível criar uma zona particular para dev.gcp.example.com para hospedar registros DNS internos para aplicativos de teste. A tabela a seguir apresenta exemplos de registros nessa zona. Clientes de bancos de dados podem conectar-se ao servidor de banco de dados, db-01.dev.gcp.example.com, usando o nome DNS interno dele em vez do endereço IP. Clientes de bancos de dados resolvem esse nome DNS interno usando o resolvedor de host na VM, que envia a consulta DNS ao servidor de metadados, 169.254.169.254. O servidor de metadados atua como um resolvedor recursivo para consultar sua zona particular.

Nome 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

Uma zona de encaminhamento é um tipo de zona privada gerenciada do Cloud DNS que envia solicitações para essa zona para os endereços IP dos destinos de encaminhamento. Consulte encaminhamento de DNS para mais informações.

Zonas de peering

Uma zona de peering é um tipo de zona privada 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 na outra rede VPC.

Operações de zona

Todas as alterações feitas nas zonas gerenciadas no Cloud DNS são registradas no conjunto de operações. Ele lista as atualizações da zona gerenciada por meio da modificação de descrições e do estado ou configuração do DNSSEC.

Registrador

Um registrador de nomes de domínio é 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 GCP cria automaticamente nomes DNS internos para VMs, mesmo que você não use o Cloud DNS. Para mais informações sobre o DNS interno, consulte a documentação.

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.

Coleção de conjuntos de registros de recursos

A coleção de conjuntos de registros de recursos armazena o estado atual dos registros de DNS que formam uma zona gerenciada. Você pode ler essa coleção, mas não é possível modificá-la diretamente. Em vez disso, edite os conjuntos de registros de recursos com a criação de uma solicitação Change na coleção de alterações. A coleção de conjuntos de registros de recursos reflete todas as suas alterações 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. O artigo Como gerenciar registros explica como gerenciar os registros.

Alterações nos registros de recursos

Quando você quiser fazer uma alteração na coleção de conjuntos de registros de recursos, será necessário enviar uma solicitação Change que contenha as adições ou exclusões. Adições e exclusões podem ser feitas em lote, em uma única transação atômica, e entrar em vigor ao mesmo tempo em cada servidor DNS autoritativo.

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á assim após a alteração em massa:

www  A  203.0.113.1 203.0.113.3

O ADD e DEL acontecem 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 constantemente com cada alteração transacional para os conjuntos de registros de uma zona por meio do comando gcloud dns record-sets transaction. É possível alterar 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 no RFC 1912. Por exemplo, no seguinte registro SOA:

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

É possível alterar o número de série diretamente do Console do Google Cloud Platform inserindo o valor desejado no terceiro campo delimitado por espaço do registro.

Política de servidor DNS

Com a política de servidor DNS, você tem acesso aos serviços de resolução de nome fornecidos pelo GCP em uma rede VPC com encaminhamento de entrada. Além disso, é possível alterar a ordem da resolução de nome 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 NS (servidor de nomes) 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 zonas 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 e não criou a zona pai, pode ser complicado criá-la caso decida transferi-la para o Cloud DNS posteriormente.

DNSSEC

As Extensões de Segurança do Sistema de Nomes de Domínio (DNSSEC) são um conjunto de extensões Internet Engineering Task Force (IETF, na sigla em inglês, uma força-tarefa que organiza a Internet) 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 DNSKEY

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

Ordem da resolução de nome VPC

Cada rede VPC fornece serviços de resolução de nome DNS para as instâncias de VM que o utilizam. Quando as VMs usam o servidor de metadados 169.254.169.254 como servidor de nomes, o GCP procura registros DNS de acordo com a seguinte ordem:

Se uma política de DNS que especifica um servidor de nomes alternativo do encaminhamento de saída tiver sido configurada para a rede VPC, o GCP encaminhará todas as consultas DNS somente para esse servidor. Consulte Encaminhamento de DNS de saída usando um servidor de nomes alternativo para mais detalhes.
O GCP consulta os seguintes serviços de resolução de nome, nesta ordem, usando a correspondência de maior sufixo:
- O GCP consulta todas as zonas de encaminhamento particulares e gerenciadas do Cloud DNS que foram autorizadas na rede VPC. São enviadas solicitações aos endereços IP dos destinos de encaminhamento.
- O GCP consulta todas as zonas particulares gerenciadas do Cloud DNS que foram autorizadas na rede VPC em busca de registros.
- O GCP pesquisa os registros DNS internos do Compute Engine criados automaticamente no projeto.
O GCP consulta as zonas com disponibilidade pública, seguindo o começo de autoridade (SOA, na sigla em inglês) definido corretamente. Isso inclui zonas públicas do Cloud DNS.

Como usar registros PTR em zonas privadas

Como consequência da correspondência de maior prefixo descrita na ordem de resolução de nomes VPC, para realizar pesquisas inversas com registros PTR personalizados, é necessário criar uma zona privada 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., ... até 31.172.in-addr.arpa.

Se você criar uma zona privada do Cloud DNS para in-addr.arpa., os registros PTR personalizados das instâncias de VM que você criar nessa zona serão ocultados pelos registros PTR que o DNS interno do Compute Engine criará automaticamente. Isso ocorre porque os registros PTR DNS internos do Compute Engine são criados na lista anterior de zonas mais específicas.

Por exemplo, suponha que você crie uma zona privada gerenciada para in-addr.arpa. com o seguinte registro PTR para uma instância de VM cujo endereço IP é 10.1.1.1:

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

Consultas PTR para 1.1.1.10.in-addr.arpa. serão respondidas pela zona DNS interna do Compute Engine. 10.in-addr.arpa. mais específica. O registro PTR na sua zona privada do Cloud DNS para test.example.domain será ignorado.

Para modificar os registros DNS PTR internos do Compute Engine criados automaticamente para as VMs, certifique-se de criar seus registros PTR personalizados em uma zona privada que seja pelo menos tão específica quanto uma das zonas apresentadas nesta seção. Por exemplo, se você criar o seguinte registro PTR em uma zona privada para 10.in-addr.arpa., seu registro modificará aquele gerado automaticamente:

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

Você também pode criar zonas privadas de DNS em nuvem mais específicas se precisar substituir apenas uma parte de um bloco de rede. Por exemplo, uma zona privada para 5.10.in-addr.arpa. pode ser usada para manter registros PTR que modificam registros de PTR DNS internos do Compute Engine, 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, usado para mapear nomes de host ao endereço IPv4 deles.
`AAAA`	Registro de endereço IPv6, usado para mapear nomes de host ao endereço IPv6 deles.
`CAA`	Autorização da autoridade de certificação (CA, na sigla em inglês), usada para especificar quais CAs podem criar certificados para um domínio.
`CNAME`	Registro de nome canônico, usado para especificar nomes de alias. O Cloud DNS não é compatível com a resolução de CNAMEs recursivamente em diferentes zonas particulares gerenciadas (pesquisa CNAME). Consulte a solução de problemas para detalhes.
`IPSECKEY`	Chaves públicas e dados do gateway do túnel IPSEC para clientes com recursos de IPSEC a fim de permitir a criptografia oportunista.
`MX`	Registro de troca de e-mails, usado no encaminhamento de solicitações para servidores de e-mail.
`NAPTR`	Registro PTR da autoridade de inscrição de nome, definido pela referência RFC 3403.
`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 de começo da autoridade, que especifica informações autoritativas sobre uma zona DNS. Um registro de recurso `SOA` é gerado para você ao criar sua zona gerenciada. É possível modificar o registro conforme necessário. Por exemplo, alterar o número de série para um número arbitrário a fim de dar suporte ao controle de versão baseado em data.
`SPF`	Registro do framework de política do remetente, um tipo de registro obsoleto usado antigamente em sistemas de validação de e-mail. Em vez disso, use um registro TXT.
`SRV`	Registro de localizador de serviço, usado por alguns serviços de voz sobre IP, protocolos de mensagem instantânea e outros aplicativos.
`SSHFP`	Impressão digital SSH para clientes SSH com a função de validar as chaves públicas de servidores SSH.
`TLSA`	Registro de autenticação TLS para clientes TLS com a função de validar certificados de servidor 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 comprimento máximo de cada string individual é de 255 caracteres. Agentes de e-mail e outros agentes de software concatenarão várias strings. Coloque cada string entre aspas. Por exemplo: "Hello world" "Bye world"

Em Como gerenciar registros, você vê como trabalhar com registros DNS.

Registros DNS curinga

Registros curinga são aceitos para todos os tipos de registro, exceto para registros 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.

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 servidores de nomes internos da plataforma e que não são do GCP. Ao definir o encaminhamento bidirecional, as instâncias na rede VPC pesquisam endereços de hosts em redes locais ou em várias nuvens. Além disso, hosts em redes vinculadas procuram endereços de recursos na rede VPC.

O GCP aceita o encaminhamento de DNS das seguintes maneiras:

As redes VPC são compatíveis com o encaminhamento de DNS de entrada e saída por meio de políticas de servidor DNS. A origem das solicitações de entrada precisa ser sistemas em 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.

No exemplo a seguir, ilustramos duas redes VPC, prod e dev, com o encaminhamento de DNS 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, Europa e 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 ficam 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 GCP usam o servidor de metadados 169.254.169.254 para resolver o DNS interno, quaisquer zonas particulares do Cloud DNS autorizadas nas respectivas redes dev ou prod, zonas públicas de DNS e a zona corp.example.com local.

Política de servidor DNS

Com a política de servidor DNS, você configura o encaminhamento de DNS de entrada e saída em uma rede VPC. É possível aplicar uma política a uma determinada rede VPC.

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

Encaminhamento de DNS de entrada

Por padrão, os serviços de resolução de nome 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 nome.

Para configurar uma política que permita o encaminhamento de DNS de entrada à rede VPC, consulte estas informações. Quando configurada, o GCP aloca um endereço IP interno em uma sub-rede em uma região da rede VPC para funcionar como um proxy de solicitações de DNS de entrada. É possível especificar uma região ou deixar que o GCP escolha uma 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 endereço IP único serve apenas como ponto de entrada para os serviços de resolução de nome da rede VPC. Configure os servidores de nomes locais para realizar encaminhamentos ao endereço de proxy conforme necessário.

Como encaminhar DNS de saída usando um servidor de nomes alternativo

É possível alterar a ordem de resolução de nome VPC criando uma política de DNS que especifique uma lista de servidores de nomes alternativos. Ao fazer isso, os servidores alternativos de nomes se tornam a única origem consultada pelo GCP para todas as solicitações de DNS enviadas por 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 internos de outras VMs do GCP na rede VPC ou sistemas na rede local conectados à VPC por meio do Cloud VPN ou Cloud Interconnect. Em vez disso, se você usar endereços IP públicos na especificação, os servidores de nomes alternativos precisarão ser acessíveis pela Internet.

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 por meio de todos os servidores de nomes de destino. No exemplo acima, as consultas correspondentes são encaminhadas para todos os endereços ou um subconjunto de 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 de mysvc.onprem.example.com é encaminhada para 172.16.8.40 de acordo com a zona 1, uma de mysvc.dev.onprem.example.com é encaminhada para 172.16.8.50 de acordo com a zona 2 e uma de mysvc.prod.onprem.example.com para 172.16.8.60 de acordo com a zona 3.

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

Peering de DNS

O peering de DNS permite enviar solicitações de registros que vêm do namespace de uma zona para outra rede VPC.

Para fornecer o peering de DNS, é preciso criar uma zona de peering do Cloud DNS e configurá-la para executar buscas de DNS em uma rede VPC na qual 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 do consumidor de DNS.

Uma vez autorizados, os recursos do GCP na rede do consumidor de DNS podem executar buscas de registros no namespace da zona de peering como se estivessem na rede do produtor de DNS. A busca de registros no namespace da zona de peering segue a ordem de resolução de nomes da rede do produtor de DNS. Assim, os recursos do GCP na rede do consumidor de DNS podem buscar registros no namespace da zona das seguintes fontes disponíveis na rede do produtor de DNS:

As zonas privadas gerenciadas do Cloud DNS autorizadas para uso da rede do produtor de DNS
As zonas de encaminhamento gerenciadas do Cloud DNS autorizadas para uso da rede do produtor de DNS
Nomes DNS internos do Compute Engine na rede do produtor de DNS
Um servidor de nomes alternativo, se uma política de DNS de saída tiver sido configurada na rede do produtor 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 GCP na rede do consumidor de DNS busquem registros no namespace da zona de peering como se os recursos do GCP estivessem na rede do produtor de DNS.
As redes do produtor e consumidor de DNS precisam ser redes VPC do GCP.
O peering de DNS e o peering de rede VPC são serviços diferentes. O peering de DNS pode ser usado em conjunto com o peering de rede VPC, mas este último não é necessário para o peering de DNS.

Para criar uma zona de peering, é preciso ter o papel do IAM de par de DNS para o projeto que contém a rede do produtor 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 a ser usada para criar uma zona de peering na rede do consumidor. O produtor também concede a essa conta o papel dns.peer na própria rede. Assim, as solicitações da zona de peering podem alcançar a zona do resolvedor. 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 do consumidor nos diferentes projetos. Configure cada zona de peering para usar a mesma rede do produtor, de modo que os recursos do GCP nas redes do consumidor possam seguir a ordem de resolução de nomes da rede do produtor. Isso permite que eles resolvam registros no namespace de qualquer zona privada gerenciada autorizada para a rede do produtor.

Novidades relacionadas às zonas de peering

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

Zonas particulares e VPC compartilhada

Para usar zonas particulares com VPC compartilhada, crie sua zona particular no projeto de host e adicione a rede VPC compartilhada apropriada à 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 particulares é permitida.

As zonas particulares desenvolvidas para diferentes redes VPC podem se sobrepor umas às outras. Por exemplo, duas redes VPC podem ter VMs de bancos de dados chamadas database.gcp.example.com em uma zona gcp.example.com. As consultas de 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 o 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.

Nos exemplos a seguir, ilustramos a ordem que o servidor de metadados usa ao consultar registros DNS. Em cada um desses exemplos, vamos supor que você tenha criado duas zonas particulares, gcp.example.com e dev.gcp.example.com, e autorizado o acesso a elas a partir da mesma rede VPC. O GCP processa as consultas DNS das VMs na rede VPC:

O servidor de metadados usa servidores de nomes públicos para resolver myapp.example.com porque não há zona particular de example.com.
O servidor de metadados resolve myapp.gcp.example.com usando a zona particular gcp.example.com porque gcp.example.com é o maior sufixo comum entre o registro DNS solicitado e as zonas particulares disponíveis. NXDOMAIN é retornado se não houver registro de myapp.gcp.example.com definido na zona particular gcp.example.com, mesmo se houver um registro de myapp.gcp.example.com definido em um servidor de nome público.
Da mesma forma, as consultas de myapp.dev.gcp.example.com são resolvidas de acordo com os registros definidos na zona particular dev.gcp.example.com. NXDOMAIN é retornado se não houver registro de myapp.dev.gcp.example.com na zona dev.gcp.example.com, mesmo se houver um registro de myapp.dev.gcp.example.com em outra zona particular ou pública.
As consultas de myapp.prod.gcp.example.com sã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.

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, você define respostas diferentes a uma consulta para o mesmo registro quando ela é originada de uma VM dentro de uma VPC autorizada. O DNS split horizon é ú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 das VMs nessa rede em busca de registros DNS nessa zona são direcionadas a 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 atenda aos mesmos registros DNS com respostas públicas adequadas para a produção.

Por exemplo, vamos supor que você tenha criado uma zona particular e uma pública para gcp.example.com. Você configurou o registrador de gcp.example.com para usar os servidores de nomes do Cloud DNS e tornar a zona pública acessível pela Internet. Além disso, você autorizou o acesso à zona particular a partir da rede VPC.

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

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

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

Nome 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

Nos exemplos a seguir, você verá como as consultas aos registros DNS são resolvidas:

Uma consulta de foo.gcp.example.com a partir de uma VM na rede VPC retorna 10.128.1.35.
Uma consulta de foo.gcp.example.com da Internet retorna 104.198.6.142.
Uma consulta de bar.gcp.example.com da VM na rede VPC retorna um erro NXDOMAIN porque não há nenhum registro de bar.gcp.example.com na zona particular gcp.example.com.
Uma consulta de bar.gcp.example.com da Internet retorna 104.198.7.145.

Controle de acesso

Controle de acesso geral

É possível gerenciar quais usuários têm permissão para fazer alterações nos registros de DNS na página "IAM e Admin" no console do Google Cloud Platform. Para que os usuários sejam autorizados a fazer alterações, eles precisam ser listados como um editor ou owner na seção "Permissões" do Console do GCP. O nível de permissão de leitor 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 no projeto específico que estão gerenciando.

Os usuários com os papéis Administrador de DNS ou Leitor de DNS podem gerenciar ou visualizar as zonas gerenciadas em todos os projetos aos quais 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 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 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 começar a usar o Cloud DNS, consulte o Guia de início rápido.