Melhores práticas para 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 humanos e aplicativos usar o Sistema de Nomes de Domínio (DNS) para endereçar aplicativos e serviços, pois usar um nome é mais fácil de lembrar e mais flexível do que usar endereços IP. Em um ambiente híbrido que consiste em plataformas locais e uma ou mais plataformas em nuvem, os registros DNS para recursos internos geralmente precisam ser acessados ​​entre ambientes. Tradicionalmente, os registros DNS locais são administrados manualmente usando um servidor DNS autoritativo, como BIND em ambientes UNIX/Linux ou o Active Directory em ambientes Microsoft Windows.

Este documento descreve as melhores práticas para encaminhar solicitações DNS privadas entre ambientes para garantir que os serviços possam ser endereçados tanto em ambientes locais quanto em ambientes remotos. Google Cloud.

Princípios gerais

Aprenda sobre os conceitos de DNS em Google Cloud

Quando você usa DNS em Google Cloud, é importante entender os diferentes sistemas e serviços disponíveis em Google Cloud para resolução de DNS e nomes de domínio:

• 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 serviços de zona DNS de baixa latência e alta disponibilidade. Ele pode atuar como um servidor DNS autoritativo para zonas públicas visíveis na internet ou para zonas privadas visíveis apenas na sua rede.
• O Managed Service for Microsoft Active Directory é um serviço reforçado e de alta disponibilidade que executa o Microsoft Active Directory, incluindo um controlador de domínio.
• DNS público é um serviço do Google que não faz parte do Google Cloud que atua como um resolvedor DNS aberto e recursivo.
• Cloud Domains é um registrador de domínios para comprar, transferir e gerenciar domínios dentro Google Cloud. O Cloud Domains permite que você interaja com o sistema de registro de domínio por meio de uma API.

Identificar partes interessadas, ferramentas e processos

Ao pensar em construir uma estratégia para DNS em um ambiente híbrido, é importante se familiarizar com sua arquitetura atual e entrar em contato com todas as partes interessadas. Faça o seguinte:

• Identifique e entre em contato com o administrador dos servidores DNS corporativos da sua organização. Peça informações sobre as configurações necessárias para mapear sua configuração local para uma arquitetura adequada.Google Cloud. Para obter informações sobre métodos de acessoGoogle Cloud Registros DNS, consulte Usar encaminhamento condicional para acessar registros DNS no local .
• Familiarize-se com o software DNS atual e identifique os nomes de domínio que são usados ​​privadamente em sua organização.
• Identifique contatos na equipe de rede que possam garantir que o tráfego para os servidores Cloud DNS seja roteado corretamente.
• Familiarize-se com sua estratégia de conectividade híbrida e com padrões e práticas híbridas e multicloud.

Crie um padrão de nomenclatura consistente

Crie um padrão de nomenclatura consistente em toda a sua organização. Por exemplo, suponha que sua organização use 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 hospedadas é irrelevante para os fins deste documento, pois o escopo é migrar zonas privadas.

Para nomear recursos corporativos locais, você pode escolher entre os seguintes padrões:

• Você pode ter nomes de domínio diferentes para servidores locais e paraGoogle Cloud. Este padrão usa um domínio separado para seus diferentes ambientes - por exemplo, corp.example.com para seus servidores locais e gcp.example.com para todos os recursos em Google CloudSe você usar outros ambientes de nuvem pública, cada um deles poderá ter um subdomínio separado. Este é o padrão preferencial, pois você pode encaminhar solicitações entre ambientes.

  Você também pode usar nomes de domínio separados, como example.com e example.cloud .

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

• Você pode ter o domínio local como um subdomínio do domínio que contémGoogle Cloud registros. Usando o domínio example.com , Google Cloudpoderia usar corp.example.com e, no local, poderia usar dc.corp.example.com . Este é um padrão incomum, mas pode ser usado por organizações digitais com pouca presença local.

• Você pode usar o mesmo domínio para Google Cloud e para o local. Neste caso, ambos Google Cloud e recursos locais que utilizam o domínio corp.example.com . Evite esse padrão, pois ele dificulta muito o gerenciamento de registros em um ambiente híbrido; isso só é possível quando você usa um único sistema DNS autoritativo.

O restante desta página usa os seguintes nomes de domínio:

• example.com como nome de domínio para seus registros públicos, independentemente de onde eles estejam hospedados.
• corp.example.com como uma zona hospedada pelo seu servidor DNS local. Esta zona hospeda registros dos seus recursos locais.
• gcp.example.com como uma zona privada gerenciada do Cloud DNS que hospeda registros para seu Google Cloud recursos.

A Figura 1 ilustra uma configuração de nome de domínio que é consistente tanto na rede local quanto na rede Google Cloud.

Para nomear recursos dentro da sua rede de Nuvem Privada Virtual (VPC), você pode seguir diretrizes como as do guia de soluções Melhores práticas e arquiteturas de referência para design de VPC .

Escolha onde a resolução de DNS será realizada

Em um ambiente híbrido, a resolução de DNS pode ser realizada em diferentes locais. Você pode fazer o seguinte:

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

Recomendamos a abordagem híbrida, portanto, este documento se concentra nela. No entanto, para ser mais completo, este documento descreve brevemente as abordagens alternativas.

Use uma abordagem híbrida com dois sistemas DNS autoritativos

Recomendamos usar uma abordagem híbrida com dois sistemas DNS autoritativos. Nesta abordagem:

• Resolução de DNS autoritativa para seu domínio privado Google Cloud o ambiente é feito pelo Cloud DNS.
• A resolução de DNS autoritativa para recursos locais é hospedada por servidores DNS existentes no local.

A Figura 2 mostra esse arranjo.

O cenário mostrado na figura 2 é o caso de uso preferencial. Os seguintes detalhes serão abordados posteriormente nesta página:

• Como configurar o encaminhamento entre ambientes usando zonas privadas e encaminhamento de DNS.
• Como configurar firewalls e roteamento.
• 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 usando seu servidor DNS local existente para hospedar com autoridade todos os nomes de domínio internos. Nesse caso, você pode usar um servidor de nomes alternativo para encaminhar todas as solicitações deGoogle Cloud por meio de encaminhamento de DNS de saída.

Essa abordagem tem as seguintes vantagens:

• Você faz menos alterações nos processos de negócios.
• Você pode continuar a usar suas ferramentas existentes.
• Você pode usar listas de negação para filtrar solicitações de DNS individuais no local.

No entanto, tem as seguintes desvantagens:

• Solicitações de DNS de Google Cloud têm maior latência.
• Seu sistema depende da conectividade com ambientes locais para operações de DNS.
• Você pode achar difícil integrar ambientes altamente flexíveis, como grupos de instâncias com dimensionamento automático.
• O sistema pode não ser compatível com produtos como o Dataproc porque esses produtos dependem da resolução reversa de Google Cloudnomes de instâncias.

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

Outra abordagem é migrar para o Cloud DNS como um serviço autoritativo para todas as resoluções de domínio. Você pode então usar zonas privadas e encaminhamento de DNS de entrada para migrar sua resolução de nomes local existente para o Cloud DNS.

Essa abordagem tem as seguintes vantagens:

• Você não precisa manter um serviço DNS de alta disponibilidade no local.
• Seu sistema pode usar o Cloud DNS para aproveitar o registro e o monitoramento centralizados.

No entanto, tem as seguintes desvantagens:

• Solicitações de DNS locais têm latência maior.
• Seu sistema requer uma conexão confiável com sua rede VPC para resolução de nomes.

Melhores práticas para zonas privadas do Cloud DNS

Zonas privadas hospedam registros DNS que são visíveis apenas dentro da sua organização. Zonas públicas no Cloud DNS não são abordadas neste documento. Zonas públicas abrangem os registros públicos da organização, como os registros DNS do site público, e não são tão relevantes em uma configuração híbrida.

Use a automação para gerenciar zonas privadas no projeto de host da VPC compartilhada

