Visão geral dos endpoints de saída

Neste documento, apresentamos uma visão geral dos endpoints de saída do Cloud DNS. Os endpoints de saída podem ser anexados a zonas de encaminhamento ou políticas de servidor para permitir o encaminhamento direto de consultas DNS de redes VPC para resolvedores de DNS externos e locais usando endereços IP privados. O uso de endpoints de saída oferece controle granular sobre o tráfego de DNS de saída e melhora sua capacidade de desbloquear casos de uso de resolução de DNS híbrido e multicloud.

Para saber como criar, atualizar e associar endpoints de saída a zonas de encaminhamento ou políticas de servidor, consulte Criar e atualizar endpoints de saída.

Recursos de endpoints de saída

Com os endpoints de saída, é possível controlar os endereços IP de origem do tráfego de DNS de saída, permitindo um comportamento específico da rede VPC ao atribuir um intervalo de saída exclusivo para cada rede. O intervalo de saída exclusivo supera as limitações de roteamento do intervalo de proxy de encaminhamento fixo atual.

Os clusters do GKE herdam automaticamente os endpoints de saída ao consultar destinos externos com a rede VPC do host. Se a rede VPC host for autorizada para uma zona de encaminhamento padrão global do Cloud DNS ou uma política de servidor configurada com endpoints de saída, os pods que usam a resolução de DNS da VPC encaminharão automaticamente as consultas de saída por meio de endpoints de saída regionais, sem exigir modificações no nível do cluster ou zonas de encaminhamento zonais.

Para saber como migrar sua configuração de encaminhamento de DNS para endpoints de saída, consulte Migrar uma configuração de encaminhamento do Cloud DNS para endpoints de saída.

Arquitetura de endpoints de saída e roteamento de consultas

Um endpoint de saída é criado em uma rede VPC específica (usando uma sub-rede regular na região de destino para o endereço IP interno do endpoint) e usa a sub-rede somente proxy regional dessa rede para o endereço IP de origem.

Quando você anexa endpoints de saída às zonas de encaminhamento ou à política de servidor, o Cloud DNS primeiro tenta rotear as consultas DNS pelo endpoint de saída de classificação mais alta usando o algoritmo de classificação de destino atual. Se esse endpoint não estiver íntegro, o Cloud DNS vai tentar o próximo endpoint com a classificação mais alta. O endpoint de saída geograficamente mais próximo é preferencial, mas não garantido.

O algoritmo de classificação para servidores de destino é executado automaticamente e se baseia no padrão de failover das zonas de encaminhamento atuais: seleção de IP com menor latência e taxa de erro. Os seguintes fatores aumentam a classificação de um destino de encaminhamento:

  • Maior número de respostas DNS bem-sucedidas processadas pelo destino de encaminhamento. As respostas de DNS bem-sucedidas também incluem respostas NXDOMAIN.
  • Menor latência para comunicação com o destino de encaminhamento.
  • Distância geográfica menor até o endpoint de saída. Se os dados de sucesso e latência não estiverem disponíveis, o destino mais próximo será preferencial.

Para se proteger contra falhas temporárias regionais, configure endpoints de saída em pelo menos duas regiões em que você executa cargas de trabalho de computação. Essa abordagem fornece ao Cloud DNS um destino de failover regional e mantém a latência de consulta mínima. Se a conectividade híbrida for provisionada apenas em algumas regiões, os endpoints em outras regiões de computação ainda poderão rotear por essas conexões para alcançar os resolvedores locais.

Mesmo que o endpoint com a classificação mais alta esteja em uma região diferente, o Cloud DNS continua roteando consultas para esse endpoint. Por exemplo, se um endpoint na Região A ficar indisponível, o tráfego será roteado automaticamente para um endpoint íntegro na Região B. Quando o endpoint na Região A estiver íntegro novamente, o algoritmo de classificação vai detectar o desempenho melhorado e começar a preferi-lo novamente para as próximas consultas.

É possível ter até 10 endpoints de saída por projeto e por região, e até 100 endpoints de saída anexados a uma zona de encaminhamento ou política de servidor.

