Práticas recomendadas para o Cloud DNS

Neste documento, você conhecerá as práticas recomendadas para zonas privadas, encaminhamento de DNS e arquiteturas de referência para DNS híbrido.

Para humanos e aplicativos, é mais fácil usar o Sistema de Nome de Domínio (DNS) para lidar com aplicativos e serviços. O motivo disso é porque, além de mais flexível, é mais fácil se lembrar de um nome do que usar endereços IP. Em um ambiente híbrido, formado por plataformas locais e uma ou mais plataformas em nuvem, os registros DNS de recursos internos são acessados em vários ambientes diferentes. É comum que os registros DNS em plataformas locais sejam administrados manualmente, usando um servidor DNS autoritativo, como o BIND em ambientes UNIX/Linux ou o Active Directory em ambientes Microsoft Windows.

Este documento descreve as práticas recomendadas para encaminhar solicitações de DNS privadas entre ambientes e, dessa forma, garantir que seja possível acessar os serviços tanto a partir de ambientes locais quanto do Google Cloud.

Princípios gerais

Aprender sobre os conceitos relacionados a DNS no Google Cloud

Ao usar o DNS no Google Cloud, é importante entender quais são e como funcionam os diferentes sistemas e serviços disponíveis no Google Cloud para nomes de domínio e resolução de DNS:

  • O DNS interno é um serviço que cria automaticamente nomes de DNS para máquinas virtuais e balanceadores de carga internos no Compute Engine.
  • Cloud DNS: é um serviço que fornece atendimento de zonas de DNS com baixa latência e alta disponibilidade. Ele pode atuar como um servidor DNS autoritativo para zonas públicas visíveis na Internet ou zonas privadas visíveis apenas na sua rede.
  • O Serviço gerenciado para Microsoft Active Directory é um serviço altamente disponível e robusto que executa o Microsoft Active Directory, incluindo um controlador de domínios.
  • Public DNS (em inglês): é um serviço do Google que não faz parte do Google Cloud e funciona como um resolvedor de DNS aberto e recursivo.
  • O Cloud Domains é um registrador de domínios para comprar, transferir e gerenciar domínios no Google Cloud. Com o Cloud Domains, é possível interagir com o sistema de registro de domínio por meio de uma API.

Identificar ferramentas, processos e principais interessados

Quando você quiser elaborar uma estratégia para DNS em um ambiente híbrido, é importante se familiarizar com sua arquitetura atual e entrar em contato com todos os principais interessados. 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 em uma arquitetura adequada no Google Cloud. Para mais informações sobre os métodos de acesso aos registros DNS do Google Cloud, consulte Usar encaminhamento condicional para acessar registros DNS a partir de ambientes locais.
  • Familiarize-se com o software de DNS atual e identifique os nomes de domínio que são usados de forma privada na sua organização.
  • Identifique os contatos da equipe de rede que podem garantir que o tráfego para os servidores do Cloud DNS está roteado corretamente.
  • Conheça bem a estratégia de conectividade híbrida da sua organização e os padrões e práticas híbridos e de várias nuvens.

Crie um padrão de nomenclatura consistente

Crie um padrão de nomenclatura consistente em toda a organização. Imagine que sua organização usa example.com como nome de domínio de segundo nível e como domínio para recursos públicos (por exemplo, www.example.com). O local onde as zonas públicas são hospedadas é irrelevante para os fins deste documento porque o escopo é sobre a migração de zonas privadas.

Escolha um dos seguintes padrões para nomear recursos corporativos locais:

  • É possível usar nomes de domínio diferentes para servidores locais e para o Google Cloud. Esse 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 no Google Cloud. Se você usa outros ambientes de nuvem pública, cada um deles pode ter um subdomínio separado. Esse é o padrão recomendável, porque é possível encaminhar solicitações entre ambientes.

    Também é possível usar nomes de domínio separados, como example.com e example.cloud.

  • Use o domínio do Google Cloud como um subdomínio daquele que contém servidores locais. No caso do domínio example.com, é possível usar corp.example.com no ambiente local e gcp.corp.example.com no Google Cloud. Esse é um padrão comum quando a maioria dos recursos permanece no ambiente local.

  • Use o domínio local como um subdomínio daquele que contém os registros do Google Cloud. No caso do domínio example.com, é possível usar corp.example.com no Google Cloud e dc.corp.example.com no ambiente local. Esse é um padrão incomum, mas pode ser usado em organizações que são digitais e têm uma infraestrutura local reduzida.

  • É possível usar o mesmo domínio para o Google Cloud e para o ambiente local. Nesse caso, o Google Cloud e o ambiente local usam os recursos que usam o domínio corp.example.com. Evite esse padrão porque ele dificulta muito o gerenciamento de registros em um ambiente híbrido. Só é possível adotá-lo quando um único sistema DNS autoritativo é usado.