Se você usa redes VPC compartilhadas na sua organização, precisa hospedar todas as zonas privadas no Cloud DNS dentro do projeto host. Todos os projetos de serviço podem acessar automaticamente os registros em zonas privadas anexadas à rede VPC compartilhada. Como alternativa, você pode configurar a zona em um projeto de serviço usando a vinculação entre projetos .

A Figura 3 mostra como as zonas privadas são hospedadas em uma rede VPC compartilhada.

Se você quiser que as equipes definam seus próprios registros DNS, recomendamos automatizar a criação de registros DNS. Por exemplo, você pode criar um aplicativo web ou uma API interna onde os usuários definam seus próprios registros DNS em subdomínios específicos. O aplicativo verifica se os registros estão em conformidade com as regras da sua organização.

Como alternativa, você pode colocar sua configuração de DNS em um repositório de código, como o Cloud Source Repositories, na forma de descritores do Terraform ou do Cloud Deployment Manager, e aceitar solicitações de pull das equipes.

Em ambos os casos, uma conta de serviço com a função de Administrador de DNS do IAM no projeto host pode implantar automaticamente as alterações depois que elas forem aprovadas.

Defina funções do IAM usando o princípio do menor privilégio

Use o princípio de segurança do menor privilégio para conceder o direito de alterar registros DNS apenas àqueles em sua organização que precisam executar essa tarefa. Evite usar funções básicas , pois elas podem conceder acesso a recursos além daqueles necessários ao usuário. O Cloud DNS oferece funções e permissões que permitem conceder acesso de leitura e gravação específico ao DNS.

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

Melhores práticas 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 seus servidores locais e Google Cloud ambiente. Você tem várias opções para configurar o encaminhamento de DNS. A seção a seguir lista as práticas recomendadas para a configuração de DNS híbrido. Essas práticas recomendadas são ilustradas nas Arquiteturas de referência para DNS híbrido .

Use zonas de encaminhamento para consultar servidores locais

Para garantir que você possa consultar registros DNS no seu ambiente local, configure uma zona de encaminhamento para o domínio que você está usando localmente para seus recursos corporativos (como corp.example.com ). Essa abordagem é preferível ao uso de uma política de DNS que habilita um servidor de nomes alternativo . Ela preserva o acesso aos nomes DNS internos do Compute Engine, e os endereços IP externos ainda são resolvidos sem um salto extra por meio de um servidor de nomes local.

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

Use servidores de nomes alternativos somente se todo o tráfego DNS precisar ser monitorado ou filtrado no local e se o registro DNS privado não puder atender aos seus requisitos.

Use políticas de servidor DNS para permitir consultas locais

Para permitir que hosts locais consultem registros DNS hospedados em zonas privadas do Cloud DNS (por exemplo, gcp.example.com ), crie uma política de servidor DNS usando o encaminhamento de DNS de entrada . O encaminhamento de DNS de entrada permite que seu sistema consulte todas as zonas privadas do projeto, bem como endereços IP de DNS internos e zonas pareadas.

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

Abrir Google Cloud e firewalls locais para permitir tráfego DNS

Certifique-se de que o tráfego DNS não seja filtrado em nenhum lugar dentro da sua rede VPC ou ambiente local, fazendo o seguinte:

• Certifique-se de que o seu firewall local transmita consultas do Cloud DNS. O Cloud DNS envia consultas do intervalo de endereços IP35.199.192.0/19 . O DNS usa a porta UDP 53 ou a porta TCP 53, dependendo do tamanho da solicitação ou resposta.

• Certifique-se de que o seu servidor DNS não bloqueie consultas. Se o seu servidor DNS local aceitar solicitações apenas de endereços IP específicos, certifique-se de que o intervalo de endereços IP35.199.192.0/19 está incluído.

• Garanta que o tráfego possa fluir do local para seus endereços IP de encaminhamento. Em 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 para o ambiente local.

Use o encaminhamento condicional para acessar registros DNS no local

Com o Cloud DNS, para acessar registros privados hospedados em servidores DNS corporativos locais, você só pode usar zonas de encaminhamento . No entanto, dependendo do software de servidor DNS usado, você pode ter várias opções para acessar os registros DNS em Google Cloud localmente. Em cada caso, o acesso aos registros ocorre por meio do encaminhamento de DNS de entrada :

