Práticas recomendadas para o Cloud DNS

Este documento fornece práticas recomendadas para zonas privadas, encaminhamento de DNS e arquiteturas de referência para DNS híbrido.

É mais fácil para os humanos e as aplicações usar o Sistema de Nomes de Domínio (DNS) para aceder a aplicações e serviços, porque usar um nome é mais fácil de memorizar e mais flexível do que usar endereços IP. Num ambiente híbrido que consiste em instalações e uma ou mais plataformas na nuvem, os registos DNS dos recursos internos têm frequentemente de ser acedidos em todos os ambientes. Tradicionalmente, os registos de DNS nas instalações são administrados manualmente através de um servidor de DNS autoritário, como o BIND em ambientes UNIX/Linux ou o Active Directory em ambientes Microsoft Windows.

Este documento descreve as práticas recomendadas para o encaminhamento de pedidos de DNS privado entre ambientes, de modo a garantir que os serviços podem ser resolvidos a partir de ambientes no local e no Google Cloud.

Princípios gerais

Saiba mais sobre os conceitos de DNS no Google Cloud

Quando usa o DNS no Google Cloud, é importante compreender os diferentes sistemas e serviços disponíveis no Google Cloud para a resolução de DNS e os nomes de domínio:

• O DNS interno é um serviço que cria automaticamente nomes DNS para máquinas virtuais e balanceadores de carga internos no Compute Engine.
• O Cloud DNS é um serviço que oferece baixa latência e serviço de zonas DNS de alta disponibilidade. Pode atuar como um servidor DNS autoritário para zonas públicas visíveis na Internet ou para zonas privadas visíveis apenas na sua rede.
• O Serviço gerido para Microsoft Active Directory é um serviço altamente disponível e reforçado que executa o Microsoft Active Directory, incluindo um controlador de domínio.
• O DNS público é um serviço da Google que não faz parte do Google Cloud , que atua como um resolvedor de DNS recursivo aberto.
• O Cloud Domains é uma entidade de registo de domínios para comprar, transferir e gerir domínios no Google Cloud. O Cloud Domains permite-lhe interagir com o sistema de registo de domínios através de uma API.

Identifique intervenientes, ferramentas e processos

Quando pensa em criar uma estratégia para DNS num ambiente híbrido, é importante familiarizar-se com a sua arquitetura atual e contactar todas as partes interessadas. Faça o seguinte:

• Identifique e contacte o administrador dos servidores DNS corporativos da sua organização. Peça-lhes informações sobre as configurações necessárias para mapear a sua configuração no local para uma arquitetura adequada noGoogle Cloud. Para ver informações sobre métodos de acesso aos Google Cloud registos de DNS, consulte o artigo Use o encaminhamento condicional para aceder a registos de DNS a partir de instalações.
• Familiarize-se com o software DNS atual e identifique os nomes de domínio que são usados de forma privada na sua organização.
• Identifique os contactos na equipa de rede que podem garantir que o tráfego para os servidores do Cloud DNS é encaminhado corretamente.
• Familiarize-se com a sua estratégia de conetividade híbrida e com os padrões e as práticas híbridas e de várias nuvens.

Crie um padrão de nomenclatura consistente

Crie uma norma de nomenclatura consistente em toda a sua organização. Por exemplo, suponha que a sua organização usa example.com como nome de domínio de segundo nível e o domínio para recursos públicos (por exemplo, www.example.com). O local onde as zonas públicas estão alojadas é irrelevante para os fins deste documento, uma vez que o objetivo é migrar zonas privadas.

Para atribuir nomes a recursos empresariais no local, pode escolher entre os seguintes padrões:

• Pode ter nomes de domínio diferentes para servidores no local e para Google Cloud. Este padrão usa um domínio separado para os seus diferentes ambientes, por exemplo, corp.example.com para os seus servidores no local e gcp.example.com para todos os recursos no Google Cloud. Se usar outros ambientes de nuvem pública, cada um pode ter um subdomínio separado. Este é o padrão preferencial, porque pode encaminhar pedidos entre ambientes.

  Também pode usar nomes de domínios separados, como example.com e example.cloud.

