Visão geral

Nesta página, você encontrará uma visão geral dos recursos e funcionalidades 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, 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.

Para ver uma lista de terminologia geral de DNS, acesse a visão geral do 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, já uma zona particular é visível apenas para os usuários em uma ou mais redes VPC especificadas por você.

Terminologia do Cloud DNS

A API do Cloud DNS 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 em que o faturamento é configurado e agregado. Para mais detalhes, veja Como criar e gerenciar projetos.
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 o uso de rótulos (em inglês), o que ajuda a organizar o faturamento.
Zonas públicas

Uma zona pública é visível para a Internet. O Cloud DNS tem servidores de nomes públicos autoritários 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 divulgar seu 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 198.51.100.0

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.

Para mais informações sobre como registrar e configurar seu domínio, consulte Como configurar um domínio usando o Cloud DNS.

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 que a zona particular. Se você precisar consultar registros hospedados em zonas particulares gerenciadas em outros projetos, use o peering de DNS.

Você precisa especificar a lista de redes VPC autorizadas que podem ser usadas para consultar sua zona particular ao criá-la ou atualizá-la. Somente redes autorizadas podem ser usadas para consultar a zona particular. Se nenhuma rede desse tipo for especificada, não será possível consultar essa zona.

É possível usar zonas particulares com uma VPC compartilhada. Para ver informações importantes sobre o uso de zonas particulares com a VPC compartilhada, consulte as considerações relacionadas.

As zonas particulares não são compatíveis com extensões de segurança de DNS (DNSSEC) 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

É possível usar as zonas particulares para criar configurações DNS split horizon. Isso ocorre porque é possível criar uma zona particular com um conjunto diferente de registros, que modifica os registros em uma zona pública. Em seguida, é possível controlar quais redes VPC consultam os registros na zona particular. Por exemplo, consulte as zonas sobrepostas.

Diretório de serviços

O diretório de serviço é um registro de serviço gerenciado para o Google Cloud. Ele permite registrar e descobrir serviços usando HTTP ou gRPC (usando a API Lookup), além de usar DNS tradicional. É possível registrar serviços que sejam ou não do Google Cloud usando o diretório de serviço.

O Cloud DNS permite criar zonas com suporte de diretório de serviços, que são um tipo de zona particular que contém informações sobre seus serviços e endpoints. Você não adiciona conjuntos de registros à zona. Em vez disso, eles são inferidos automaticamente com base na configuração do namespace do diretório de serviços associado à zona. Para informações detalhadas sobre o diretório de serviços, consulte a Visão geral do diretório de serviços.

Cloud DNS e endereços não-RFC 1918

Por padrão, o Cloud DNS encaminha esses endereços para a Internet pública. No entanto, o Cloud DNS também aceita encaminhamento para endereços não-RFC 1918 para zonas particulares.

Depois de configurar uma rede VPC para usar endereços não-RFC 1918, é preciso configurar a zona privada do Cloud DNS como uma zona de pesquisa reversa gerenciada. Essa configuração permite que o Cloud DNS resolva localmente endereços não-RFC 1918 em vez de enviá-los pela Internet.

O Cloud DNS também aceita encaminhamento de saída para endereços não-RFC 1918 ao encaminhar de modo privado esses endereços no Google Cloud. Para ativar esse tipo de encaminhamento de saída, configure uma zona de encaminhamento com argumentos de caminho de encaminhamento específicos. Para mais detalhes, consulte Como criar uma política de servidor de saída.

Zonas de encaminhamento

Trata-se de um tipo de zona particular gerenciada do Cloud DNS que envia solicitações dessa zona para os endereços IP dos destinos de encaminhamento dela. Para mais informações, consulte os métodos de encaminhamento de DNS.

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.

Nomes de domínio internacionalizados (IDN)

Um nome de domínio internacional (IDN, na sigla em inglês) é um nome de domínio da Internet que permite que pessoas do mundo todo usem um script ou alfabeto específico do idioma, como árabe, chinês, cirílico, devanagari, hebraico ou caracteres especiais de idiomas latinos nos nomes de domínio. Essa conversão é implementada usando o Punycode, que é uma representação de caracteres Unicode usando ASCII. Por exemplo, uma representação de IDN de .ελ é .xn--qxam. Alguns navegadores, clientes de e-mail e aplicativos podem reconhecê-lo e renderizá-lo como .ελ em seu nome. O padrão Internacionalização de nomes de domínio em aplicativos (IDNA, na sigla em inglês) permite apenas strings Unicode curtas o suficiente para serem representadas como um rótulo DNS válido. Para informações sobre como usar a IDN com o Cloud DNS, consulte Como criar zonas com nomes de domínio internacionalizados.

Registrador

Um registrador de domínios (em inglês) é uma organização que gerencia a reserva de nomes de domínio da Internet. Um registrador precisa ter a autorização de um registro de domínio de nível superior genérico (gTLD, na sigla em inglês) ou de domínio de nível superior 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 sobre o DNS interno, consulte a documentação relacionada.

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 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 alterar a ordem da resolução de nomes da 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ê tiver várias zonas de subdomínio, mas não criar a zona mãe, pode ser complicado criar essa zona mais tarde se decidir movê-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 esse serviço. 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 DNSSEC.

Considerações sobre a VPC compartilhada

Para usar uma zona particular gerenciada, uma zona de encaminhamento ou uma zona de peering do Cloud DNS com a VPC compartilhada, crie a zona no projeto host e adicione as redes VPC compartilhadas apropriadas à lista de redes autorizadas para essa zona.

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

Ordem de resolução de nome da VPC

Cada rede VPC fornece serviços de resolução de nome DNS para as instâncias de máquina virtual (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 a seguir:

  • Se sua rede VPC tiver uma política de servidor de saída, todas as consultas DNS serão encaminhadas para esses servidores alternativos pelo Google Cloud. A ordem de resolução de nomes da VPC consiste apenas nessa etapa.

  • Se sua rede VPC não tiver uma política de servidor de saída:

    1. o Google Cloud tentará encontrar uma zona particular que corresponda ao máximo possível do registro solicitado (a maior correspondência de sufixo). Isso inclui:
      • pesquisa de registros criados em zonas particulares;
      • consulta de destinos de encaminhamento para zonas de desse mesmo tipo;
      • consulta de ordem de resolução de nomes de outra rede VPC usando zonas de peering;
    2. 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.

Métodos de encaminhamento de DNS

O Google Cloud oferece encaminhamento de DNS de entrada e saída para zonas particulares.

  • Encaminhamento de entrada significa permitir que um cliente ou servidor DNS no local envie solicitações desse tipo 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. O encaminhamento de entrada permite que clientes locais determinem registros em zonas particulares, zonas de encaminhamento e zonas de peering para onde a rede VPC foi autorizada. Clientes locais se conectam à rede VPC usando a VPN do Cloud ou o Cloud Interconnect.

  • Encaminhamento de saída significa permitir que as VMs no Google Cloud enviem solicitações de DNS para servidores de nomes DNS de sua escolha. Os servidores de nomes podem estar localizados na mesma rede VPC, em uma rede no local ou na Internet.

Para configurar o encaminhamento de DNS, crie 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 Métodos do Cloud DNS
Entrada Os sistemas locais podem enviar solicitações para uma rede VPC para usar a ordem de resolução de nome VPC dessa rede se você criar uma política de servidor de entrada para essa mesma rede.
Saída É possível configurar VMs em uma rede VPC para o seguinte:
  • Resolver registros hospedados em servidores de nomes configurados como destinos de encaminhamento de uma zona de encaminhamento autorizada para uso pela rede VPC. Para informações importantes sobre como o Google Cloud encaminha o tráfego para o endereço IP de um destino de encaminhamento, acesse esta página.
  • Enviar um servidor de nomes alternativo para todas as solicitações DNS criando uma política de servidor de saída para a rede VPC. Ao usar um servidor de nomes alternativo, as VMs na sua rede VPC não poderão mais ser usadas para resolver registros em zonas particulares, zonas de encaminhamento ou zonas de peering do Cloud DNS. Para mais detalhes, acesse a ordem de resolução de nome da VPC

É possível configurar simultaneamente o encaminhamento 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.

No plano de controle do Cloud DNS, é usado um algoritmo para determinar a receptividade de um destino de encaminhamento. Às vezes, suas consultas encaminhadas de saída podem resultar em erros SERVFAIL. Para informações sobre como resolver esse problema, consulte a seção relacionada na documentação de solução de problemas.

Registros PTR em zonas particulares

Registros PTR para endereços RFC 1918

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.

  • 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 particular do Cloud DNS para endereços RFC 1918, os registros PTR personalizados criados para VMs nessa zona serão modificados pelos registros PTR criados automaticamente com o DNS interno do Compute Engine. 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, 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 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 será possível criar zonas particulares inversas do Cloud DNS mais específicas se precisar modificar apenas uma parte de um bloco de rede. Por exemplo, uma zona particular para 5.10.in-addr.arpa. pode ser usada para armazenar registros PTR que modificam quaisquer registros PTR de 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, 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). Para detalhes, consulte a solução de problemas.

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 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. Por exemplo:


"Hello world" "Bye world"

Em Como gerenciar registros, você verá 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 é compatível com a 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, a DNSSEC fornece uma autenticação forte (mas não criptografia) para pesquisas de domínio. Para mais informações sobre como configurar a DNSSEC, consulte esta página.

Zonas de encaminhamento

As zonas de encaminhamento do Cloud DNS permitem a configuração de 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 pela VPN do Cloud ou 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 Roteamento particular As solicitações vêm de
Tipo 1 Um endereço IP interno de uma VM do Google Cloud na mesma rede VPC autorizada a usar a zona de encaminhamento Precisa ser um endereço IP RFC 1918. O tráfego sempre é roteado por uma rede VPC autorizada Qualquer endereço IP interno. 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 Precisa ser um endereço IP RFC 1918. O tráfego sempre é roteado por uma rede VPC autorizada Qualquer endereço IP interno. 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 na Internet.
Inclui um endereço IP externo de um recurso do Google Cloud.
Precisa ser um endereço roteável da Internet. O tráfego sempre é roteado para a Internet O roteamento particular não é compatível. 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: direciona 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 classificará o destino como um destino Type 1 ou Type 2 e encaminhará as solicitações por meio do uma rede VPC autorizada. Se o destino não for um endereço IP RFC 1918, o Cloud DNS o classificará como Tipo 3 e espera que o destino seja acessível pela Internet.

  • Roteamento privado: sempre direciona 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 de Tipo 1 ou Tipo 2, o Cloud DNS usa rotas na rede VPC autorizada, em que o cliente DNS está localizado. Estas rotas definem um caminho seguro para o destino de encaminhamento:

Para mais orientações sobre os requisitos de rede para destinos Tipo 1 e Tipo 2, consulte 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 SO 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

Não é possível conectar o Cloud DNS a um destino de encaminhamento por meio de roteamento transitivo. Para ilustrar uma configuração inválida, considere o cenário a seguir:

  • Você conectou uma rede local a uma rede VPC chamada vpc-net-a usando a VPN do Cloud ou o Cloud Interconnect.

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

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

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

  • Consulte o servidor de metadados da VM, 169.254.169.254, para um registro definido na zona de encaminhamento. É esperado que essa consulta falhe, porque o Cloud DNS não é compatível com roteamento transitivo para destinos de encaminhamento. Para usar uma zona de encaminhamento, é preciso configurar uma VM para usar o servidor de metadados.
  • Consulte o destino do encaminhamento diretamente em busca do mesmo registro. Com essa consulta, você verá que a conectividade transitiva é bem-sucedida, mesmo que o Cloud DNS não use esse caminho.

É possível corrigir esse cenário inválido usando uma zona de peering do Cloud DNS:

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

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

Peering de DNS

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

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

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

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. As pesquisas por registros no namespace da zona de peering seguem a ordem de resolução de nomes da rede produtora de DNS. Dessa forma, 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.
  • 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 último não é obrigatório.
  • 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 tem como destino vpc-net-b e uma zona de peering em vpc-net-b, que tem como destino vpc-net-c.
  • Se você estiver usando o peering de DNS para segmentar uma zona de encaminhamento, a rede VPC de destino com a zona de encaminhamento precisará conter uma VM, um anexo de interconexão (VLAN) ou um túnel do Cloud VPN localizado no mesmo região que a VM de origem que usa a zona de peering de DNS. Para detalhes sobre essa limitação, consulte a seção "Solução de problemas".

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. Por exemplo:

  • Uma zona para gcp.example.com e outra para gcp.example.com se sobrepõem, porque os nomes de domínio são idênticos.
  • Uma zona para dev.gcp.example.com e uma zona para gcp.example.com se sobrepõem porque dev.gcp.example.com é um subdomínio de gcp.example.com. Consulte a próxima seção para regras que se aplicam a zonas sobrepostas.

