Visão geral das zonas DNS

O Cloud DNS oferece suporte a diferentes tipos depúblico e Zonas privadas . Este documento fornece detalhes sobre os diferentes tipos de zonas e quando você pode usar uma ou outra.

Zonas de encaminhamento

As zonas de encaminhamento de DNS na nuvem permitem configurar servidores de nomes de destino para zonas privadas 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 privada do Cloud DNS. Em vez de criar registros dentro da zona, você especifica um conjunto de destinos de encaminhamento. Cada destino de encaminhamento é um nome de domínio totalmente qualificado (FQDN) ou endereço IP de um servidor DNS, localizado na sua rede VPC ou em uma rede local conectada à sua rede VPC pelo Cloud VPN ou Cloud Interconnect.

Alvos de encaminhamento e métodos de roteamento

O Cloud DNS suporta quatro tipos de destinos e oferece métodos de roteamento padrão ou privados para conectividade.

Você pode escolher um dos dois métodos de roteamento a seguir ao adicionar o destino de encaminhamento à zona de encaminhamento:

• Roteamento padrão: encaminha o tráfego por uma rede VPC autorizada ou pela internet, dependendo se o destino de encaminhamento é um endereço IP RFC 1918. Se o destino de encaminhamento for um endereço IP RFC 1918, o Cloud DNS o classifica como Tipo 1 ou Tipo 2 e encaminha as solicitações por uma rede VPC autorizada. Se o destino não for um endereço IP RFC 1918, o Cloud DNS o classifica como Tipo 3 e espera que ele seja acessível pela internet.

• Roteamento privado: sempre roteia o tráfego por uma rede VPC autorizada, independentemente do endereço IP do destino (RFC 1918 ou não). Consequentemente, apenas destinos Tipo 1 e Tipo 2 são suportados.

Se você usar um FQDN para o seu destino de encaminhamento, o seu método de roteamento deverá corresponder ao seu tipo de rede. Quando o seu servidor de nomes de domínio for resolvido para um endereço IP público, você deverá usar o roteamento padrão.

Para acessar um destino de encaminhamento Tipo 1 ou Tipo 2, o Cloud DNS usa rotas na rede VPC autorizada onde o cliente DNS está localizado. Essas rotas definem um caminho seguro para o destino de encaminhamento:

• Para enviar tráfego para destinos do Tipo 1, o Cloud DNS usa rotas de sub-rede criadas automaticamente. Para responder, os destinos do Tipo 1 usam um caminho de roteamento especial para respostas do Cloud DNS .

• Para enviar tráfego para destinos do Tipo 2, o Cloud DNS pode usar rotas dinâmicas personalizadas ou rotas estáticas personalizadas , exceto rotas estáticas personalizadas com tags de rede. Para responder, os destinos de encaminhamento do Tipo 2 usam rotas na sua rede local.

Para obter orientações adicionais sobre os requisitos de rede para destinos Tipo 1 e Tipo 2, consulte Requisitos de rede de destino de encaminhamento .

Para acessar um destino de encaminhamento Tipo 4, o Cloud DNS primeiro resolve o nome de domínio e, em seguida, usa o método de roteamento da rede de origem. Por exemplo, se subdomain.example.com for resolvido para um endereço IP de um sistema local conectado à rede VPC autorizada a consultar a zona de encaminhamento por meio do Cloud VPN, ele usará as mesmas regras de roteamento de um destino de encaminhamento Tipo 2.

Ao usar um FQDN como destino de encaminhamento, você só pode usar um. O destino de encaminhamento pode resolver até 50 endereços IP.

Proibido encaminhamento de endereços IP de destino

Você não pode usar os seguintes endereços IP para destinos de encaminhamento do Cloud DNS:

• 169.254.0.0/16
• 192.0.0.0/24
• 192.0.2.0/24
• 192.88.99.0/24
• 198.51.100.0/24
• 203.0.113.0/24
• 224.0.0.0/4
• 240.0.0.0/4
• ::1/128
• ::/128
• 2001:db8::/32
• fe80::/10
• fec0::/10
• ff00::/8