• Pode ter o Google Cloud domínio como um subdomínio do domínio que contém servidores no local. Usando o domínio example.com, a implementação no local pode usar corp.example.com e a implementação na nuvem pode usar Google Cloud .gcp.corp.example.com Este é um padrão comum quando a maioria dos recursos permanece no local.

• Pode ter o domínio no local como um subdomínio do domínio que contém registos Google Cloud . Usando o domínio example.com, Google Cloud pode usar corp.example.com e a implementação no local pode usar dc.corp.example.com. Este é um padrão pouco comum, mas pode ser usado para organizações digitais que têm apenas uma pequena presença no local.

• Pode usar o mesmo domínio para Google Cloud e para o local. Neste caso, ambos os utilizadores Google Cloud e os utilizadores no local usam recursos que usam o domínio corp.example.com. Evite este padrão porque torna a gestão de registos num ambiente híbrido muito mais difícil. Só é possível quando usa um único sistema DNS autoritativo.

O resto desta página usa os seguintes nomes de domínios:

• example.com como nome de domínio para os seus registos públicos, independentemente de onde estiverem alojados.
• corp.example.com como uma zona alojada pelo seu servidor DNS no local. Esta zona alberga registos dos seus recursos no local.
• gcp.example.com como uma zona gerida privada do Cloud DNS que aloja registos para os seus recursos Google Cloud .

A Figura 1 ilustra uma configuração de nome de domínio consistente na sua rede local e na Google Cloud.

Para dar nomes aos recursos na sua rede da nuvem virtual privada (VPC), pode seguir diretrizes como as do guia de soluções Práticas recomendadas e arquiteturas de referência para o design da VPC.

Escolha onde a resolução de DNS é realizada

Num ambiente híbrido, a resolução de DNS pode ser realizada em diferentes localizações. Pode fazer o seguinte:

• Use uma abordagem híbrida com dois sistemas DNS autoritativos.
• Manter a resolução de DNS no local.
• Mova toda a resolução de DNS para o Cloud DNS.

Recomendamos a abordagem híbrida, pelo que este documento se foca nessa abordagem. No entanto, para ser completo, este documento descreve brevemente as abordagens alternativas.

Use uma abordagem híbrida com dois sistemas DNS autoritários

Recomendamos a utilização de uma abordagem híbrida com dois sistemas DNS autoritativos. Nesta abordagem:

• A resolução de DNS autoritativa para o seu ambiente Google Cloud privado é feita pelo Cloud DNS.
• A resolução de DNS autoritativa para recursos no local é alojada por servidores DNS no local existentes.

A Figura 2 mostra esta disposição.

O cenário apresentado na figura 2 é o exemplo de utilização preferencial. Os seguintes detalhes são abordados mais adiante nesta página:

• Como configurar o encaminhamento entre ambientes através de zonas privadas e encaminhamento de DNS.
• Como configurar firewalls e encaminhamento.
• Arquiteturas de referência que mostram como usar uma ou várias redes VPC.

Mantenha a resolução de DNS no local

Uma abordagem alternativa é continuar a usar o seu servidor DNS local existente para alojar de forma autorizada todos os nomes de domínios internos. Nesse caso, pode usar um servidor de nomes alternativo para encaminhar todos os pedidos deGoogle Cloud através do encaminhamento DNS de saída.

Esta abordagem tem as seguintes vantagens:

• Fazer menos alterações nos processos empresariais.
• Pode continuar a usar as suas ferramentas existentes.
• Pode usar listas de recusa para filtrar pedidos DNS individuais no local.

No entanto, tem as seguintes desvantagens:

