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.

Neste documento, descrevemos as práticas recomendadas para encaminhar solicitações de DNS particular 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

Aprenda sobre os conceitos de DNS em 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ínio.
  • 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 noGoogle Cloud. Para mais informações sobre os métodos de acesso aos registros DNS, consulte Usar encaminhamento condicional para acessar registros DNS a partir de ambientes locais.Google Cloud
  • 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 multicloud.

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:

  • Use nomes de domínio diferentes para servidores locais e para 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 separados, como example.com e example.cloud.

  • Use o domínio 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 Google Cloud no gcp.corp.example.com. 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 deGoogle Cloud . No caso do domínio example.com, Google Cloud pode usar corp.example.com e o ambiente local pode usar dc.corp.example.com. 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 Google Cloud e para o ambiente local. Nesse caso, o Google Cloud e o ambiente local usam 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 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 deGoogle 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 de 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 Serviço Gerenciado para Apache Spark, 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 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: