Termos-chave

Este documento apresenta a terminologia-chave que se aplica ao Cloud DNS. Leia esses termos para entender melhor como o Cloud DNS funciona e os conceitos da criação dele.

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 onde o faturamento é configurado e agregado. Para mais detalhes, veja Como criar e gerenciar projetos.

Zona gerenciada

A zona gerenciada mantém os registros do Sistema de Nome de Domínio (DNS, na sigla em inglês) para o mesmo sufixo de nome de DNS (como example.com). 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 várias zonas gerenciadas. As cobranças são acumuladas por zona, considerando cada dia de existência da zona gerenciada. As zonas gerenciadas aceitam rótulos que podem ser usados para ajudar a organizar seu faturamento.

Zona pública

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

Observação: as zonas públicas do Cloud DNS são autoritativas, e os registros de recurso NS (servidor de nomes) e SOA estão na zona apex. Não é possível excluir esses tipos de registros. Para detalhes, consulte RFC 1034.

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

Zona particular

Com as zonas particulares, é possível gerenciar nomes de domínio personalizados para instâncias de máquina virtual (VM), 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 de nuvem privada virtual (VPC) que você autorizar.

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, 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 de nomes 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. O servidor de metadados atua como um resolvedor recursivo para consultar sua 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

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

Diretório de serviços

O Diretório de serviços é um registro de serviços gerenciado do Google Cloud que permite registrar e descobrir serviços usando HTTP ou gRPC (usando a API Lookup), além de usar o DNS tradicional. Use o Diretório de serviços para registrar os serviços do Google Cloud e de terceiros.

O Cloud DNS permite criar zonas com suporte do 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 mais informações, consulte a Visão geral do Diretório de serviços.

Ao criar uma zona apoiada pelo Diretório de serviços, não é possível adicionar registros diretamente à zona. Os dados são provenientes do registro de serviços do Diretório de serviços.

Cloud DNS e pesquisa reversa de endereços não RFC 1918

Por padrão, o Cloud DNS encaminha solicitações para registros PTR de endereços não RFC 1918 por meio da Internet pública. No entanto, o Cloud DNS também aceita a pesquisa reversa de endereços não RFC 1918 usando zonas particulares.

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

Ao criar uma zona de DNS de pesquisa reversa gerenciada, não é possível adicionar registros diretamente à zona. Os dados vêm dos dados de endereço IP do Compute Engine.

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 detalhes, consulte Destinos de encaminhamento e métodos de roteamento.

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

Quando você cria uma zona de encaminhamento, não é possível adicionar registros diretamente a ela. Os dados são provenientes de um ou mais servidores de nomes de destino configurados ou resolvedores.

Zona 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. É possível usá-la para resolver os nomes definidos na outra rede VPC.

Ao criar uma zona de peering de DNS, não é possível adicionar registros diretamente à zona. Os dados são provenientes da rede VPC do produtor, de acordo com a ordem de resolução de nomes.

Política de resposta

Uma política de resposta é um conceito de zona particular do Cloud DNS que contém regras em vez de registros. É possível usar essas regras para alcançar efeitos semelhantes ao conceito de rascunho da zona de política de resposta (RPZ, na sigla em inglês) de DNS (IETF, link em inglês). O recurso de política de resposta permite introduzir regras personalizadas nos servidores DNS na rede que o resolvedor de DNS consulta durante as pesquisas. Se uma regra na política de resposta afetar a consulta recebida, ela será processada. Caso contrário, a pesquisa continuará normalmente. Para mais informações, consulte Como gerenciar políticas e regras de resposta.

Uma política de resposta é diferente de uma RPZ, que é uma zona DNS normal com dados especialmente formatados que faz com que os resolvedores compatíveis realizem ações especiais. As políticas de resposta não são zonas DNS e são gerenciadas separadamente na API.

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. As alterações nos conjuntos de registros dentro de uma zona são armazenadas separadamente nos conjuntos de registros de recursos, descritos mais adiante neste documento.

Nome de domínio internacionalizado (IDN)

Um nome de domínio internacionalizado (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 do alfabeto latino nos nomes de domínio. Essa conversão é implementada com o Punycode, que é uma representação de caracteres Unicode que usam 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 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.

Subzona delegada

O DNS permite que o proprietário de uma zona delegue um subdomínio a outro servidor de nomes usando registros NS (servidor de nomes). 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.

Conjuntos de registros de recursos

Um conjunto de registros de recursos é uma coleção de registros DNS com o mesmo rótulo, classe e tipo, mas com dados diferentes. Os conjuntos de registros de recursos armazenam o estado atual dos registros DNS que compõem uma zona gerenciada. É possível ler um conjunto de registros de recursos, mas não é possível modificá-lo diretamente. Em vez disso, edite o conjunto de registros de recursos em uma zona gerenciada criando uma solicitação Change na coleção de alterações. Também é possível editar os conjuntos de registros de recursos usando a API ResourceRecordSets. O conjunto 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. Para informações sobre como gerenciar registros, consulte Adicionar, modificar e excluir registros.

Observação: de acordo com as práticas do setor de DNS, os servidores de nomes do Cloud DNS agora são selecionados aleatoriamente na ordem dos conjuntos de registros de recurso quando há vários registros em um conjunto. Esse é um comportamento de DNS normal e se aplica a zonas públicas e privadas do Cloud DNS. Os resolvedores de armazenamento em cache no caminho ainda podem retornar conjuntos de registros como armazenados em cache originalmente e não reorganizar a ordem nas respostas subsequentes.

Alteração do conjunto de registros de recursos

Para alterar um conjunto de registros de recurso, envie uma solicitação Change ou ResourceRecordSets que contenha adições ou exclusões. 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 monotonicamente a cada alteração transacional nos conjuntos de registros de uma zona feita por meio do comando gcloud dns record-sets transaction. No entanto, é possível alterar manualmente o número de série de um registro SOA para um número arbitrário, incluindo uma data no formato ISO 8601, como recomendado na RFC 1912.

Por exemplo, no registro SOA a seguir, é possível mudar o número de série diretamente no console do Google Cloud. Basta inserir o valor desejado no terceiro campo delimitado por espaço do registro:

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

Política de servidor DNS

Uma política de servidor DNS permite acessar serviços de resolução de nomes fornecidos pelo Google Cloud em uma rede VPC com encaminhamento de entrada ou substitui a Ordem da resolução de nomes de VPC a uma política de servidor de saída. Para mais informações, consulte Políticas de servidor DNS.

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

A maioria dos subdomínios são 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 públicas gerenciadas para domínios pai no Cloud DNS antes de criar zonas públicas 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. Para mais informações, consulte Limites do servidor de nomes. 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 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.