• Os pedidos DNS de Google Cloud têm uma latência mais elevada.
• O seu sistema depende da conetividade a ambientes nas instalações para operações de DNS.
• Pode ter dificuldades em integrar ambientes altamente flexíveis, como grupos de instâncias com escalabilidade automática.
• O sistema pode não ser compatível com produtos como o Dataproc, porque esses produtos dependem da resolução inversa dos nomes das instâncias. Google Cloud

Mova toda a resolução de DNS para o Cloud DNS

Outra abordagem é migrar para o Cloud DNS como um serviço autoritário para toda a resolução de domínios. Em seguida, pode usar zonas privadas e o encaminhamento de DNS de entrada para migrar a resolução de nomes no local existente para o Cloud DNS.

Esta abordagem tem as seguintes vantagens:

• Não precisa de manter um serviço de DNS de alta disponibilidade no local.
• O seu sistema pode usar o Cloud DNS para tirar partido do registo e monitorização centralizados.

No entanto, tem as seguintes desvantagens:

• Os pedidos de DNS a partir de localizações no local têm uma latência mais elevada.
• O seu sistema requer uma ligação fiável à sua rede VPC para a resolução de nomes.

Práticas recomendadas para zonas privadas do Cloud DNS

As zonas privadas alojam registos de DNS que só são visíveis no interior da sua organização. As zonas públicas no Cloud DNS não são abordadas neste documento. As zonas públicas abrangem os registos públicos da organização, como os registos DNS do Website público, e não são tão relevantes numa configuração híbrida.

Use a automatização para gerir zonas privadas no projeto anfitrião da VPC partilhada

Se usar redes VPC partilhadas na sua organização, tem de alojar todas as zonas privadas no Cloud DNS no projeto anfitrião. Todos os projetos de serviço podem aceder automaticamente aos registos em zonas privadas anexadas à rede de VPC partilhada. Em alternativa, pode configurar a zona num projeto de serviço usando a associação entre projetos.

A Figura 3 mostra como as zonas privadas são alojadas numa rede VPC partilhada.

Se quiser que as equipas definam os seus próprios registos DNS, recomendamos que automatize a criação de registos DNS. Por exemplo, pode criar uma aplicação Web ou uma API interna onde os utilizadores definem os seus próprios registos de DNS em subdomínios específicos. A app verifica se os registos estão em conformidade com as regras da sua organização.

Em alternativa, pode colocar a sua configuração de DNS num repositório de código, como os Cloud Source Repositories, sob a forma de descritores do Terraform ou do Cloud Deployment Manager e aceitar pedidos de obtenção de equipas.

Em ambos os casos, uma conta de serviço com a função de IAM administrador de DNS no projeto anfitrião pode implementar automaticamente as alterações após a respetiva aprovação.

Defina funções do IAM com base no princípio do menor privilégio

Use o princípio de segurança do mínimo privilégio para conceder o direito de alterar os registos de DNS apenas às pessoas na sua organização que precisam de realizar esta tarefa. Evite usar funções básicas, pois podem dar acesso a recursos além dos que o utilizador precisa. O Cloud DNS oferece funções e autorizações que lhe permitem conceder acesso de leitura e escrita específico do DNS.

Se for importante separar a capacidade de criar zonas de DNS privadas da capacidade de criar zonas públicas, use a autorização dns.networks.bindPrivateDNSZone.

Práticas recomendadas para zonas de encaminhamento de DNS e políticas de servidor

O Cloud DNS oferece zonas de encaminhamento de DNS e políticas de servidor DNS para permitir pesquisas de nomes DNS entre o seu ambiente local e o Google Cloud ambiente. Tem várias opções para configurar o encaminhamento de DNS. A secção seguinte apresenta práticas recomendadas para a configuração de DNS híbrido. Estas práticas recomendadas são ilustradas nas Arquiteturas de referência para DNS híbrido.

Use zonas de encaminhamento para consultar servidores no local