No restante desta página, são usados os seguintes nomes de domínio:

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

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

Figura 1. Configuração consistente do nome de domínio em toda a organização.
Figura 1. A configuração do nome de domínio é consistente em toda a organização.

Para nomear recursos na sua rede de nuvem privada virtual (VPC), siga as diretrizes no guia de soluções Práticas recomendadas e arquiteturas de referência para o design da VPC.

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

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

  • Usar uma abordagem híbrida com dois sistemas DNS autoritativos.
  • Manter a resolução de DNS no ambiente local.
  • Mover a resolução de DNS por completo para o Cloud DNS.

Recomendamos adotar a abordagem híbrida, e é por isso que ela é o foco deste documento. No entanto, para que você tenha uma visão geral completa, as abordagens alternativas também são discutidas aqui.

Usar uma abordagem híbrida com dois sistemas DNS autoritativos

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

  • a resolução de DNS autoritativo para seu ambiente privado do Google Cloud é feita pelo Cloud DNS;
  • a resolução de DNS autoritativo para recursos locais é hospedada por servidores DNS no ambiente local.

A Figura 2 mostra essa disposição.

Figura 2. Uma arquitetura de DNS híbrido que usa o Cloud DNS e os servidores DNS locais para fornecer resolução de DNS autoritativa.
Figura 2. Uma arquitetura de DNS híbrido que usa o Cloud DNS e os servidores DNS locais oferece resolução de DNS autoritativa.

O cenário mostrado na figura 2 é o caso de uso preferido. Os detalhes a seguir são abordados mais adiante nesta página:

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

Manter a resolução de DNS no ambiente local

Uma abordagem alternativa é continuar usando seu servidor DNS local atual para hospedar de modo autoritativo todos os nomes de domínio internos. Nesse caso, é possível usar um servidor de nomes alternativo para encaminhar todas as solicitações do Google Cloud por meio do encaminhamento de DNS de saída.

Essa abordagem tem as seguintes vantagens:

  • São necessárias menos mudanças nos processos de negócios.
  • É possível continuar usando as ferramentas que você já tem.
  • É possível usar listas de negações para filtrar solicitações de DNS individuais no local.

No entanto, ela tem as seguintes desvantagens:

  • As solicitações de DNS do Google Cloud têm maior latência.
  • Seu sistema depende da conectividade com o ambiente local para realizar as operações de DNS.
  • Talvez seja difícil integrar ambientes altamente flexíveis, como grupos de instâncias com escalonamento automático.
  • O sistema pode não ser compatível com produtos como o Dataproc, porque eles dependem da resolução inversa dos nomes de instância do Google Cloud.

Mova a resolução de DNS por completo para o Cloud DNS

Outra abordagem é migrar para o Cloud DS como um serviço autoritário para todas as resoluções de domínio. É possível migrar sua resolução de nome local para o Cloud DNS usando zonas privadas e encaminhamento de DNS de entrada.

Essa abordagem tem as seguintes vantagens:

No entanto, ela tem as seguintes desvantagens:

  • As solicitações de DNS do ambiente local têm maior latência.
  • Seu sistema precisa de uma conexão confiável com a rede VPC para a resolução de nomes.

Práticas recomendadas para zonas privadas do Cloud DNS

As zonas privadas hospedam registros DNS visíveis apenas dentro da organização. As zonas públicas do Cloud DNS não são abordadas neste documento. As zonas públicas abrigam os registros públicos da organização, como os registros DNS do site público, e não são muito importantes em uma configuração híbrida.

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

Se você usar redes VPC compartilhadas internamente na sua organização, precisará hospedar todas as zonas privadas no Cloud DNS, dentro do projeto de host. Todos os projetos de serviço poderão acessar automaticamente os registros nas zonas privadas anexadas à rede VPC compartilhada. Também é possível 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.

Figura 3. Zonas privadas hospedadas em uma rede VPC compartilhada (clique para ampliar).
Figura 3. Essa configuração mostra como as zonas particulares são anexadas a uma VPC compartilhada.

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

Como alternativa, também é possível colocar a configuração de DNS em um repositório de código, como o Cloud Source Repositories, na forma de descritores do Terraform (em inglês) ou do Cloud Deployment Manager, e aceitar as solicitações de envio das equipes.

