Práticas recomendadas de DNS

Neste documento, você conhecerá as práticas recomendadas sobre:

Introdução

Para humanos e aplicativos, é mais fácil interagir com aplicativos e serviços usando o Sistema de Nome de Domínio (DNS, na sigla em inglês). 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. Neste artigo, você conhecerá as práticas recomendadas para encaminhar solicitações de DNS privado 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:

  • 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. Para mais detalhes, consulte a Visão geral do Cloud DNS.
  • Serviço gerenciado para o Microsoft Active Directory: é um serviço altamente disponível e protegido 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.
  • Google Domains: é um registrador de domínios para comprar, transferir ou gerenciar domínios. Trata-se de um serviço do Google que não faz parte do Google Cloud.

Identificar ferramentas, processos e principais interessados

Quando você quiser elaborar uma estratégia para DNS em um ambiente híbrido, é importante primeiro 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 detalhes, leia sobre o uso de encaminhamento condicional para acessar registros DNS a partir de ambientes locais nos métodos para acessar registros do Google Cloud DNS.
  • 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 familiarize-se com os padrões e as práticas para ambientes híbridos e de várias nuvens.

Criar um padrão de nomenclatura simples e consistente

Crie um padrão de nomenclatura que seja consistente em toda a organização, mas fácil de lembrar. 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:

  • Usar nomes de domínio separados 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 com ele é fácil encaminhar solicitações entre ambientes.

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

  • Usar 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.

  • Usar o domínio local como um subdomínio daquele que contém 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 nativas digitais e têm uma infraestrutura local reduzida.

  • Usar o mesmo domínio para o Google Cloud e para o ambiente local. Nesse caso, o Google Cloud e o ambiente acessam recursos usando o domínio corp.example.com. É recomendável que você 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 registros de hospedagem da zona gerenciada privada do Cloud DNS para os recursos no Google Cloud.

O diagrama a seguir mostra como é a estruturação:

Exemplo de configuração de um nome de domínio (clique para ampliar)
Exemplo de configuração de um nome de domínio (clique para ampliar)

Para nomear recursos na sua rede VPC, siga as diretrizes em Práticas recomendadas e arquiteturas de referência para o design da VPC.

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

Em um ambiente híbrido, a resolução de DNS pode ser realizada em locais diferentes. Você tem as opções a seguir:

  • 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.

O diagrama a seguir mostra como é a estruturação:

Arquitetura híbrida com dois sistemas DNS autoritativos (clique para ampliar)
Arquitetura híbrida com dois sistemas DNS autoritativos (clique para ampliar)

Esse cenário é o caso de uso recomendado e é abordado em detalhes neste documento. O documento abrange os seguintes pontos:

  • 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 VPCs.

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 encaminhar todas as solicitações do Google Cloud por meio do encaminhamento de DNS de saída usando um servidor de nomes alternativo. 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.
  • As solicitações individuais de DNS podem ser filtradas localmente usando listas de negação.

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 Cloud Dataproc, porque eles dependem da resolução inversa dos nomes de instância do Google Cloud.

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

Outra abordagem é migrar para o Cloud DNS como um serviço autoritário para todas as resoluções de domínio. Depois, é 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 no Cloud DNS não são discutidas neste documento. Elas 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.

Usar a automação para permitir que as equipes gerenciem zonas privadas 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 automaticamente poderão acessar os registros nas zonas privadas anexadas à rede VPC compartilhada.

O diagrama a seguir mostra como as zonas privadas são hospedadas em uma rede VPC compartilhada:

Zonas privadas hospedadas em uma rede VPC compartilhada (clique para ampliar)
Zonas particulares hospedadas em uma rede VPC compartilhada (clique para ampliar)

Se você quiser que as equipes definam os próprios registros DNS, recomendamos automatizar a criação desses registros. Por exemplo, crie um app da Web ou uma API interna para os usuários definirem os próprios registros DNS em subdomínios específicos. Ele seria responsável por verificar 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

Adote o princípio de segurança do privilégio mínimo (em inglês) para conceder o direito de mudar registros DNS apenas àqueles na sua organização que precisam executar essa tarefa. Evite usar papéis primários porque eles podem dar 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 zonas de encaminhamento de DNS

O Cloud DNS oferece políticas de servidor DNS e zonas de encaminhamento de 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.

Não é possível usar o encaminhamento de DNS com ambientes diferentes do Google Cloud, independentemente de como eles são interconectados. Nesse caso de uso, adote o peering de DNS.

Usar 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 do que 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 públicos continuarão não sendo resolvidos sem um salto extra passando por um servidor de nomes local.

Na seção sobre arquiteturas de referência, há um exemplo de fluxo de tráfego que usa essa configuração.

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.

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

Para permitir que hosts locais consultem registros DNS hospedados em zonas particulares do Cloud DNS (por exemplo, gcp.example.com), crie uma política de servidor DNS usando o encaminhamento de entrada desse serviço. 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. Mesmo tendo um endereço IP de encaminhador de entrada separado para cada sub-rede, todas as consultas de DNS retornarão respostas idênticas, sem diferença de latência. Seus apps podem enviar uma solicitação para qualquer um desses endereços.

Na seção sobre arquiteturas de referência, há um exemplo de fluxo de tráfego que usa essa configuração.

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 qualquer ponto da sua VPC ou ambiente local. Isso inclui as seguintes ações:

  • Verifique se o firewall local transmite 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, inclua o intervalo 35.199.192.0/19.

  • Verifique se o tráfego pode fluir do ambiente local para os endereços IP de encaminhamento. Para o encaminhamento de entrada, o firewall local não pode bloquear o fluxo do tráfego para os endereços IP de encaminhamento proveniente dos servidores DNS locais ou de outros clientes. Talvez seja necessário criar uma regra no firewall local para permitir o tráfego proveniente de todos os clientes na porta UDP 53 para o endereço IP de encaminhamento.

Usar 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: 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 no Google Cloud for um subdomínio da zona usada localmente, 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: o Cloud DNS não é compatível com transferências de zona. Portanto, não é possível sincronizar registros DNS com servidores DNS locais usando transferências de zona.

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. As respostas dos seus servidores DNS serão aceitas pelo GCP somente se forem roteadas para a VPC de origem da consulta. No entanto, as consultas de qualquer 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 completamente separados.

O diagrama abaixo ilustra o problema de ter várias VPCs que fazem encaminhamento de saída:

Problemas com várias VPCs fazendo o encaminhamento de saída (clique para ampliar)
Problemas com várias VPCs fazendo o encaminhamento de saída (clique para ampliar)

Recomendamos que você escolha uma única VPC para consultar os servidores de nomes locais usando o encaminhamento de saída. Depois, outras VPCs podem consultar os servidores de nomes locais ao apontar a VPC que você escolheu com uma zona de peering de DNS. As consultas dessas outras VPCs 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 na seção sobre arquiteturas de referência.

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 VMs de vários projetos interajam umas com as outras, mas não muda a resolução de nomes. Os recursos em cada 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 VPC. Assim, é possível encaminhar solicitações para diferentes ambientes do Google Cloud, independentemente de se as VPCs estão interconectadas.

Além disso, esses dois tipos de peering são configurados de maneira diferente. No peering de rede VPC, as duas VPCs 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 VPCs. 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 dns.networks.targetWithPeeringZone do IAM 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 criadas pelo serviço de DNS interno, adote o peering de DNS para encaminhar as zonas projectname.internal para outros projetos. É possível agregar todas as zonas .internal em um projeto hub para disponibilizá-las a partir do ambiente local.

Veja essa configuração no diagrama abaixo:

Peering de DNS em uma configuração de malha (clique para ampliar)
Peering de DNS em uma configuração de malha (clique para ampliar)

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ê verá 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 desenho de VPC:

  • Arquitetura híbrida que usa uma única VPC compartilhada: se você usa apenas uma rede VPC conectada para enviar e receber solicitações do ambiente local.

  • Arquitetura híbrida que usa várias redes VPC separadas: se você tem várias VPCs conectadas ao ambiente local usando diferentes túneis VPN ou anexos da VLAN, mas que compartilham a mesma infraestrutura de DNS local.

  • Arquitetura híbrida que usa uma rede VPC hub conectada a redes VPC spoke: se você 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 VPCs do Google Cloud usando um ou vários túneis do Cloud VPN ou do Cloud Interconnect: conexões dedicadas ou de parceiros. O método de conexão usado em cada rede VPC não é importante.

Arquitetura híbrida que usa uma única rede VPC compartilhada

O caso mais comum é ter uma única rede VPC compartilhada conectada ao ambiente local, conforme mostrado no diagrama a seguir:

Arquitetura híbrida que usa uma única rede VPC compartilhada (clique para ampliar)
Arquitetura híbrida que usa uma única rede VPC compartilhada (clique para ampliar)

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, inclua uma divulgação de rota personalizada para o intervalo 35.199.192.0/19 para envios ao 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 elas são conectadas ao ambiente local usando diferentes túneis do Cloud VPN ou anexos da VLAN. Um caso de uso típico dessa arquitetura é quando há ambientes separados que não se comunicam entre si, mas compartilham os mesmos servidores DNS, por exemplo, ter o ambiente de produção isolado do de desenvolvimento.

Veja essa arquitetura no diagrama abaixo:

Arquitetura híbrida que usa várias redes VPC separadas (clique para ampliar)
Arquitetura híbrida que usa várias redes VPC separadas (clique para ampliar)

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 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 para gcp.example.com nos servidores DNS locais, apontando para um endereço IP encaminhador de entrada na rede VPC compartilhada de produção.
  9. Verifique se o firewall permite o tráfego DNS tanto localmente quanto no Google Cloud.
  10. Nas instâncias do Cloud Router, inclua uma divulgação de rota personalizada para o intervalo 35.199.192.0/19 na rede VPC compartilhada para envios ao ambiente local.

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

Outra opção é conectar a infraestrutura local a uma única rede VPC hub usando o Cloud Interconnect ou o Cloud VPN. Nesse caso, essa rede VPC é pareada a várias redes spoke por meio do peering de rede VPC. Cada 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.

Veja essa arquitetura representada no diagrama abaixo:

Arquitetura híbrida que usa redes VPC hub conectadas a redes VPC spoke (clique para ampliar)
Arquitetura híbrida que usa redes VPC hub conectadas a redes VPC spoke (clique para ampliar)

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 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 para projectX.gcp.example.com, saindo da VPC hub para cada VPC spoke.
  6. Defina uma zona de peering de DNS para example.com, saindo de cada VPC spoke para a VPC hub.
  7. Configure o encaminhamento para gcp.example.com nos servidores DNS locais para apontar para um endereço IP encaminhador de entrada na 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, inclua uma divulgação de rota personalizada para o intervalo 35.199.192.0/19 na VPC hub para envios ao 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.

Próximas etapas