• Encaminhamento condicional . Usar o encaminhamento condicional significa que o servidor DNS corporativo encaminha solicitações de zonas ou subdomínios específicos para os endereços IP de encaminhamento em Google CloudRecomendamos essa abordagem porque é a menos complexa e permite monitorar centralmente todas as solicitações de DNS nos servidores DNS corporativos.

• Delegação . Se sua zona privada estiver em Google Cloud é um subdomínio da zona que você usa no local, você também pode delegar esse subdomínio aoGoogle Cloud servidor de nomes configurando entradas NS dentro de sua zona. Ao usar esta configuração, os clientes podem se comunicar com os endereços IP de encaminhamento emGoogle Cloud diretamente, portanto, certifique-se de que o firewall passe essas solicitações.

• Transferências de zona . O Cloud DNS não oferece suporte a transferências de zona, portanto, você não pode usá-las para sincronizar registros DNS com seus servidores DNS locais.

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 seus servidores DNS locais de várias redes VPC porque isso cria problemas com o tráfego de retorno. Google Cloud aceita respostas dos seus servidores DNS somente se forem roteadas para a rede VPC de origem da consulta. No entanto, consultas de qualquer rede VPC têm o mesmo intervalo de endereços IP.35.199.192.0/19 como fonte. Portanto, as respostas não podem ser roteadas corretamente, a menos que você tenha ambientes separados no local.

Recomendamos que você designe uma única rede VPC para consultar servidores de nomes locais usando o encaminhamento de saída. Assim, redes VPC adicionais podem consultar os servidores de nomes locais, direcionando a rede VPC designada com uma zona de peering DNS. Suas consultas seriam então encaminhadas para servidores de nomes locais de acordo com a ordem de resolução de nomes da rede VPC designada. Essa configuração é mostrada em Arquiteturas de referência para DNS híbrido .

Entenda a diferença entre peering de DNS e peering de rede VPC

O peering de rede VPC não é o mesmo que o peering de DNS. O peering de rede VPC permite que instâncias de máquinas virtuais (VMs) em vários projetos se comuniquem, mas não altera a resolução de nomes. Os recursos em cada rede VPC seguem sua própria ordem de resolução.

Em contrapartida, por meio do peering de DNS, você pode permitir o encaminhamento de solicitações de zonas específicas para outra rede VPC. Isso permite que você encaminhe solicitações para diferentes Google Cloud ambientes, independentemente de as redes VPC estarem interconectadas.

O peering de rede VPC e o peering de DNS também são configurados de forma diferente. Para o peering de rede VPC, ambas as redes VPC precisam configurar um relacionamento de peering com a outra rede VPC. O peering é então automaticamente bidirecional.

O peering de DNS encaminha solicitações de DNS unidirecionalmente e não requer um relacionamento bidirecional entre as redes VPC. Uma rede VPC, chamada de rede de consumidor DNS, realiza buscas por uma zona de peering do Cloud DNS em outra rede VPC, chamada de rede de produtor DNS. Usuários com a permissão do IAM dns.networks.targetWithPeeringZone no projeto da rede de produtor podem estabelecer peering de DNS entre as redes de consumidor e de produtor. Para configurar o peering de DNS a partir de uma rede VPC de consumidor, você precisa da função de peer DNS para o projeto host da rede VPC de produtor.

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

Se você usar os nomes gerados automaticamente para VMs criados pelo serviço DNS interno, poderá usar o peering de DNS para encaminhar as zonas projectname.internal para outros projetos. Como mostrado na Figura 5, você pode agrupar todas as zonas .internal em um projeto de hub para torná-las acessíveis a partir da sua rede local.

Se você tiver problemas, siga o guia de solução de problemas

O guia de solução de problemas do Cloud DNS fornece instruções para resolver erros comuns que você pode encontrar ao configurar o Cloud DNS.

Arquiteturas de referência para DNS híbrido