Nos dois casos, uma conta de serviço com o papel do IAM de administrador de DNS no projeto host pode implantar automaticamente as alterações depois de serem aprovadas.

Defina papéis de IAM usando o princípio do privilégio mínimo

Use o princípio de segurança do privilégio mínimo para conceder o direito de mudar registros DNS apenas àqueles na sua organização que precisam executar essa tarefa. Evite usar papéis básicos porque eles podem conceder acesso a mais recursos do que o usuário precisa. O Cloud DNS disponibiliza permissões e papéis que permitem conceder acesso de leitura e gravação específico apenas para DNS.

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

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

O Cloud DNS oferece zonas de encaminhamento de DNS e políticas de servidor DNS para permitir pesquisas de nomes entre seu ambiente local e o Google Cloud. Você tem várias opções para configurar o encaminhamento de DNS. Veja na seção a seguir as práticas recomendadas para uma configuração de DNS híbrida. Essas práticas estão exemplificadas em Arquiteturas de referência para DNS híbrido.

Use zonas de encaminhamento para consultar servidores locais

Para ter certeza de que é possível consultar registros DNS no ambiente local, configure uma zona de encaminhamento para o domínio usado localmente para os recursos corporativos, como corp.example.com. É preferível usar essa abordagem a uma política de DNS que permita um servidor de nomes alternativo. Ela preserva o acesso aos nomes de DNS interno do Compute Engine. Além disso, os endereços IP externo continuarão não sendo resolvidos sem um salto extra passando por 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 for necessário monitorar ou filtrar localmente todo o tráfego de DNS e se não for possível atender a seus requisitos pela geração de registros DNS privados.

Use políticas do servidor DNS para permitir consultas do ambiente local

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 entrada. Esse tipo de encaminhamento permite que seu sistema consulte todas as zonas privadas no projeto, bem como endereços DNS internos e zonas em peering.

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

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

Verifique se o tráfego de DNS não está sendo filtrado em nenhum ponto da sua rede VPC ou ambiente local por meio das etapas a seguir:

  • Verifique se o firewall local transmite as consultas do Cloud DNS. O Cloud DNS envia consultas do intervalo de endereços IP 35.199.192.0/19. O DNS usa a porta UDP 53 ou a porta TCP 53, dependendo do tamanho da solicitação ou da resposta.

  • Verifique se o servidor DNS não está bloqueando as consultas. Se o servidor DNS local aceitar solicitações somente de endereços IP específicos, verifique se o intervalo de endereços IP 35.199.192.0/19 está incluído.

  • Garanta que o tráfego possa fluir do ambiente local para os 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 rede VPC para o ambiente local.

Use encaminhamento condicional para acessar registros DNS locais

Com o Cloud DNS, só é possível usar zonas de encaminhamento para acessar registros privados hospedados em servidores DNS corporativos locais. No entanto, dependendo do software de servidor DNS usado, há várias opções para acessar os registros DNS no Google Cloud a partir do ambiente local. Em cada caso, o acesso aos registros se dá por meio do encaminhamento de DNS de entrada:

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

  • Delegação. Se sua zona privada do Google Cloud for um subdomínio da zona usada no ambiente local, configure as entradas NS na sua zona para delegar esse subdomínio ao servidor de nomes do Google Cloud. Quando você usa essa configuração, os clientes podem interagir diretamente com os endereços IP de encaminhamento no Google Cloud. Portanto, verifique se o firewall está transmitindo essas solicitações.

  • Transferências de zona. Como o Cloud DNS não é compatível com transferências de zona, não é possível sincronizar registros DNS com servidores DNS locais.

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

Não use encaminhamento de saída de várias redes VPC para servidores DNS locais. Isso cria problemas com o tráfego de retorno. O Google Cloud aceita respostas dos seus servidores DNS somente se forem roteadas para a rede VPC de origem da consulta. No entanto, as consultas de qualquer rede VPC têm o mesmo intervalo de endereços IP 35.199.192.0/19 como origem. Portanto, as respostas não podem ser roteadas corretamente, a menos que você tenha ambientes locais separados.

Figura 4. Um problema ocorre quando vários tráfegos de encaminhamento de VPC estão fora das redes.
Figura 4. Problema com várias redes VPC fazendo encaminhamento de saída.

