O Cloud DNS suporta diferentes tipos de zonas públicas e privadas. Este documento fornece detalhes sobre os diferentes tipos de zonas e quando pode usar um ou outro.
Zonas de encaminhamento
As zonas de encaminhamento do Cloud DNS permitem-lhe configurar servidores de nomes de destino para zonas privadas específicas. A utilização de uma zona de encaminhamento é uma forma de implementar o encaminhamento de DNS de saída a partir da sua rede de VPC.
Uma zona de encaminhamento do Cloud DNS é um tipo especial de zona privada do Cloud DNS. Em vez de criar registos na zona, especifica um conjunto de destinos de encaminhamento. Cada destino de encaminhamento é um nome de domínio totalmente qualificado (FQDN) ou um endereço IP de um servidor DNS, localizado na sua rede VPC ou numa rede no local ligada à sua rede VPC através do Cloud VPN ou do Cloud Interconnect.
Destinos de encaminhamento e métodos de encaminhamento
O Cloud DNS suporta quatro tipos de destinos e oferece métodos de encaminhamento padrão ou privados para a conetividade.
| Alvo de encaminhamento | Descrição | Suporte de encaminhamento padrão | O encaminhamento privado suporta | Origem dos pedidos |
|---|---|---|---|---|
| Tipo 1 | Um endereço IP interno de uma Google Cloud VM ou um Network Load Balancer de encaminhamento interno na mesma rede VPC que está autorizado a usar a zona de encaminhamento. | Apenas endereços IP RFC 1918: o tráfego é sempre encaminhado através de uma rede VPC autorizada. | Qualquer endereço IP interno, como um endereço privado RFC 1918, um endereço IP privado não RFC 1918 ou um endereço IP externo reutilizado de forma privada, exceto um endereço IP de destino de encaminhamento proibido —tráfego sempre encaminhado através de uma rede VPC autorizada. | 35.199.192.0/19 |
| Tipo 2 | Um endereço IP de um sistema no local, ligado à rede VPC autorizada a consultar a zona de encaminhamento, através do Cloud VPN ou do Cloud Interconnect. | Apenas endereços IP RFC 1918: o tráfego é sempre encaminhado através de uma rede VPC autorizada. | Qualquer endereço IP interno, como um endereço privado RFC 1918, um endereço IP privado não RFC 1918 ou um endereço IP externo reutilizado de forma privada, exceto um endereço IP de destino de encaminhamento proibido — tráfego sempre encaminhado através de uma rede VPC autorizada. | 35.199.192.0/19 |
| Tipo 3 | Um endereço IP externo de um servidor de nomes DNS acessível à Internet ou o endereço IP externo de um Google Cloud recurso; por exemplo, o endereço IP externo de uma VM n outra rede VPC. | Apenas endereços IP externos encaminháveis pela Internet: tráfego sempre encaminhado para a Internet ou para o endereço IP externo de um Google Cloud recurso. | O encaminhamento privado não é suportado. Certifique-se de que o encaminhamento privado não está selecionado. | Intervalos de origem do DNS público da Google |
| Tipo 4 | Um nome de domínio totalmente qualificado de um servidor de nomes de destino que pode ser resolvido para endereços IPv4 e IPv6 através da ordem de resolução da rede VPC. | Consoante a rede do destino de encaminhamento resolvido, o tráfego é encaminhado
de uma das seguintes formas:
|
Consoante a rede do destino de encaminhamento resolvido, o tráfego é encaminhado através de qualquer endereço IP interno, como um endereço privado RFC 1918, um endereço IP privado não RFC 1918 ou um endereço IP externo reutilizado de forma privada, exceto um endereço IP de destino de encaminhamento proibido. O tráfego é sempre encaminhado através de uma rede VPC autorizada. Se o servidor de nomes DNS tiver sido resolvido para um endereço IP externo acessível à Internet ou ao endereço IP externo, o encaminhamento privado não é suportado. |
|
Pode escolher um dos dois seguintes métodos de encaminhamento quando adiciona o destino de encaminhamento à zona de encaminhamento:
Encaminhamento padrão: encaminha o tráfego através de uma rede VPC autorizada ou através da Internet com base no facto de o destino de encaminhamento ser um endereço IP RFC 1918. Se o destino de encaminhamento for um endereço IP RFC 1918, o Cloud DNS classifica o destino como um destino de tipo 1 ou tipo 2 e encaminha os pedidos através de uma rede VPC autorizada. Se o destino não for um endereço IP RFC 1918, o Cloud DNS classifica o destino como Tipo 3 e espera que o destino seja acessível através da Internet.
Encaminhamento privado: encaminha sempre o tráfego através de uma rede VPC autorizada, independentemente do endereço IP do destino (RFC 1918 ou não). Consequentemente, apenas são suportados alvos do tipo 1 e do tipo 2.
Se usar um FQDN para o destino de encaminhamento, o método de encaminhamento tem de corresponder ao tipo de rede. Quando o servidor de nomes do seu domínio é resolvido para um endereço IP público, tem de usar o encaminhamento padrão.
Para aceder a um destino de encaminhamento do Tipo 1 ou do Tipo 2, o Cloud DNS usa rotas na rede VPC autorizada onde o cliente DNS está localizado. Estas rotas definem um caminho seguro para o destino de encaminhamento:
Para enviar tráfego para alvos do tipo 1, o Cloud DNS usa rotas de sub-rede criadas automaticamente. Para responder, os alvos do tipo 1 usam um caminho de encaminhamento especial para respostas do Cloud DNS.
Para enviar tráfego para alvos do tipo 2, o Cloud DNS pode usar rotas dinâmicas personalizadas ou rotas estáticas personalizadas, exceto rotas estáticas personalizadas com etiquetas de rede. Para responder, os destinos de encaminhamento do tipo 2 usam rotas na sua rede no local.
Para orientações adicionais acerca dos requisitos de rede para alvos do tipo 1 e do tipo 2, consulte os requisitos de rede de encaminhamento de alvos.
Para aceder a um destino de encaminhamento do tipo 4, o Cloud DNS resolve primeiro o nome do domínio e, em seguida, usa o método de encaminhamento da rede de origem. Por exemplo, se subdomain.example.com for resolvido para um endereço IP de um sistema no local que esteja ligado à rede VPC autorizada a consultar a zona de encaminhamento através da Cloud VPN, usa as mesmas regras de encaminhamento que um destino de encaminhamento do tipo 2.
Quando usar um FQDN como destino de encaminhamento, só pode usar um. O destino de encaminhamento pode ser resolvido para até 50 endereços IP.
Endereços IP de destino de encaminhamento proibidos
Não pode usar os seguintes endereços IP para destinos de encaminhamento do Cloud DNS:
169.254.0.0/16192.0.0.0/24192.0.2.0/24192.88.99.0/24198.51.100.0/24203.0.113.0/24224.0.0.0/4240.0.0.0/4::1/128::/1282001:db8::/32fe80::/10fec0::/10ff00::/8
Ordem de seleção do destino de encaminhamento
O Cloud DNS permite-lhe configurar uma lista de destinos de encaminhamento para uma zona de encaminhamento.
Quando configura dois ou mais destinos de encaminhamento, o Cloud DNS usa um algoritmo interno para selecionar um destino de encaminhamento. Este algoritmo classifica cada destino de encaminhamento.
Quando usa um FQDN como destino de encaminhamento, o Cloud DNS resolve o nome do domínio num conjunto de até 50 endereços IP e, em seguida, aplica o mesmo algoritmo a esses endereços IP.
Para processar um pedido, o Cloud DNS tenta primeiro uma consulta DNS contactando o destino de encaminhamento com a classificação mais elevada. Se esse servidor não responder, o Cloud DNS repete o pedido para o destino de encaminhamento com a classificação mais elevada seguinte. 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 destino de encaminhamento:
- Quanto maior for o número de respostas de DNS bem-sucedidas processadas pelo destino de encaminhamento. As respostas DNS com êxito incluem respostas NXDOMAIN.
- Quanto menor for a latência (tempo de resposta) para comunicar com o destino de encaminhamento.
Use zonas de encaminhamento
As VMs numa rede VPC podem usar uma zona de encaminhamento do 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, 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 operativo convidado de cada VM na rede VPC usa o servidor de metadados da VM
169.254.169.254como o respetivo servidor de nomes.
Se usar um FQDN como servidor de nomes de destino, reveja os seguintes itens:
- Só pode ter um único destino de encaminhamento.
- A resolução de destino FQDN através de outra zona de encaminhamento não é suportada.
- Não pode usar um FQDN como um servidor de nomes alternativo em políticas de servidor.
- Um destino FQDN pode ser resolvido para até 50 endereços IP associados. Todos os endereços resolvidos com mais de 50 caracteres são truncados.
Zonas de encaminhamento sobrepostas
Uma vez que as zonas de encaminhamento do Cloud DNS são um tipo de zona privada gerida do Cloud DNS, pode criar várias zonas que se sobreponham. As VMs configuradas conforme descrito anteriormente resolvem um registo de acordo com a ordem de resolução de nomes, usando a zona com o sufixo mais longo. Para mais informações, consulte o artigo Zonas sobrepostas.
Zonas de encaminhamento e colocação em cache
O Cloud DNS armazena em cache as respostas para consultas enviadas para zonas de encaminhamento do Cloud DNS. O Cloud DNS mantém uma cache de respostas de destinos de encaminhamento acessíveis para o período mais curto dos seguintes intervalos de tempo:
- 60 segundos
- A duração do tempo de vida (TTL) do registo
Quando todos os destinos de encaminhamento de uma zona de encaminhamento ficam inacessíveis, o Cloud DNS mantém a respetiva cache dos registos pedidos anteriormente nessa zona durante o TTL de cada registo.
Quando usar a interligação
O Cloud DNS não pode usar o encaminhamento transitivo para se ligar a um destino de encaminhamento. Para ilustrar uma configuração inválida, considere o seguinte cenário:
Usou o Cloud VPN ou o Cloud Interconnect para ligar uma rede no local a uma rede VPC denominada
vpc-net-a.Usou o intercâmbio da rede da VPC para ligar a rede da VPC
vpc-net-aavpc-net-b. Configurouvpc-net-apara exportar rotas personalizadas evpc-net-bpara as importar.Criou uma zona de encaminhamento cujos destinos de encaminhamento estão localizados na rede no local à qual o
vpc-net-aestá ligado. Autorizouvpc-net-ba usar essa zona de encaminhamento.
A resolução de um registo numa zona publicada pelos destinos de encaminhamento falha neste cenário, mesmo que exista conetividade de vpc-net-b para a sua rede no local. Para demonstrar esta falha, faça os seguintes testes a partir de uma VM em vpc-net-b:
Consultar o servidor de metadados da VM
169.254.169.254para um registo definido na zona de encaminhamento. Esta consulta falha (como esperado) porque o Cloud DNS não suporta o encaminhamento transitivo para destinos de encaminhamento. Para usar uma zona de encaminhamento, uma VM tem de ser configurada para usar o respetivo servidor de metadados.Consultar o destino de encaminhamento diretamente para esse mesmo registo. Embora o Cloud DNS não use este caminho, esta consulta demonstra que a conetividade transitiva é bem-sucedida.
Pode usar uma zona de peering do Cloud DNS para corrigir este cenário inválido:
- Crie uma zona de peering do Cloud DNS autorizada para
vpc-net-bque tem como destinovpc-net-a. - Crie uma zona de encaminhamento autorizada para
vpc-net-acujos destinos de encaminhamento sejam servidores de nomes no local.
Pode realizar estes passos por qualquer ordem. Depois de concluir estes passos, as instâncias do Compute Engine em vpc-net-a e vpc-net-b podem consultar os destinos de encaminhamento no local.
Para ver informações sobre como criar zonas de encaminhamento, consulte o artigo Crie uma zona de encaminhamento.
Zonas de intercâmbio
Uma zona de intercâmbio é uma zona privada do Cloud DNS que lhe permite enviar pedidos de DNS entre zonas do Cloud DNS em diferentes redes da VPC. Por exemplo, um fornecedor de software como serviço (SaaS) pode dar aos clientes acesso aos respetivos registos de DNS geridos no Cloud DNS.
Para fornecer o peering de DNS, tem de criar uma zona de peering privado do Cloud DNS e configurá-la para realizar pesquisas de DNS numa rede VPC onde os registos do espaço de nomes dessa zona estão disponíveis. A rede VPC onde a zona de peering de DNS realiza procuras é denominada rede de produtor de DNS.
A zona de peering só é visível para redes VPC que são selecionadas durante a configuração da zona. A rede VPC autorizada a usar a zona de peering é denominada rede de consumidor de DNS.
Depois de Google Cloud os recursos na rede de consumidor de DNS serem autorizados, podem realizar pesquisas de registos no espaço de nomes da zona de peering como se estivessem na rede de produtor de DNS. As pesquisas de registos no espaço de nomes da zona de peering seguem a ordem de resolução de nomes da rede do produtor de DNS.
Por conseguinte,os recursos na rede de consumo do DNS podem procurar registos no espaço de nomes da zona nas seguintes origens disponíveis na rede de produção do DNS: Google Cloud
- Zonas privadas geridas do Cloud DNS autorizadas para utilização pela rede do produtor de DNS.
- Zonas de encaminhamento geridas do Cloud DNS autorizadas para utilização pela rede do produtor de DNS.
- Nomes DNS internos do Compute Engine na rede do produtor de DNS.
- Um servidor de nomes alternativo, se tiver sido configurada uma política de servidor de saída na rede do produtor de DNS.
Com o peering de DNS, pode ter uma rede (rede de consumidor de DNS) que encaminha pedidos de DNS para outra rede (rede de produtor de DNS), que, em seguida, realiza procuras de DNS.
Limitações e pontos principais da interligação de DNS
Tenha em atenção o seguinte ao configurar a interligação de DNS:
- A interligação de DNS é uma relação unidirecional. Permite que os recursos Google Cloud na rede de consumidor de DNS procurem registos no espaço de nomes da zona de peering como se os recursos Google Cloud estivessem na rede de produtor de DNS.
- As redes de produtores e consumidores de DNS têm de ser redes VPC.
- Embora as redes de produtores e consumidores de DNS façam normalmente parte da mesma organização, o peering de DNS entre organizações também é suportado.
- O intercâmbio de DNS e o intercâmbio da rede da VPC são serviços diferentes. O intercâmbio da rede da VPC não partilha automaticamente informações de DNS. O intercâmbio de DNS pode ser usado com o intercâmbio das redes da VPC, mas o intercâmbio das redes da VPC não é necessário para o intercâmbio de DNS.
- O intercâmbio de DNS transitivo é suportado, mas apenas através de um único salto transitivo.
Por outras palavras, não podem estar envolvidas mais de três redes VPC (sendo a rede no meio o salto transitivo). Por exemplo, pode criar uma zona de intercâmbio em
vpc-net-aque segmentevpc-net-be, em seguida, criar uma zona de intercâmbio emvpc-net-bque segmentevpc-net-c. - Se estiver a usar o peering de DNS para segmentar uma zona de encaminhamento enquanto o encaminhamento dinâmico global está desativado na rede VPC do produtor, a rede VPC de destino com a zona de encaminhamento tem de 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 ver detalhes sobre esta limitação, consulte o artigo O encaminhamento de consultas de VMs numa rede VPC de consumidor para uma rede VPC de produtor não está a funcionar.
Para obter instruções sobre como criar uma zona de peering, consulte o artigo Crie uma zona de peering.
Zonas reverse lookup geridas
Uma zona de procura inversa gerida é uma zona privada com um atributo especial que indica ao Cloud DNS para fazer uma procura PTR em relação aos dados de DNS do Compute Engine.
Registos PTR para endereços RFC 1918 em zonas privadas
Para realizar pesquisas inversas com registos PTR personalizados para endereços RFC 1918, tem de criar uma zona privada do Cloud DNS que seja, pelo menos, tão específica quanto uma das seguintes zonas de exemplo. Isto é uma consequência da correspondência de sufixos mais longos descrita na ordem de resolução de nomes.
Alguns exemplos de zonas:
10.in-addr.arpa.168.192.in-addr.arpa.16.172.in-addr.arpa.,17.172.in-addr.arpa., ... através de31.172.in-addr.arpa.
Se criar uma zona privada do Cloud DNS para endereços RFC 1918, os registos PTR personalizados que criar para VMs nessa zona são substituídos pelos registos PTR que o DNS interno cria automaticamente. Isto deve-se ao facto de os registos PTR de DNS internos serem criados na lista anterior de zonas mais específicas.
Por exemplo, suponha que cria uma zona privada gerida para in-addr.arpa. com o seguinte registo 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 registo PTR na sua zona privada do Cloud DNS para
in-addr.arpa. é ignorado. Todas as consultas PTR para 1.1.1.10.in-addr.arpa. são respondidas pela zona DNS interna 10.in-addr.arpa. mais específica.
Para substituir os registos PTR de DNS internos criados automaticamente para VMs, certifique-se de que cria os seus registos PTR personalizados numa zona privada que seja, pelo menos, tão específica quanto uma das zonas apresentadas nesta secção.
Por exemplo, se criar o seguinte registo PTR numa zona privada para
10.in-addr.arpa., o seu registo substitui o registo gerado automaticamente: 1.1.1.10.in-addr.arpa. -> test.example.domain.
Se só precisar de substituir uma parte de um bloco de rede, pode criar zonas privadas de DNS do Google Cloud mais específicas. Por exemplo, uma zona privada para 5.10.in-addr.arpa. pode ser usada para conter registos PTR que substituem quaisquer registos PTR de DNS internos que são 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 inversa gerida, consulte o artigo Crie uma zona de pesquisa inversa gerida.
Zonas sobrepostas
Duas zonas sobrepõem-se entre si 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.come outra zona paragcp.example.comsobrepõem-se porque os nomes de domínio são idênticos. - Uma zona para
dev.gcp.example.come uma zona paragcp.example.comsobrepõem-se porquedev.gcp.example.comé um subdomínio degcp.example.com.
Regras para zonas sobrepostas
O Cloud DNS aplica as seguintes regras para zonas sobrepostas: * Não são permitidas zonas públicas sobrepostas nos mesmos servidores de nomes do Cloud DNS. Quando cria zonas sobrepostas, o Cloud DNS tenta colocá-las em servidores de nomes diferentes. Se tal não for possível, o Cloud DNS não consegue criar a zona sobreposta.
- Uma zona privada pode sobrepor-se a qualquer zona pública.
As zonas privadas com âmbito para diferentes redes VPC podem sobrepor-se entre si. Por exemplo, duas redes de VPC podem ter cada uma uma VM de base de dados com o nome
database.gcp.example.comnuma zonagcp.example.com. As consultas paradatabase.gcp.example.comrecebem respostas diferentes de acordo com os registos de zonas definidos na zona autorizada para cada rede de VPC.Duas zonas privadas que foram autorizadas a serem acessíveis a partir da 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 que origem consultar para registos numa determinada zona.
Exemplos de resolução de consultas
Google Cloud resolve as zonas do Cloud DNS, conforme descrito em Ordem de resolução de nomes. Ao determinar a zona a consultar para um determinado registo, o Cloud DNS tenta encontrar uma zona que corresponda o máximo possível ao registo pedido (correspondência de sufixo mais longo).
A menos que tenha especificado um servidor de nomes alternativo numa política de servidor de saída, Google Cloud o primeiro passo é tentar encontrar um registo numa zona privada (ou numa zona de encaminhamento ou numa zona de intercâmbio) autorizada para a sua rede VPC antes de procurar o registo numa zona pública.
Os exemplos seguintes ilustram a ordem que o servidor de metadados usa quando
consulta registos DNS. Para cada um destes exemplos, suponha que criou duas zonas privadas, gcp.example.com e dev.gcp.example.com, e autorizou o acesso às mesmas a partir da mesma rede da VPC. Google Cloud
processa as consultas DNS de VMs numa rede da VPC da seguinte forma:
O servidor de metadados usa servidores de nomes públicos para resolver um registo para
myapp.example.com.(tenha em atenção o ponto final) porque não existe uma zona privada paraexample.comque tenha sido autorizada para a rede VPC. Usedignuma VM do Compute Engine para consultar o servidor de nomes predefinido da VM:dig myapp.example.com.
Para ver detalhes, consulte o artigo Consultar o nome DNS através do servidor de metadados.
O servidor de metadados resolve o registo
myapp.gcp.example.comatravés da zona privada autorizadagcp.example.comporquegcp.example.comé o sufixo comum mais longo entre o nome do registo pedido e as zonas privadas autorizadas disponíveis.NXDOMAINé devolvido se não existir nenhum registo paramyapp.gcp.example.comdefinido na zona privadagcp.example.com, mesmo que exista um registo paramyapp.gcp.example.comdefinido numa zona pública.Da mesma forma, as consultas para
myapp.dev.gcp.example.comsão resolvidas de acordo com os registos na zona privada autorizadadev.gcp.example.com.NXDOMAINé devolvido se não existir nenhum registo paramyapp.dev.gcp.example.comna zonadev.gcp.example.com, mesmo que exista um registo paramyapp.dev.gcp.example.comnoutra zona privada ou pública.As consultas para
myapp.prod.gcp.example.comsão resolvidas de acordo com os registos na zona privadagcp.example.comporquegcp.example.comé o sufixo comum mais longo entre o registo DNS pedido e as zonas privadas disponíveis.
Exemplo de DNS de horizonte dividido
Pode usar uma combinação de zonas públicas e privadas numa configuração de DNS de horizonte dividido. As zonas privadas permitem-lhe definir respostas diferentes a uma consulta para o mesmo registo quando a consulta tem origem numa VM numa rede VPC autorizada. O DNS de horizonte dividido é útil sempre que precisar de fornecer registos diferentes para as mesmas consultas DNS, consoante a rede VPC de origem.
Considere o seguinte exemplo de horizonte dividido:
- Criou uma zona pública,
gcp.example.com, e configurou o respetivo registador para usar servidores de nomes do Cloud DNS. - Criou uma zona privada,
gcp.example.com, e autorizou a sua rede de VPC a aceder a esta zona.
Na zona privada, criou um único registo, conforme apresentado na tabela seguinte.
| Grave | Tipo | TTL (segundos) | Dados |
|---|---|---|---|
| myrecord1.gcp.example.com | A | 5 | 10.128.1.35 |
Na zona pública, criou dois registos.
| Grave | Tipo | TTL (segundos) | Dados |
|---|---|---|---|
| myrecord1.gcp.example.com | A | 5 | 104.198.6.142 |
| myrecord2.gcp.example.com | A | 50 | 104.198.7.145 |
As seguintes consultas são resolvidas conforme descrito:
- Uma consulta para
myrecord1.gcp.example.coma partir de uma VM na sua rede VPC devolve10.128.1.35. - Uma consulta por
myrecord1.gcp.example.comna Internet devolve104.198.6.142. - Uma consulta para
myrecord2.gcp.example.coma partir de uma VM na sua rede VPC devolve um erroNXDOMAINporque não existe nenhum registo paramyrecord2.gcp.example.comna zona privadagcp.example.com. - Uma consulta por
myrecord2.gcp.example.comna Internet devolve104.198.7.145.
Vinculação entre projetos
A associação entre projetos permite-lhe manter a propriedade do espaço de nomes de DNS do projeto de serviço independente da propriedade do espaço de nomes de DNS de toda a rede VPC.
Uma configuração típica de VPC partilhada tem projetos de serviço que assumem a propriedade de uma aplicação ou de serviços de máquina virtual (VM), enquanto o projeto anfitrião assume a propriedade da rede VPC e da infraestrutura de rede. Muitas vezes, é criado um espaço de nomes DNS a partir do espaço de nomes da rede VPC para corresponder aos recursos do projeto de serviço. Para esta configuração, pode ser mais fácil delegar a administração do espaço de nomes DNS de cada projeto de serviço aos administradores de cada projeto de serviço (que são frequentemente departamentos ou empresas diferentes). A associação entre projetos permite-lhe separar a propriedade do espaço de nomes DNS do projeto de serviço da propriedade do espaço de nomes DNS de toda a rede VPC.
A figura seguinte mostra uma configuração típica de VPC partilhada com interligação de DNS.
A figura seguinte mostra uma configuração que usa a vinculação entre projetos. O Cloud DNS permite que cada projeto de serviço crie e seja proprietário das respetivas zonas de DNS, mas continua a estar associado à rede partilhada que o projeto anfitrião detém. Isto permite uma melhor autonomia e um limite de autorização mais preciso para a administração da zona DNS.
A associação entre projetos oferece o seguinte:
- Os administradores e os utilizadores do projeto de serviço podem criar e gerir as suas próprias zonas de DNS.
- Não precisa de criar uma rede VPC de marcador de posição.
- Os administradores do projeto anfitrião não têm de gerir o projeto de serviço.
- As funções do IAM continuam a aplicar-se ao nível do projeto.
- Todas as zonas DNS estão diretamente associadas à rede da VPC partilhada.
- A resolução de DNS de qualquer para qualquer está prontamente disponível. Qualquer VM na rede VPC partilhada pode resolver zonas associadas.
- Não existe um limite de saltos transitivos. Pode fazer a gestão num design de hub e spoke.
Para obter instruções sobre como criar uma zona com a associação entre projetos ativada, consulte o artigo Crie uma zona de associação entre projetos.
Zonas do Cloud DNS zonais
O Cloud DNS zonal permite-lhe criar zonas DNS privadas com âmbito apenas numa Google Cloud zona. As zonas do Cloud DNS zonais são criadas para o GKE quando escolhe um âmbito do cluster.
O serviço Cloud DNS predefinido é de natureza global e os nomes DNS são visíveis globalmente na sua rede VPC. Esta configuração expõe o seu serviço a indisponibilidades globais. O Cloud DNS zonal é um novo serviço de Cloud DNS privado que existe em cada Google Cloud zona. O domínio de falhas está contido nessa Google Cloud zona. As zonas privadas do Cloud DNS zonais não são afetadas quando ocorrem interrupções globais. As interrupções Google Cloud zonais afetam apenas essa zona Google Cloud específica e as zonas do Cloud DNS nessa Google Cloud zona. Tenha em atenção que qualquer recurso criado num serviço zonal só é visível para essa zona. Google Cloud
Para saber como configurar uma zona de âmbito do cluster do Cloud DNS zonal, consulte o artigo Configurar uma zona de âmbito do cluster do GKE zonal.
Suporte do Cloud DNS zonal
A tabela seguinte indica os recursos e as funcionalidades do Cloud DNS que são suportados pelos serviços zonais do Cloud DNS.
| Recurso ou funcionalidade | Disponível no DNS na nuvem global | Disponível no Cloud DNS zonal |
|---|---|---|
| Zonas públicas geridas | ||
| Zonas privadas geridas (com âmbito de rede ou VPC) | ||
| Zonas privadas geridas (com âmbito do GKE) | ||
| Zonas de encaminhamento1 | ||
| Zonas de intercâmbio | ||
| Zonas reverse lookup geridas | ||
| Crie alterações ou faça a gestão de registos2 | ||
| Zonas do diretório de serviços | ||
| Políticas | ||
| Políticas de resposta (com âmbito de rede) | ||
| Políticas de resposta (com âmbito do cluster do GKE) | ||
| Regras da política de respostas |
1 O Cloud DNS zonal suporta apenas zonas de encaminhamento com âmbito num cluster do GKE.
2O controlador do GKE substitui quaisquer alterações aos registos quando é reiniciado.
Faturação de zonas do Cloud DNS zonais
A faturação das zonas do Cloud DNS zonais e das políticas de resposta funciona da mesma forma que as respetivas equivalentes globais.
O que se segue?
- Para trabalhar com zonas geridas, consulte o artigo Crie, modifique e elimine zonas.
- Para encontrar soluções para problemas comuns que pode encontrar ao usar o Cloud DNS, consulte a secção Resolução de problemas.
- Para obter uma vista geral do Cloud DNS, consulte o artigo Vista geral do Cloud DNS.