Encaminhamento da ordem de seleção do alvo

O Cloud DNS permite que você configure uma lista de destinos de encaminhamento para uma zona de encaminhamento.

Ao configurar dois ou mais destinos de encaminhamento, o Cloud DNS usa um algoritmo interno para selecionar um destino de encaminhamento. Esse algoritmo classifica cada destino de encaminhamento.

Quando você usa um FQDN como destino de encaminhamento, o Cloud DNS resolve o nome de domínio em um conjunto de até 50 endereços IP e aplica o mesmo algoritmo a esses endereços IP.

Para processar uma solicitação, o Cloud DNS primeiro tenta uma consulta DNS contatando o destino de encaminhamento com a classificação mais alta. Se esse servidor não responder, o Cloud DNS repete a solicitação para o próximo destino de encaminhamento com a classificação mais alta. Se nenhum destino de encaminhamento responder, o Cloud DNS sintetiza uma resposta SERVFAIL .

O algoritmo de classificação é automático e os seguintes fatores aumentam a classificação de um alvo de encaminhamento:

• Quanto maior o número de respostas DNS bem-sucedidas processadas pelo destino de encaminhamento. Respostas DNS bem-sucedidas incluem respostas NXDOMAIN.
• Quanto menor a latência (tempo de ida e volta) para comunicação com o destino de encaminhamento.

Usar zonas de encaminhamento

VMs em uma rede VPC podem usar uma zona de encaminhamento de Cloud DNS nos seguintes casos:

• A rede VPC foi autorizada a usar a zona de encaminhamento do Cloud DNS. Para usar a zona de encaminhamento, você pode autorizar várias redes VPC no mesmo projeto ou em vários projetos, desde que as redes VPC estejam na mesma organização.

• O sistema operacional convidado de cada VM na rede VPC usa o servidor de metadados da VM 169.254.169.254 como seu servidor de nomes.

Se você usar um FQDN como servidor de nomes de destino, revise os seguintes itens:

• Você só pode ter um único destino de encaminhamento.
• A resolução de destino do FQDN por meio de outra zona de encaminhamento não é suportada.
• Você não pode usar um FQDN como um servidor de nomes alternativo em políticas de servidor.
• Um alvo FQDN pode ser resolvido para até 50 endereços IP associados. Quaisquer endereços resolvidos acima de 50 são truncados.

Zonas de encaminhamento sobrepostas

Como as zonas de encaminhamento do Cloud DNS são um tipo de zona privada gerenciada pelo Cloud DNS, você pode criar várias zonas que se sobrepõem. As VMs configuradas conforme descrito anteriormente resolvem um registro de acordo com a ordem de resolução de nomes , usando a zona com o sufixo mais longo. Para obter mais informações, consulte Zonas sobrepostas .

Zonas de cache e encaminhamento

O Cloud DNS armazena em cache as respostas das consultas enviadas às zonas de encaminhamento do Cloud DNS. O Cloud DNS mantém um cache das respostas de destinos de encaminhamento acessíveis pelo menor dos seguintes períodos:

• 60 segundos
• A duração do tempo de vida do registro (TTL)

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 peering em vez disso

O Cloud DNS não pode usar o roteamento transitivo para se conectar a um destino de encaminhamento. Para ilustrar uma configuração inválida, considere o seguinte cenário:

• Você usou o Cloud VPN ou o Cloud Interconnect para conectar uma rede local a uma rede VPC chamada vpc-net-a .

• Você usou o VPC Network Peering para conectar a rede VPC vpc-net-a à vpc-net-b . Você configurou vpc-net-a para exportar rotas personalizadas e vpc-net-b para importá-las.

• Você criou uma zona de encaminhamento cujos alvos de encaminhamento estão localizados na rede local à qual vpc-net-a está conectado. Você autorizou vpc-net-b a usar essa zona de encaminhamento.

A resolução de um registro em uma zona atendida pelos destinos de encaminhamento falha neste cenário, mesmo que haja conectividade de vpc-net-b com sua rede local. Para demonstrar essa falha, execute os seguintes testes em uma VM em vpc-net-b :

• Consulte o servidor de metadados 169.254.169.254 da VM para obter um registro definido na zona de encaminhamento. Esta consulta falha (previsivelmente) porque o Cloud DNS não oferece suporte ao roteamento transitivo para destinos de encaminhamento. Para usar uma zona de encaminhamento, a VM precisa ser configurada para usar seu servidor de metadados.

• Consulte o destino de encaminhamento diretamente para o mesmo registro. Embora o Cloud DNS não use esse caminho, esta consulta demonstra que a conectividade transitiva é bem-sucedida.

Você pode usar uma zona de peering de DNS do Cloud para corrigir esse cenário inválido:

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

Você pode executar essas etapas em qualquer ordem. Após a conclusão, as instâncias do Compute Engine em vpc-net-a e vpc-net-b poderão consultar os destinos de encaminhamento locais.

Para obter informações sobre como criar zonas de encaminhamento, consulte Criar uma zona de encaminhamento .

Zonas de peering

Uma zona de peering é uma zona privada do Cloud DNS que permite enviar solicitações de DNS entre zonas do Cloud DNS em diferentes redes VPC. Por exemplo, um provedor de software como serviço (SaaS) pode conceder aos clientes acesso aos seus registros DNS gerenciados no Cloud DNS.

Para fornecer peering de DNS, você precisa criar uma zona de peering privada do Cloud DNS e configurá-la para realizar pesquisas de DNS em uma rede VPC onde os registros do namespace dessa zona estejam disponíveis. A rede VPC onde a zona de peering de DNS realiza pesquisas é chamada de rede produtora de DNS .

A zona de peering é visível apenas para redes VPC selecionadas durante a configuração da zona. A rede VPC autorizada a usar a zona de peering é chamada de rede de consumidor DNS .

Depois Google Cloud Quando os recursos na rede de consumidores DNS são autorizados, eles podem realizar buscas por registros no namespace da zona de peering como se estivessem na rede de produtores DNS. As buscas por registros no namespace da zona de peering seguem a ordem de resolução de nomes da rede de produtores DNS.

Portanto, Google Cloud recursos na rede de consumidores de DNS podem consultar registros no namespace da zona nas seguintes fontes disponíveis na rede de produtores de DNS:

• Zonas privadas gerenciadas pelo Cloud DNS autorizadas para uso pela rede do produtor de DNS.
• Zonas de encaminhamento gerenciadas pelo Cloud DNS autorizadas para uso pela rede do produtor de DNS.
• Nomes DNS internos do Compute Engine na rede do produtor DNS.
• Um servidor de nomes alternativo, se uma política de servidor de saída tiver sido configurada na rede do produtor de DNS.

Com o peering de DNS, você pode ter uma rede ( rede de consumidor de DNS ) encaminhando solicitações de DNS para outra rede ( rede de produtor de DNS ), que então executa pesquisas de DNS.

Limitações e pontos-chave do peering de DNS

Tenha em mente o seguinte ao configurar o peering de DNS:

• O peering de DNS é um relacionamento unilateral. Ele permite Google Cloud recursos na rede do consumidor DNS para consultar registros no namespace da zona de peering como se o Google Cloud os recursos estavam na rede de produtores de DNS.
• As redes produtoras e consumidoras de DNS devem ser redes VPC.
• Embora as redes de produtores e consumidores de DNS normalmente façam parte da mesma organização, o peering de DNS entre organizações também é suportado.
• O peering de DNS e o peering de rede VPC são serviços diferentes. O peering de rede VPC não compartilha informações de DNS automaticamente. O peering de DNS pode ser usado com o peering de rede VPC, mas o peering de rede VPC não é necessário para o peering de DNS.
• O peering DNS transitivo é suportado, mas apenas por meio de um único salto transitivo. Em outras palavras, no máximo três redes VPC (com a rede do meio sendo o salto transitivo) podem estar envolvidas. Por exemplo, você pode criar uma zona de peering em vpc-net-a com destino vpc-net-b e, em seguida, criar uma zona de peering em vpc-net-b com destino vpc-net-c .
• Se você estiver usando o peering de DNS para direcionar uma zona de encaminhamento enquanto o roteamento dinâmico global estiver desabilitado na rede VPC produtora, a rede VPC de destino com a zona de encaminhamento deverá conter uma VM, um anexo de VLAN ou um túnel de VPN na nuvem localizado na mesma região que a VM de origem que usa a zona de peering de DNS. Para obter detalhes sobre essa limitação, consulte "O encaminhamento de consultas de VMs em uma rede VPC consumidora para uma rede VPC produtora não está funcionando" .

Para obter instruções sobre como criar uma zona de peering, consulte Criar uma zona de peering .

Zonas de pesquisa reversa gerenciadas

Uma zona de pesquisa reversa gerenciada é uma zona privada com um atributo especial que instrui o Cloud DNS a executar uma pesquisa PTR nos dados DNS do Compute Engine.

Registros PTR para endereços RFC 1918 em zonas privadas

Para realizar pesquisas reversas com registros PTR personalizados para endereços RFC 1918 , você deve criar uma zona privada do Cloud DNS que seja pelo menos tão específica quanto uma das zonas de exemplo a seguir. Isso é consequência da correspondência de sufixo mais longa descrita em Ordem de resolução de nomes .

Exemplos de zonas incluem o seguinte:

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

Se você criar uma zona privada do Cloud DNS para endereços RFC 1918, os registros PTR personalizados criados para VMs nessa zona serão substituídos pelos registros PTR criados automaticamente pelo DNS interno . Isso ocorre porque os registros PTR do DNS interno 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 VM cujo endereço IP é 10.1.1.1 :

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

Neste exemplo, o registro PTR na sua zona privada do Cloud DNS para in-addr.arpa. é ignorado. Quaisquer consultas PTR para 1.1.1.10.in-addr.arpa. são respondidas pela zona DNS interna mais específica 10.in-addr.arpa.

Para substituir os registros PTR de DNS internos criados automaticamente para 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 substituirá o gerado automaticamente: 1.1.1.10.in-addr.arpa. -> test.example.domain .

Se você precisar substituir apenas uma parte de um bloco de rede, poderá criar zonas privadas de DNS reverso mais específicas. Por exemplo, uma zona privada para 5.10.in-addr.arpa. pode ser usada para armazenar registros PTR que substituem quaisquer registros PTR de DNS interno criados automaticamente para VMs com endereços IP no intervalo de endereços 10.5.0.0/16 .

Para obter instruções sobre como criar uma zona de pesquisa reversa gerenciada, consulte Criar uma zona de pesquisa reversa gerenciada .

Zonas sobrepostas

Duas zonas se sobrepõem quando o nome de domínio de origem de uma zona é idêntico ou é um subdomínio da origem da outra zona. Por exemplo:

• Uma zona para gcp.example.com e outra zona 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 .

Regras para zonas sobrepostas

O Cloud DNS aplica as seguintes regras para zonas sobrepostas:* Zonas públicas sobrepostas não são permitidas nos mesmos servidores de nomes do Cloud DNS. Ao criar zonas sobrepostas, o Cloud DNS tenta colocá-las em servidores de nomes diferentes. Se isso não for possível, o Cloud DNS não consegue criar a zona sobreposta.

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

• Zonas privadas com escopo para diferentes redes VPC podem se sobrepor. Por exemplo, duas redes VPC podem ter, cada uma, uma VM de banco de dados chamada database.gcp.example.com em uma zona gcp.example.com . Consultas para database.gcp.example.com recebem respostas diferentes de acordo com os registros de zona definidos na zona autorizada para cada rede VPC.

• Duas zonas privadas que foram autorizadas a serem acessadas pela mesma rede VPC não podem ter origens idênticas, a menos que uma zona seja um subdomínio da outra. O servidor de metadados usa a correspondência de sufixo mais longo para determinar qual origem consultar para registros em uma determinada zona.

Exemplos de resolução de consulta

Google Cloud resolve zonas do Cloud DNS conforme descrito em Ordem de resolução de nomes . Ao determinar a zona a ser consultada para um determinado registro, o Cloud DNS tenta encontrar uma zona que corresponda ao máximo possível do registro solicitado (correspondência com o sufixo mais longo).

A menos que você tenha especificado um servidor de nomes alternativo em uma política de servidor de saída, Google Cloud primeiras tentativas de encontrar um registro em uma zona privada (ou zona de encaminhamento ou zona de peering) autorizada para sua rede VPC antes de procurar o registro em uma zona pública.Os exemplos a seguir ilustram a ordem que o servidor de metadados usa ao consultar registros DNS. Para cada um desses exemplos, suponha que você tenha criado duas zonas privadas, gcp.example.com e dev.gcp.example.com , e autorizado o acesso a elas na mesma rede VPC. Google Cloudlida com as consultas DNS de 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. (observe o ponto final) porque não há uma zona privada para example.com autorizada para a rede VPC. Use dig de uma VM do Compute Engine para consultar o servidor de nomes padrão da VM:

  dig myapp.example.com.
  

  Para obter detalhes, consulte Consultar o nome DNS usando o servidor de metadados .

• O servidor de metadados resolve o registro myapp.gcp.example.com usando a zona privada autorizada gcp.example.com porque gcp.example.com é o sufixo comum mais longo entre o nome do registro solicitado e as zonas privadas autorizadas disponíveis. NXDOMAIN será retornado se não houver nenhum registro para myapp.gcp.example.com definido na zona privada gcp.example.com , mesmo que haja 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 privada autorizada dev.gcp.example.com . NXDOMAIN será retornado se não houver nenhum registro para myapp.dev.gcp.example.com na zona dev.gcp.example.com , mesmo se houver um registro para myapp.dev.gcp.example.com em outra zona privada ou pública .

• Consultas para myapp.prod.gcp.example.com são resolvidas de acordo com registros na zona privada gcp.example.com porque gcp.example.com é o sufixo comum mais longo entre o registro DNS solicitado e as zonas privadas disponíveis.

Exemplo de DNS de horizonte dividido

Você pode usar uma combinação de zonas públicas e privadas em uma configuração de DNS de horizonte dividido. Zonas privadas permitem definir respostas diferentes a uma consulta para o mesmo registro quando a consulta se origina de uma VM dentro de uma rede VPC autorizada. O DNS de horizonte dividido é útil sempre que você precisa fornecer registros diferentes para as mesmas consultas DNS, dependendo da rede VPC de origem.

Considere o seguinte exemplo de horizonte dividido:

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

Na zona privada, você criou um único registro, conforme mostrado na tabela a seguir.

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

As seguintes consultas são resolvidas conforme descrito:

• Uma consulta para myrecord1.gcp.example.com de uma VM na sua rede VPC retorna 10.128.1.35 .
• Uma consulta para myrecord1.gcp.example.com na Internet retorna 104.198.6.142 .
• Uma consulta para myrecord2.gcp.example.com de uma VM na sua rede VPC retorna um erro NXDOMAIN porque não há nenhum registro para myrecord2.gcp.example.com na zona privada gcp.example.com .
• Uma consulta para myrecord2.gcp.example.com na Internet retorna 104.198.7.145 .

Ligação entre projetos

A vinculação entre projetos permite que você mantenha a propriedade do namespace DNS do projeto de serviço independente da propriedade do namespace DNS de toda a rede VPC.