Esta seção fornece algumas arquiteturas de referência para cenários comuns que usam zonas privadas do Cloud DNS em um ambiente híbrido. Em cada caso, tanto os recursos locais quanto Google Cloud Os registros e zonas de recursos são gerenciados dentro do ambiente. Todos os registros estão disponíveis para consulta tanto no local quanto Google Cloud anfitriões.

Use a arquitetura de referência que mapeia seu design de rede VPC:

• Arquitetura híbrida usando uma única rede VPC compartilhada: usa uma única rede VPC conectada a ou de ambientes locais.

• Arquitetura híbrida usando várias redes VPC separadas: conecta várias redes VPC a ambientes locais por meio de diferentes túneis VPN ou anexos VLAN e compartilha a mesma infraestrutura de DNS local.

• Arquitetura híbrida usando uma rede VPC hub conectada a redes VPC spoke: usa o VPC Network Peering para ter uma rede VPC hub conectada a várias redes VPC spoke independentes.

Em cada caso, o ambiente local está conectado ao Google CloudRedes VPC por um ou vários túneis VPN em nuvem ou conexões de Interconexão Dedicada ou Interconexão de Parceiros. É irrelevante qual método de conexão é usado para cada rede VPC.

Arquitetura híbrida usando uma única rede VPC compartilhada

O caso de uso mais comum é uma única rede VPC compartilhada conectada ao ambiente local, conforme mostrado na figura 6.

Para configurar esta arquitetura:

1. Configure seus servidores DNS locais como autoritativos para corp.example.com .
2. Configure uma zona privada autoritativa (por exemplo, gcp.example.com ) no Cloud DNS no projeto host da rede VPC compartilhada e configure todos os registros para recursos nessa zona.
3. Defina uma política de servidor DNS no projeto host para a rede VPC compartilhada 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 locais. A rede VPC compartilhada precisa ser autorizada a consultar a zona de encaminhamento.
5. Configure o encaminhamento para gcp.example.com em seus servidores DNS locais, apontando para um endereço IP de encaminhador de entrada na rede VPC compartilhada.
6. Certifique-se de que o tráfego DNS seja permitido no seu firewall local.
7. Em instâncias do Cloud Router, adicione uma rota anunciada personalizada para o intervalo35.199.192.0/19 para o ambiente local.

Arquitetura híbrida usando várias redes VPC separadas

Outra opção para arquiteturas híbridas é ter várias redes VPC separadas. Essas redes VPC em seuGoogle Cloud Os ambientes locais não são conectados entre si por meio do peering de rede VPC. Todas as redes VPC usam túneis VPN na nuvem ou anexos de VLAN separados para se conectar aos seus ambientes locais.

Conforme mostrado na figura 7, um caso de uso típico para essa arquitetura é quando você tem ambientes de produção e desenvolvimento separados que não se comunicam entre si, mas compartilham servidores DNS.

Para configurar esta arquitetura:

1. Configure seus servidores DNS locais como autoritativos para corp.example.com .
2. Configure uma zona privada (por exemplo, prod.gcp.example.com ) no Cloud DNS no projeto host da rede VPC compartilhada de produção e configure todos os registros de recursos nessa zona.
3. Configure uma zona privada (por exemplo, dev.gcp.example.com ) no Cloud DNS no projeto host da rede VPC compartilhada de desenvolvimento e configure todos os registros de recursos nessa zona.
4. Defina uma política de servidor DNS no projeto host para a rede VPC compartilhada de produção e permita o encaminhamento de DNS de entrada.
5. Na rede VPC compartilhada de produção, defina uma zona DNS para encaminhar corp.example.com para os servidores DNS locais.
6. Defina uma zona de peering de DNS da rede VPC compartilhada de desenvolvimento para a rede VPC compartilhada de produção para prod.gcp.example.com .
7. Defina uma zona de peering de DNS da rede VPC compartilhada de produção para a rede VPC compartilhada de desenvolvimento para dev.gcp.example.com .
8. Configure o encaminhamento de entrada delegando a resolução de gcp.example.com. aos endereços IP virtuais de encaminhamento de entrada do Cloud DNS nos seus servidores de nomes locais.
9. Certifique-se de que o firewall permite tráfego DNS tanto no local quantoGoogle Cloud firewalls.
10. Em instâncias do Cloud Router, adicione uma rota anunciada personalizada para o intervalo de endereços IP35.199.192.0/19 na rede VPC compartilhada de produção para o ambiente local.