Encaminhar consultas para resolvedores locais regionais

O Cloud DNS não garante que o tráfego seja enviado ao endpoint na mesma região da VM de origem, mas é possível usar políticas de roteamento de geolocalização para rotear o tráfego para o servidor de nomes de destino mais próximo. Embora o Cloud DNS encaminhe preferencialmente o tráfego para o endpoint de saída na região mais próxima da consulta de origem e do servidor de nomes de destino, a região do servidor de nomes de destino e a região do endpoint de saída não estão rigidamente acopladas. Independentemente do local, o Cloud DNS escolhe o endpoint que historicamente forneceu a menor latência.

Veja a seguir uma visão geral de alto nível do que você precisa fazer para rotear consultas para resolvedores regionais no local:

  • Criar uma zona com uma política de geolocalização: crie uma nova zona privada do Cloud DNS para um FQDN que você controla (por exemplo, onprem-resolvers.example.com) autorizado para sua rede VPC. Nessa zona, crie registros A para os IPs do servidor DNS local e aplique uma política de roteamento de geolocalização. Configure a política para retornar IPs de resolvedor para consultas provenientes dessa região específica. Por exemplo, retornar IPs de resolvedor europeus para consultas provenientes de regiões europeias do Google Cloud .
  • Use o FQDN como o destino de encaminhamento: na zona de encaminhamento, use o FQDN que você acabou de criar (onprem-resolvers.example.com) como o servidor DNS de destino.
  • Configurar endpoints de saída: associe seus endpoints de saída regionais (por exemplo, um em uma região dos EUA e outro em uma região da Europa) a essa zona de encaminhamento.

Quando uma VM em uma região faz uma consulta, o sistema segue um processo de roteamento em duas etapas:

  • Seleção de endpoint: o Cloud DNS avalia a lista de endpoints de saída associados à zona de encaminhamento e seleciona o melhor endpoint (por exemplo, um endpoint na Europa provavelmente é escolhido para uma consulta de uma VM na Europa).
  • Resolução de destino: o Cloud DNS resolve o FQDN de destino (onprem-resolvers.example.com) para a região de origem da consulta. Em seguida, o Cloud DNS encaminha a consulta original pelo endpoint de saída selecionado para o IP do servidor DNS resolvido. A política de geolocalização identifica a origem da consulta como essa região e retorna o endereço IP específico que você configurou para essa região.

Para mais informações, consulte o tutorial de encaminhamento de DNS de saída para FQDN do Cloud DNS.

Encaminhamento de uma região sem um endpoint local em uma única rede VPC

Uma rede VPC do Google Cloud é um recurso global que pode conter sub-redes em várias regiões. Se uma VM fizer uma consulta em uma região em que você não configurou um endpoint de saída, o encaminhamento ainda será bem-sucedido. A consulta será roteada entre regiões para o endpoint de saída disponível de classificação mais alta que existe na mesma rede VPC e está configurado na zona de encaminhamento ou na política do servidor.

Encaminhamento de várias redes VPC na mesma região com isolamento de IP de origem

Se você precisar encaminhar consultas de várias redes VPC na mesma região e precisar que o resolvedor local veja um endereço IP de origem diferente para cada rede VPC, siga estas etapas:

  1. Crie um endpoint de saída em cada rede VPC: para mais informações, consulte Criar um endpoint de saída.
  2. Crie uma zona de encaminhamento ou uma política de servidor em cada rede VPC: autorize a zona de encaminhamento ou a política de servidor apenas para essa rede VPC e use apenas o endpoint de saída dessa rede VPC.

Essa ação faz com que as VMs em cada rede VPC enviem consultas pelo endpoint de saída na rede VPC delas. Cada endpoint encaminha a consulta para o resolvedor local. A rede local vê o endereço IP de origem da sub-rede somente proxy de cada rede VPC, o que permite aplicar configurações diferentes para o tráfego de cada rede.

Encaminhamento unificado em diferentes redes VPC (Hub-and-Spoke)