Regras para zonas sobrepostas

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

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

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

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

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

Exemplos de resolução de consulta

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

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

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

  • O servidor de metadados usa servidores de nomes públicos para resolver um registro para myapp.example.com, porque não há zona particular para example.com que tenha sido autorizada para a rede VPC.
  • O servidor de metadados resolve o registro myapp.gcp.example.com usando a zona particular autorizada gcp.example.com, porque gcp.example.com é o maior sufixo comum entre o nome do registro solicitado e as zonas particulares autorizadas disponíveis. Se não houver registro para myapp.gcp.example.com definido na zona particular gcp.example.com, a resposta será NXDOMAIN, mesmo se houver um registro para myapp.gcp.example.com definido em uma zona pública.
  • Da mesma forma, as consultas para myapp.dev.gcp.example.com são resolvidas de acordo com os registros na zona particular autorizada dev.gcp.example.com. Se não houver registro para myapp.dev.gcp.example.com na zona dev.gcp.example.com, a resposta será NXDOMAIN, mesmo se houver um registro para myapp.dev.gcp.example.com em outra zona particular ou pública.
  • As consultas para myapp.prod.gcp.example.com serão resolvidas de acordo com os registros na zona particular gcp.example.com, porque gcp.example.com é o maior sufixo comum entre o registro DNS solicitado e as zonas particulares disponíveis.

Exemplo de DNS split horizon

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

Considere o exemplo de split horizon a seguir:

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

Na zona particular, você criou apenas um registro:

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

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

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

As consultas a seguir são determinadas conforme descrito:

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

Políticas do servidor DNS

É possível configurar uma política de servidor DNS para cada rede VPC. A política pode ser usada para especificar o encaminhamento de entrada, o encaminhamento de saída ou ambos. Nesta seção, política do servidor de entrada refere-se a uma política que permite o encaminhamento de DNS de entrada. Já política do servidor de saída refere-se a um método possível para implementar 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.

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 disponibilizar esses serviços de resolução de nomes para uma rede local conectada usando a VPN do Cloud ou o Cloud Interconnect criando uma política de DNS de entrada na rede VPC.

Quando você cria uma política de entrada, o Cloud DNS adquire um endereço IP interno do intervalo de endereços IP principal de uma sub-rede em cada região usada pela rede VPC. Ele usa esses endereços IP internos como pontos de acesso para solicitações de DNS de entrada.

Pontos de acesso da política de entrada

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

Para informações sobre como criar políticas de servidor de entrada, consulte esta página.

Política de servidor de saída

É possível alterar a ordem de resolução de nomes da VPC criando uma política de DNS 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 esta página.

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 Roteamento particular As solicitações vêm de
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 Precisa ser um endereço IP RFC 1918. O tráfego sempre é roteado por uma rede VPC autorizada Qualquer endereço IP interno. 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 Precisa ser um endereço IP RFC 1918. O tráfego sempre é roteado por uma rede VPC autorizada Qualquer endereço IP interno. 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 na Internet.
Inclui um endereço IP externo de um recurso do Google Cloud.
Precisa ser um endereço roteável da Internet. O tráfego sempre é roteado para a Internet O roteamento particular não é compatível. Intervalos de origem do DNS público do Google

Escolha um dos dois métodos de roteamento a seguir ao especificar o servidor de nomes alternativo de uma política de encaminhamento de saída.

  • Roteamento padrão: direciona o tráfego por meio de uma rede VPC autorizada ou pela Internet, baseado 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 Tipo 1 ou Tipo 2 e encaminhará 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 classificará o servidor de nomes como Tipo 3 e espera que o servidor de nomes seja acessível pela Internet.

  • Roteamento privado: sempre direciona 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 Tipo 1 e Tipo 2 são compatíveis.

Para acessar um servidor de nomes alternativo do Tipo 1 ou um 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:

Para mais orientações sobre os requisitos de rede para servidor de nomes de Tipo 1 e do Tipo 2, consulte os requisitos de rede do servidor de nomes alternativo.

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 administrador de DNS ou leitor de DNS 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 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