Para se certificar de que pode consultar registos DNS no seu ambiente no local, configure uma zona de encaminhamento para o domínio que está a usar no local para os seus recursos corporativos (como corp.example.com). Esta abordagem é preferível à utilização de uma política de DNS que ative um servidor de nomes alternativo. Preserva o acesso aos nomes DNS internos do Compute Engine e os endereços IP externos continuam a ser resolvidos sem um salto adicional através de um servidor de nomes no local.

O fluxo de tráfego que usa esta configuração é apresentado nas Arquiteturas de referência para DNS híbrido.

Use servidores de nomes alternativos apenas se todo o tráfego DNS tiver de ser monitorizado ou filtrado no local e se o registo DNS privado não conseguir satisfazer os seus requisitos.

Use políticas de servidor DNS para permitir consultas a partir de local

Para permitir que os anfitriões no local consultem registos DNS alojados em zonas privadas do Cloud DNS (por exemplo, gcp.example.com), crie uma política de servidor DNS com encaminhamento DNS de entrada. O encaminhamento de DNS de entrada permite que o seu sistema consulte todas as zonas privadas no projeto, bem como endereços IP de DNS internos e zonas com peering.

O fluxo de tráfego que usa esta configuração é apresentado nas Arquiteturas de referência para DNS híbrido.

Abra Google Cloud firewalls no local para permitir o tráfego DNS

Certifique-se de que o tráfego DNS não é filtrado em nenhum local na sua rede VPC ou ambiente no local, fazendo o seguinte:

• Certifique-se de que a sua firewall no local passa consultas do Cloud DNS. O Cloud DNS envia consultas a partir do intervalo de endereços IP 35.199.192.0/19. O DNS usa a porta UDP 53 ou a porta TCP 53, consoante o tamanho do pedido ou da resposta.

• Certifique-se de que o seu servidor DNS não bloqueia consultas. Se o seu servidor DNS no local aceitar pedidos apenas de endereços IP específicos, certifique-se de que o intervalo de endereços IP 35.199.192.0/19 está incluído.

• Certifique-se de que o tráfego pode fluir das instalações para os seus endereços IP de encaminhamento. Nas instâncias do Cloud Router, adicione uma rota anunciada personalizada para o intervalo de endereços IP 35.199.192.0/19 na sua rede VPC ao ambiente no local.

Use o encaminhamento condicional para aceder a registos DNS a partir de instalações locais

Com o Cloud DNS, para aceder a registos privados alojados em servidores DNS corporativos no local, só pode usar zonas de encaminhamento. No entanto, consoante o software do servidor DNS que usar, pode ter várias opções para aceder aos registos DNS a partir de instalações locais. Google Cloud Em cada caso, o acesso aos registos ocorre através do encaminhamento DNS de entrada:

• Encaminhamento condicional. A utilização do encaminhamento condicional significa que o seu servidor DNS corporativo encaminha pedidos de zonas ou subdomínios específicos para os endereços IP de encaminhamento em Google Cloud. Recomendamos esta abordagem porque é a menos complexa e permite-lhe monitorizar centralmente todos os pedidos DNS nos servidores DNS corporativos.

• Delegação. Se a sua zona privada no Google Cloud for um subdomínio da zona que usa no local, também pode delegar este subdomínio no Google Cloud servidor de nomes definindo entradas NS na sua zona. Quando usa esta configuração, os clientes podem comunicar com os endereços IP de encaminhamento diretamente, por isso, certifique-se de que a firewall passa estes pedidos.Google Cloud

• Transferências de zonas. O Cloud DNS não suporta transferências de zonas, pelo que não pode usar transferências de zonas para sincronizar registos de DNS com os seus servidores DNS no local.

Use o peering de DNS para evitar o encaminhamento de saída de várias redes VPC

Não use o encaminhamento de saída para os seus servidores DNS no local a partir de várias redes VPC, uma vez que cria problemas com o tráfego de retorno.O Google Cloud aceita respostas dos seus servidores DNS apenas se forem encaminhadas para a rede VPC a partir da qual a consulta foi originada. No entanto, as consultas de qualquer rede VPC têm o mesmo intervalo de endereços IP 35.199.192.0/19 como origem. Por conseguinte, não é possível encaminhar as respostas corretamente, a menos que tenha ambientes separados no local.