Uma configuração típica de VPC compartilhada tem projetos de serviço que assumem a propriedade de um aplicativo ou serviço de máquina virtual (VM), enquanto o projeto host assume a propriedade da rede da VPC e da infraestrutura de rede. Frequentemente, um namespace DNS é criado a partir do namespace da rede da VPC para corresponder aos recursos do projeto de serviço. Para essa configuração, pode ser mais fácil delegar a administração do namespace DNS de cada projeto de serviço aos administradores de cada projeto (que geralmente são departamentos ou empresas diferentes). A vinculação entre projetos permite separar a propriedade do namespace DNS do projeto de serviço da propriedade do namespace DNS de toda a rede da VPC.

A figura a seguir mostra uma configuração típica de VPC compartilhada com peering de DNS.

A figura a seguir mostra uma configuração usando vinculação entre projetos. O Cloud DNS permite que cada projeto de serviço crie e possua suas próprias zonas DNS, mas ainda as vincule à rede compartilhada que o projeto host possui. Isso proporciona maior autonomia e um limite de permissão mais preciso para a administração de zonas DNS.

A vinculação entre projetos fornece o seguinte:

• Os administradores e usuários do projeto de serviço podem criar e gerenciar suas próprias zonas DNS.
• Você não precisa criar uma rede VPC de espaço reservado.
• Os administradores do projeto host não precisam gerenciar o projeto de serviço.
• As funções do IAM ainda se aplicam ao nível do projeto.
• Todas as zonas DNS estão diretamente associadas à rede VPC compartilhada.
• A resolução de DNS "any-to-any" está prontamente disponível. Qualquer VM na rede VPC compartilhada pode resolver zonas associadas.
• Não há limite de salto transitivo. Você pode gerenciá-lo em um design hub-and-spoke.

Para obter instruções sobre como criar uma zona com a vinculação entre projetos habilitada, consulte Criar uma zona de vinculação entre projetos .

Zonas DNS Zonal Cloud

O DNS Zonal Cloud permite que você crie zonas DNS privadas que têm como escopo um Google Cloud somente zona. As zonas DNS Zonal Cloud são criadas para o GKE quando você escolhe um escopo de cluster .

O serviço DNS padrão na nuvem é global por natureza e os nomes DNS são visíveis globalmente na sua rede VPC. Esta configuração expõe seu serviço a interrupções globais. O DNS Zonal na Nuvem é um novo serviço DNS privado na Nuvem que existe em cada Google Cloud zona. O domínio de falha está contido dentro dessa Google Cloud zona. As zonas privadas do DNS Zonal Cloud não são afetadas quando ocorrem interrupções globais. Qualquer Google Cloud interrupções zonais afetam apenas aquela zona específica Google Cloud zona e zonas de DNS em nuvem dentro dessa Google Cloud zona. Observe que qualquer recurso criado em um serviço zonal só é visível para aquele Google Cloudzona.

Para saber como configurar uma zona com escopo de cluster zonal do Cloud DNS, consulte Configurar uma zona com escopo de cluster zonal do GKE .

Suporte DNS zonal em nuvem

A tabela a seguir lista os recursos e funcionalidades do Cloud DNS suportados pelos serviços zonais do Cloud DNS.

¹ O DNS de nuvem zonal oferece suporte apenas ao encaminhamento de zonas com escopo para um cluster do GKE.

² O controlador do GKE substitui quaisquer alterações nos registros quando é reiniciado.

Faturamento para zonas DNS zonais do Cloud

O faturamento de zonas e políticas de resposta do Cloud DNS zonais funciona da mesma forma que suas contrapartes globais.

O que vem a seguir

• Para trabalhar com zonas gerenciadas, consulte Criar, modificar e excluir zonas .
• Para encontrar soluções para problemas comuns que você pode encontrar ao usar o Cloud DNS, consulte Solução de problemas .
• Para obter uma visão geral do Cloud DNS, consulte Visão geral do Cloud DNS .