Arquitetura híbrida usando uma rede VPC hub conectada a redes VPC spoke

Outra opção é usar o Cloud Interconnect ou o Cloud VPN para conectar a infraestrutura local a uma rede VPC hub. Como mostrado na Figura 8, você pode usar o VPC Network Peering para parear uma rede VPC com várias redes VPC spoke. Cada rede VPC spoke hospeda suas próprias zonas privadas no Cloud DNS. Rotas personalizadas no VPC Network Peering, juntamente com o anúncio de rotas personalizadas no Cloud Router, permitem a troca completa de rotas e a conectividade entre as redes VPC locais e todas as redes spoke. O peering de DNS é executado em paralelo com as conexões do VPC Network Peering para permitir a resolução de nomes entre ambientes.

O diagrama a seguir mostra essa arquitetura.

Para configurar esta arquitetura:

1. Configure seus servidores DNS locais como autoritativos 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 registros de recursos nessa zona.
3. Defina uma política de servidor DNS no projeto do hub para a rede VPC compartilhada 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 locais.
5. Defina uma zona de peering de DNS da rede VPC do hub para cada rede VPC spoke para projectX.gcp.example.com .
6. Defina uma zona de peering de DNS de cada rede VPC spoke para a rede VPC hub, por example.com .
7. Configure o encaminhamento para gcp.example.com em seus servidores DNS locais para apontar para um endereço IP de encaminhador de entrada na rede VPC do hub.
8. Certifique-se de que o firewall permite tráfego DNS tanto no local quantoGoogle Cloud firewalls.
9. Em instâncias do Cloud Router, adicione uma rota anunciada personalizada para o intervalo de endereços IP35.199.192.0/19 na rede VPC do hub para o ambiente local.
10. (Opcional) Se você também usar os nomes DNS internos gerados automaticamente, faça o peering de cada zona do projeto spoke (por exemplo, spoke-project-x.internal ) com o projeto hub e encaminhe todas as consultas para .internal do local.

DNS público multiprovedor usando Cloud DNS

Como componente fundamental da rede de aplicativos, um DNS confiável é essencial para garantir que seus aplicativos ou serviços estejam disponíveis para seus usuários. Você pode melhorar a disponibilidade e a resiliência de seus aplicativos e serviços configurando vários provedores de DNS. Quando vários provedores de DNS são configurados, seu aplicativo ou serviço pode estar disponível para seus usuários mesmo em caso de indisponibilidade de um deles. Você também pode simplificar a implantação e a migração de aplicativos híbridos que têm dependências entre ambientes locais e em nuvem com uma configuração de DNS multiprovedor.

Google Cloud oferece uma solução de código aberto baseada no octoDNS para ajudar você a configurar e operar um ambiente com vários provedores de DNS. A solução de DNS multiprovedor utiliza o Cloud DNS como um dos seus provedores de DNS em uma configuração ativa-ativa (recomendada) ou ativa-passiva para garantir uma arquitetura de DNS de alta disponibilidade. Após a implantação da solução, o octoDNS realiza a sincronização única e contínua entre suas zonas DNS atuais e as zonas DNS gerenciadas hospedadas no Cloud DNS. Quando registros DNS individuais são atualizados, as alterações são propagadas para as zonas DNS correspondentes hospedadas no Cloud DNS sem a necessidade de alterações em seus pipelines de CI/CD.

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

O que vem a seguir

• Para encontrar soluções para problemas comuns que você pode encontrar ao usar o Cloud DNS, consulte Solução de problemas .
• Para encontrar orientação sobre como abordar e implementar uma configuração híbrida que usa Google Cloud, consulte o guia de soluções de padrões e práticas de nuvem híbrida e multinuvem .
• Para mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Cloud Architecture Center .