Recomendamos que você escolha uma única rede VPC para consultar os servidores de nomes locais usando o encaminhamento de saída. Depois, outras redes VPC podem consultar os servidores de nomes locais ao apontar a rede VPC escolhida com uma zona de peering de DNS. As consultas dessas outras redes VPC serão encaminhadas para os servidores de nomes locais de acordo com a ordem de resolução de nomes da VPC escolhida. Essa configuração é mostrada nas Arquiteturas de referência para DNS híbrido.

Diferença entre peering de DNS e peering de rede VPC

Peering de rede VPC não é a mesma coisa que peering de DNS. O peering de rede VPC permite que as máquinas virtuais (VMs) de vários projetos interajam umas com as outras, mas não muda a resolução de nomes. Os recursos em cada rede VPC ainda seguem a própria ordem de resolução.

Por outro lado, o peering de DNS permite que solicitações a zonas específicas sejam encaminhadas para outra rede VPC. Assim, é possível encaminhar solicitações para diferentes ambientes do Google Cloud, independentemente de se as redes VPC estão interconectadas.

Além disso, esses dois tipos de peering são configurados de maneira diferente. No peering de rede VPC, as duas redes VPC precisam estar configuradas em uma relação de peering entre elas. Assim, o peering é automaticamente bidirecional.

O peering de DNS encaminha de modo unidirecional as solicitações de DNS e não exige uma relação bidirecional entre as redes VPC. Uma rede VPC, chamada de rede consumidora de DNS, realiza pesquisas para encontrar uma zona de peering do Cloud DNS em outra rede VPC, chamada de rede produtora de DNS. Os usuários com a permissão do IAM dns.networks.targetWithPeeringZone no projeto da rede produtora podem estabelecer o peering de DNS entre as redes consumidora e produtora. Para configurar um peering de DNS em uma rede VPC consumidora, é necessário ter o papel que permite fazer isso no projeto host da rede VPC produtora.

Se você estiver usando nomes gerados automaticamente, adote o peering de DNS para zonas internas

Se você estiver usando nomes gerados automaticamente para as VMs que o serviço de DNS interno criar, use o peering de DNS para encaminhar as zonas projectname.internal para outros projetos. Conforme mostrado na figura 5, é possível agrupar todas as zonas .internal em um projeto de hub para torná-las acessíveis a partir da sua rede local.

Figura 5. O peering de DNS é usado para organizar todas as zonas .internal em um hub.
Figura 5. O peering de DNS é usado para organizar todas as zonas .internal em um hub.

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

No guia de solução de problemas do Cloud DNS, você encontra instruções para resolver erros comuns que poderão aparecer ao configurar o Cloud DNS.

Arquiteturas de referência para DNS híbrido

Nesta seção, você conhecerá algumas arquiteturas de referência para cenários comuns que usam zonas privadas do Cloud DNS em um ambiente híbrido. Em cada caso, as zonas e os registros de recursos do Google Cloud e de recursos são gerenciados internamente no ambiente. Todos os registros estão disponíveis para consultas por hosts locais e do Google Cloud.

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

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

  • Arquitetura híbrida que usa várias redes VPC separadas: conecta várias redes VPC a ambientes locais por meio de diferentes túneis VPN ou anexos da VLAN, mas compartilham a mesma infraestrutura de DNS local.

  • Arquitetura híbrida que usa uma rede VPC hub conectada a redes VPC spoke: usa o peering de rede VPC para ter uma rede VPC hub conectada a várias redes VPC spoke independentes.

Em cada caso, o ambiente local é conectado às redes VPC do Google Cloud por um ou vários túneis do Cloud VPN, ou por conexões de Interconexão dedicada ou Interconexão por parceiro. O método de conexão usado em cada rede VPC não é importante.

Arquitetura híbrida que usa uma rede VPC compartilhada

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

Figura 6. Uma arquitetura híbrida usa uma única rede VPC compartilhada para se conectar a uma rede local.
Figura 6. Uma arquitetura híbrida usa uma única rede VPC compartilhada para se conectar a uma rede local.

Para configurar essa arquitetura, siga estas etapas:

  1. Configure os 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. Depois, configure todos os registros de recursos nessa zona.
  3. Defina uma política de servidor DNS no projeto host da rede VPC compartilhada para permitir o encaminhamento de DNS de entrada.
  4. Defina uma zona de encaminhamento de DNS que envia corp.example.com aos servidores DNS locais. A VPC compartilhada precisa ser autorizada a consultar a zona de encaminhamento.
  5. Configure o encaminhamento para gcp.example.com nos servidores DNS locais, apontando para um endereço IP encaminhador de entrada na rede VPC compartilhada.
  6. Verifique se o tráfego de DNS está permitido no firewall local.
  7. Nas instâncias do Cloud Router, adicione uma rota divulgada personalizada para o intervalo 35.199.192.0/19 para o ambiente local.

Arquitetura híbrida que usa várias redes VPC separadas

Outra opção de arquitetura híbrida é ter várias redes VPC separadas. Essas redes VPC no seu ambiente do Google Cloud não são conectadas umas às outras por meio do peering de rede VPC. Todas as redes VPC usam túneis do Cloud VPN separados ou anexos da VLAN para se conectar aos ambientes locais.

Conforme mostrado na figura 7, um caso de uso típico dessa arquitetura é quando há ambientes de produção e desenvolvimento separados que não se comunicam entre si, mas compartilham os mesmos servidores DNS.

Figura 7. Uma arquitetura híbrida pode usar várias redes VPC separadas.
Figura 7. Uma arquitetura híbrida pode usar várias redes VPC separadas.

Para configurar essa arquitetura, siga estas etapas:

  1. Configure os 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. Depois, 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. Depois, configure todos os registros de recursos nessa zona.
  4. Defina uma política de servidor DNS no projeto host da 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 de DNS para encaminhar corp.example.com aos servidores DNS locais.
  6. Defina uma zona de peering de DNS para prod.gcp.example.com, saindo da rede VPC compartilhada de desenvolvimento para a de produção.
  7. Defina uma zona de peering de DNS para dev.gcp.example.com, saindo da rede VPC compartilhada de produção para a de desenvolvimento.
  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 servidores de nomes locais.
  9. Verifique se o firewall permite o tráfego DNS tanto localmente quanto no 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 compartilhada de produção para o ambiente local.

Arquitetura híbrida que usa 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. Conforme mostrado na figura 8, é possível usar o peering de rede VPC para fazer peering de uma rede VPC com várias redes VPC spoke. Toda rede VPC spoke hospeda as próprias zonas privadas no Cloud DNS. Ao usar rotas personalizadas no peering de rede VPC em conjunto com uma divulgação de rota personalizada no Cloud Router, é possível ter total troca de rotas e conectividade entre o ambiente local e todas as redes VPC spoke. O peering de DNS é executado em paralelo com a conexão do peering de rede VPC para permitir a resolução de nomes entre ambientes.

O diagrama a seguir mostra essa arquitetura.

Figura 8. Uma arquitetura híbrida pode usar uma rede VPC hub conectada a redes VPC spoke usando peering de rede VPC.
Figura 8. Uma arquitetura híbrida pode usar uma rede VPC hub conectada a redes VPC spoke.

Para configurar essa arquitetura, siga estas etapas:

  1. Configure os 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. Depois, configure todos os registros de recursos nessa zona.
  3. Defina uma política de servidor DNS no projeto hub da rede VPC compartilhada de produção para permitir o encaminhamento de DNS de entrada.
  4. Na VPC hub, crie uma zona de 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 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 para example.com.
  7. Configure o encaminhamento para gcp.example.com nos servidores DNS locais para apontar para um endereço IP encaminhador de entrada na rede VPC hub.
  8. Verifique se o firewall permite o tráfego DNS tanto localmente quanto no Google Cloud.
  9. Nas instâncias do Cloud Router, adicione uma rota divulgada personalizada para o intervalo de endereços IP 35.199.192.0/19 na rede VPC hub para o ambiente local.
  10. (Opcional) Se você também usa nomes de DNS internos gerados automaticamente, faça o peer de cada zona de projeto spoke (por exemplo, spoke-project-x.internal) com o projeto hub e encaminhe todas as consultas provenientes do ambiente local para .internal.

DNS público de vários provedores usando o Cloud DNS

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

O Google Cloud oferece uma solução de código aberto baseada em octoDNS para ajudar você a configurar e operar um ambiente com vários provedores de DNS. Essa solução usa o Cloud DNS como um dos provedores de DNS em uma configuração ativa-ativa (recomendada) ou ativo-passivo para garantir uma arquitetura de DNS altamente disponível. Depois de implantar a solução, o octoDNS realiza uma sincronização única e contínua entre as zonas DNS atuais e as zonas DNS gerenciadas hospedadas no Cloud DNS. Quando os registros DNS individuais são atualizados, as alterações são propagadas para as zonas DNS correspondentes hospedadas no Cloud DNS sem exigir nenhuma alteração nos seus pipelines de CI/CD.

A seguir