É possível configurar uma zona de encaminhamento ou uma política de servidor para usar um endpoint de saída em uma rede VPC diferente e centralizada (o hub). A conectividade de rede não é necessária entre a rede hub e a rede VPC em que a consulta se origina (o spoke), já que o Cloud DNS lida com o encaminhamento de consultas internamente.

É necessário configurar a conectividade de rede entre o endpoint de saída e os destinos de encaminhamento na zona de encaminhamento ou na política de servidor. A conectividade pode ser estabelecida usando o Cloud Interconnect ou o Cloud VPN para alcançar os resolvedores locais. O peering de rede VPC pode ser usado para alcançar destinos de encaminhamento em outra rede VPC.

  1. Crie um endpoint de saída na rede VPC hub.
  2. Crie uma zona de encaminhamento ou uma política de servidor na rede VPC spoke e configure-a para usar o endpoint de saída da rede hub.

As VMs nas redes VPC spoke enviam consultas pelo endpoint de saída na rede VPC hub. O endpoint encaminha a consulta para o resolvedor local.

Suporte para VPC compartilhada

Os endpoints de saída são compatíveis com implantações de VPC compartilhada. O endpoint, a sub-rede regular e a sub-rede somente proxy associada são criados de forma centralizada no projeto host. Os projetos de serviço podem herdar zonas de encaminhamento ou políticas de servidor criadas no projeto host ou criar as próprias zonas de encaminhamento privadas ou políticas de servidor e vinculá-las entre projetos ao endpoint de saída centralizado no projeto host (exigindo dns.outboundEndpoints.bindPrivateDNSZone ou dns.outboundEndpoints.bindPrivateDNSPolicy no projeto host).

Gerenciar recursos de rede associados a endpoints de saída

Os endpoints de saída do Cloud DNS aplicam dependências de ciclo de vida estritas com as redes VPC e sub-redes subjacentes para ajudar a proteger o tráfego de DNS de produção contra mudanças acidentais na infraestrutura, como exclusões ou modificações.

Excluir a sub-rede somente proxy ou a rede VPC quando estiver em uso por um endpoint de saída

Uma sub-rede normal, uma sub-rede somente proxy ou uma rede VPC em uso ativo por um endpoint de saída é protegida contra exclusão para evitar interrupções. A tentativa de excluir esses recursos resulta em um erro. Se você quiser excluir esses recursos, siga estas etapas na ordem exata:

  1. Atualizar a configuração do Cloud DNS: edite as zonas de encaminhamento ou as políticas de servidor que usam o endpoint de saída e remova-o da configuração para que ele não seja mais usado.
  2. Excluir o endpoint de saída: depois que o endpoint não estiver mais em uso, você poderá excluí-lo. Essa ação libera a dependência da sub-rede normal e da sub-rede somente proxy.
  3. Exclua as sub-redes: depois de confirmar que nenhum outro recurso as está usando, exclua as sub-redes somente proxy e as regulares.
  4. Exclua a rede VPC: depois que todas as outras dependências da VPC forem removidas, será possível excluir a rede VPC.

Modificação de sub-rede

Não é possível modificar diretamente uma sub-rede somente proxy quando um endpoint de saída a está usando ativamente. Essa restrição impede que você edite propriedades importantes, como o intervalo de endereços IP, o que ajuda a evitar interrupções no serviço. Para modificar a sub-rede, siga as diretrizes atuais e migre primeiro para uma nova sub-rede.

Para modificar uma sub-rede que está sendo usada por um endpoint de saída, faça o seguinte:

  1. Crie uma sub-rede de backup: crie uma nova sub-rede somente proxy na mesma rede VPC e região. É preciso definir o papel dessa sub-rede como BACKUP durante a criação.
  2. Ative a nova sub-rede: atualize o papel da nova sub-rede para ACTIVE. Isso define automaticamente a sub-rede original como o papel BACKUP e começa a drenar as conexões ativas dela.
  3. Aguardar a diminuição: aguarde a conclusão do processo de diminuição da conexão.
  4. Exclua a sub-rede antiga: agora é possível excluir a sub-rede original quando ela estiver no papel BACKUP e não tiver conexões ativas.

Previsibilidade de IP de origem dedicada para firewalls no local

Se os firewalls de DNS locais exigirem um intervalo de endereços IP de origem dedicado e previsível isolado para o tráfego de DNS, recomendamos que você aplique a seguinte arquitetura:

  • Implantar em uma rede VPC de saída dedicada: crie uma rede VPC dedicada com uma sub-rede regular (para o endereço IP do endpoint de saída) e uma sub-rede regional somente proxy reservada exclusivamente para o Cloud DNS (--purpose=REGIONAL_MANAGED_PROXY e --role=ACTIVE).
  • Isole as redes VPC do aplicativo:não faça peering nem roteie as redes VPC do aplicativo para essa rede de saída dedicada. O Cloud DNS encaminha consultas internamente na infraestrutura do Google Cloud, portanto, a conectividade de rede direta entre essas redes VPC não é necessária.
  • Conecte a rede VPC de saída dedicada aos destinos de encaminhamento externos: configure a conectividade apenas entre a rede VPC de saída dedicada e os servidores de nomes de destino externos ou locais. Estabeleça esse caminho usando o seguinte:
    • Peering de rede VPC com uma VPC de trânsito atual: essa é a abordagem recomendada e mais econômica. Se a sua organização já tiver uma rede VPC de trânsito central com o Cloud Interconnect ou o Cloud VPN para o local, faça peering da rede VPC de DNS dedicada com esse hub de trânsito. Essa abordagem evita o provisionamento de circuitos híbridos redundantes e minimiza os custos.
    • Conectividade híbrida direta: Interconexão dedicada, Interconexão entre nuvens ou Cloud VPN que termina diretamente na rede VPC de DNS dedicada.

Limitações

Os endpoints de saída têm as seguintes limitações:

  • Compartilhamento de IP de origem e sub-rede limitado a recursos na mesma região: os endpoints de saída alocam intervalos de IP de origem da sub-rede regional somente proxy da rede VPC a que estão anexados. Em implantações padrão, essa sub-rede somente proxy pode ser compartilhada com outros recursos regionais, como balanceadores de carga de aplicativo regionais.

  • Não há suporte para peering direto com sub-redes somente proxy: não é possível fazer peering direto com uma sub-rede somente proxy. A conectividade de rede com servidores de nomes externos precisa ser estabelecida por meio do roteamento de VPC padrão, como Cloud Interconnect, Cloud VPN ou peering de rede VPC.

  • Somente suporte a IPv4: o endereço IP de origem de um endpoint de saída é somente IPv4, e as consultas só podem ser encaminhadas para destinos IPv4 ou destinos de encaminhamento de FQDN em zonas de encaminhamento que são resolvidas para endereços IPv4.

  • Não é possível vincular endpoints de saída a uma rede em vários projetos: não é possível criar um endpoint de saída em um projeto de serviço anexado à rede VPC compartilhada de um projeto host. Os endpoints de saída precisam estar no mesmo projeto que a rede VPC e a sub-rede a que estão anexados.

  • Limitado a destinos particulares: os endpoints de saída só aceitam o encaminhamento para destinos particulares (incluindo RFC 1918, RFC 6598 e endereços não RFC 1918 roteados de forma particular configurados com --private-forward-targets ou forwardingPath: "private") e não podem ser usados como um proxy de saída ou âncora de IP de origem estática para o tráfego de DNS público da Internet. As consultas a destinos públicos da Internet são resolvidas diretamente pela borda anycast distribuída do Google para minimizar a latência e evitar dependências do Cloud NAT.

  • Escopo regional: os endpoints de saída são recursos regionais. É necessário criar endpoints em cada região em que você pretende usá-los.

  • Somente mecanismo de encaminhamento único: seu mecanismo de encaminhamento (o intervalo 35.199.192.0/19 padrão ou os endpoints de saída) é configurado no nível da zona de encaminhamento ou da política do servidor. No entanto, não é possível usar os dois métodos simultaneamente para a mesma zona ou política.

A seguir