Recomendamos que designe uma única rede VPC para consultar servidores de nomes no local através do encaminhamento de saída. Em seguida, as redes VPC adicionais podem consultar os servidores de nomes no local segmentando a rede VPC designada com uma zona de interligação DNS. As respetivas consultas seriam, em seguida, encaminhadas para servidores de nomes no local de acordo com a ordem de resolução de nomes da rede VPC designada. Esta configuração é apresentada nas Arquiteturas de referência para DNS híbrido.

Compreenda a diferença entre o peering de DNS e o peering de rede VPC

O intercâmbio da rede da VPC não é o mesmo que o intercâmbio de DNS. O intercâmbio de redes VPC permite que as instâncias de máquinas virtuais (VM) em vários projetos se alcancem mutuamente, mas não altera a resolução de nomes. Os recursos em cada rede VPC continuam a seguir a sua própria ordem de resolução.

Por outro lado, através da interligação de DNS, pode permitir que os pedidos sejam encaminhados para zonas específicas para outra rede VPC. Isto permite-lhe encaminhar pedidos para diferentes Google Cloud ambientes, independentemente de as redes VPC estarem interligadas.

O intercâmbio da rede da VPC e o intercâmbio de DNS também são configurados de forma diferente. Para o intercâmbio das redes da VPC, ambas as redes da VPC têm de configurar uma relação de intercâmbio com a outra rede da VPC. Em seguida, a interligação é automaticamente bidirecional.

O intercâmbio de DNS encaminha os pedidos de DNS unidirecionalmente e não requer uma relação bidirecional entre as redes da VPC. Uma rede de VPC referida como a rede consumidora de DNS realiza consultas para uma zona de peering do Cloud DNS noutra rede de VPC, que é referida como a rede produtora de DNS. Os utilizadores com a autorização do IAM dns.networks.targetWithPeeringZone no projeto da rede do produtor podem estabelecer o peering de DNS entre as redes do consumidor e do produtor. Para configurar o peering de DNS a partir de uma rede VPC consumidora, precisa da função de par de DNS para o projeto anfitrião da rede VPC produtora.

Se usar nomes gerados automaticamente, use o peering de DNS para zonas internas

Se usar os nomes gerados automaticamente para VMs que o serviço DNS interno cria, pode usar o peering de DNS para encaminhar as zonas projectname.internal para outros projetos. Conforme mostrado na figura 5, pode agrupar todas as .internalzonas num projeto de hub para as tornar acessíveis a partir da sua rede no local.

Se tiver problemas, siga o guia de resolução de problemas

O guia de resolução de problemas do Cloud DNS fornece instruções para resolver erros comuns que pode encontrar quando configura o Cloud DNS.

Arquiteturas de referência para DNS híbrido

Esta secção fornece algumas arquiteturas de referência para cenários comuns que usam zonas privadas do Cloud DNS num ambiente híbrido. Em cada caso, os recursos no local e os registos de recursos e as zonas são geridos no ambiente. Google Cloud Todos os registos estão disponíveis para consulta a partir de anfitriões no local e Google Cloud .

Use a arquitetura de referência que é mapeada para a sua conceção de rede VPC:

• Arquitetura híbrida com uma única rede VPC partilhada: usa uma única rede VPC ligada a ou a partir de ambientes no local.

• Arquitetura híbrida com várias redes VPC separadas: liga várias redes VPC a ambientes no local através de diferentes túneis VPN ou anexos de VLAN e partilha a mesma infraestrutura de DNS no local.

• Arquitetura híbrida que usa uma rede VPC central ligada a redes VPC periféricas: usa o peering de redes VPC para ter uma rede VPC central ligada a várias redes VPC periféricas independentes.

Em cada caso, o ambiente no local está ligado às redes VPC por um ou vários túneis do Cloud VPN ou ligações de Interligação dedicada ou de parceiro. Google Cloud Não importa que método de ligação é usado para cada rede VPC.

Arquitetura híbrida com uma única rede VPC partilhada

O exemplo de utilização mais comum é uma única rede VPC partilhada ligada ao ambiente no local, conforme mostrado na figura 6.

Para configurar esta arquitetura:

1. Configure os seus servidores DNS no local como autoritários para corp.example.com.
2. Configure uma zona privada autorizada (por exemplo, gcp.example.com) no Cloud DNS no projeto anfitrião da rede VPC partilhada e configure todos os registos para recursos nessa zona.
3. Defina uma política de servidor DNS no projeto anfitrião para a rede de VPC partilhada para permitir o encaminhamento de DNS de entrada.
4. Defina uma zona de encaminhamento de DNS que encaminhe corp.example.com para os servidores DNS no local. A rede de VPC partilhada tem de estar autorizada a consultar a zona de encaminhamento.
5. Configure o encaminhamento para gcp.example.com nos seus servidores DNS no local, apontando para um endereço IP do encaminhador de entrada na rede VPC partilhada.
6. Certifique-se de que o tráfego DNS é permitido na sua firewall no local.
7. Nas instâncias do Cloud Router, adicione uma rota anunciada personalizada para o intervalo 35.199.192.0/19 ao ambiente no local.

Arquitetura híbrida com várias redes VPC separadas

Outra opção para arquiteturas híbridas é ter várias redes VPC separadas. Estas redes VPC no seu ambienteGoogle Cloud não estão ligadas entre si através do intercâmbio das redes VPC. Todas as redes VPC usam túneis do Cloud VPN separados ou anexos de VLAN para estabelecer ligação aos seus ambientes no local.

Conforme mostrado na figura 7, um exemplo de utilização típico desta arquitetura é quando tem ambientes de produção e desenvolvimento separados que não comunicam entre si, mas partilham servidores DNS.

Para configurar esta arquitetura:

1. Configure os seus servidores DNS no local como autoritários para corp.example.com.
2. Configure uma zona privada (por exemplo, prod.gcp.example.com) no Cloud DNS no projeto anfitrião da rede VPC partilhada de produção e configure todos os registos para recursos nessa zona.
3. Configure uma zona privada (por exemplo, dev.gcp.example.com) no Cloud DNS no projeto anfitrião da rede VPC partilhada de desenvolvimento e configure todos os registos para recursos nessa zona.
4. Defina uma política de servidor DNS no projeto anfitrião para a rede de VPC partilhada de produção e permita o encaminhamento de DNS de entrada.
5. Na rede VPC partilhada de produção, defina uma zona DNS para encaminhar corp.example.com para os servidores DNS no local.
6. Defina uma zona de intercâmbio de DNS da rede VPC partilhada de desenvolvimento para a rede VPC partilhada de produção para prod.gcp.example.com.
7. Defina uma zona de intercâmbio de DNS da rede VPC partilhada de produção para a rede VPC partilhada de desenvolvimento para dev.gcp.example.com.
8. Configure o encaminhamento de entrada delegando a resolução de gcp.example.com. para os endereços IP virtuais de encaminhamento de entrada do Cloud DNS nos seus servidores de nomes no local.
9. Certifique-se de que a firewall permite o tráfego DNS nas firewalls no local e Google Cloud .
10. Nas instâncias do Cloud Router, adicione uma rota anunciada personalizada para o intervalo de endereços IP 35.199.192.0/19 na rede VPC partilhada de produção ao ambiente no local.

Arquitetura híbrida que usa uma rede VPC central ligada a redes VPC periféricas

Outra opção é usar o Cloud Interconnect ou o Cloud VPN para ligar a infraestrutura nas instalações a uma rede VPC de hub. Conforme mostrado na figura 8, pode usar o intercâmbio da rede da VPC para estabelecer o intercâmbio de uma rede VPC com várias redes VPC spoke. Cada rede VPC spoke aloja as suas próprias zonas privadas no Cloud DNS. Os trajetos personalizados no intercâmbio da rede da VPC, juntamente com a publicidade de trajetos personalizados no Cloud Router, permitem a troca completa de trajetos e a conetividade entre as instalações e todas as redes da VPC spoke. O intercâmbio de DNS é executado em paralelo com as ligações de intercâmbio das redes da VPC para permitir a resolução de nomes entre ambientes.

O diagrama seguinte mostra esta arquitetura.

Para configurar esta arquitetura:

1. Configure os seus servidores DNS no local como autoritários para corp.example.com.
2. Configure uma zona privada (por exemplo, projectX.gcp.example.com) no Cloud DNS para cada rede VPC spoke e configure todos os registos para recursos nessa zona.
3. Defina uma política de servidor DNS no projeto central para a rede de VPC partilhada de produção para permitir o encaminhamento de DNS de entrada.
4. Na rede VPC do hub, crie uma zona DNS privada para corp.example.com e configure o encaminhamento de saída para os servidores DNS no local.
5. Defina uma zona de intercâmbio de DNS da rede VPC do hub para cada rede VPC de spoke para projectX.gcp.example.com.
6. Defina uma zona de intercâmbio de DNS de cada rede de VPC spoke para a rede de VPC hub para example.com.
7. Configure o encaminhamento para gcp.example.com nos seus servidores DNS no local para apontar para um endereço IP do encaminhador de entrada na rede VPC do hub.
8. Certifique-se de que a firewall permite o tráfego DNS nas firewalls no local e Google Cloud .
9. Nas instâncias do Cloud Router, adicione uma rota anunciada personalizada para o intervalo de endereços IP 35.199.192.0/19 na rede VPC do hub ao ambiente no local.
10. (Opcional) Se também usar os nomes DNS internos gerados automaticamente, sincronize cada zona do projeto spoke (por exemplo, spoke-project-x.internal) com o projeto hub e encaminhe todas as consultas para .internal a partir das instalações.

DNS público com vários fornecedores através do Cloud DNS

Como componente fundamental da rede de aplicações, o DNS fiável é essencial para garantir que as suas aplicações ou serviços estão disponíveis para os utilizadores. Pode melhorar a disponibilidade e a capacidade de recuperação das suas aplicações e serviços configurando vários fornecedores de DNS. Quando são configurados vários fornecedores de DNS, a sua aplicação ou serviço pode estar disponível para os utilizadores, mesmo que haja uma interrupção com um dos fornecedores de DNS. Também pode simplificar a implementação e a migração de aplicações híbridas que têm dependências em ambientes no local e na nuvem com uma configuração de DNS de vários fornecedores.

Google Cloud oferece uma solução de código aberto baseada no octoDNS para ajudar a configurar e operar um ambiente com vários fornecedores de DNS. A solução de DNS de vários fornecedores usa o Cloud DNS como um dos seus fornecedores de DNS numa configuração ativa-ativa (recomendada) ou ativa-passiva para garantir uma arquitetura de DNS de elevada disponibilidade. Depois de implementar a solução, o octoDNS faz uma sincronização única e contínua entre as suas zonas DNS atuais e as zonas DNS geridas alojadas no Cloud DNS. Quando os registos DNS individuais são atualizados, as alterações são propagadas para as zonas DNS correspondentes alojadas no Cloud DNS sem exigir alterações aos seus pipelines de CI/CD.

• Para configurar o Cloud DNS numa configuração de DNS público com vários fornecedores, consulte multi-provider-dns-with-clouddns.

O que se segue?

• Para encontrar soluções para problemas comuns que pode encontrar ao usar o Cloud DNS, consulte a secção Resolução de problemas.
• Para encontrar orientações sobre como abordar e implementar uma configuração híbrida que use Google Cloud, consulte o guia de soluções de padrões e práticas híbridas e de várias nuvens.
• Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.