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 privado entre ambientes e, dessa forma, garantir que seja possível acessar os serviços tanto a partir de ambientes locais quanto do Trusted Cloud.

Princípios gerais

Saiba mais sobre os conceitos de DNS em Trusted Cloud

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

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

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 noTrusted Cloud. Para mais informações sobre os métodos de acesso aos Trusted Cloud registros DNS, consulte Usar encaminhamento condicional para acessar registros DNS em 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 as práticas híbridos e de várias nuvens.

Práticas recomendadas para zonas privadas do Cloud DNS

As zonas privadas hospedam registros DNS visíveis apenas dentro da organização.

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.

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 Trusted 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 nas 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.

Abra Trusted Cloud e 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 177.222.82.0/25. 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 177.222.82.0/25 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 177.222.82.0/25 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 Trusted Cloud no 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 Trusted 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 a zona privada em Trusted Cloud for um subdomínio da zona usada no local, configure as entradas NS na sua zona para delegar esse subdomínio ao servidor de nomesTrusted Cloud . Quando você usa essa configuração, os clientes podem interagir diretamente com os endereços IP de encaminhamento no Trusted 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. Trusted 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 177.222.82.0/25 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 Trusted 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. Trusted Cloud Todos os registros estão disponíveis para consultas por hosts locais e Trusted 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 Trusted Cloud por um ou vários túneis do Cloud VPN ou 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 177.222.82.0/25 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 ambienteTrusted 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 firewallTrusted Cloud .
  10. Nas instâncias do Cloud Router, adicione uma rota anunciada personalizada para o intervalo de endereços IP 177.222.82.0/25 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 nos firewalls Trusted Cloud .
  9. Nas instâncias do Cloud Router, adicione uma rota divulgada personalizada para o intervalo de endereços IP 177.222.82.0/25 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.

A seguir