Visão geral dos endpoints de saída

Este documento oferece 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 ativar o encaminhamento direto de consultas DNS de redes VPC para resolvedores de DNS externos e locais usando endereços IP particulares. O uso de endpoints de saída oferece controle granular sobre o tráfego DNS de saída e melhora sua capacidade de desbloquear casos de uso de resolução de DNS híbrida 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

Os endpoints de saída permitem controlar os endereços IP de origem do tráfego DNS de saída, ativando o 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 existente.

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 do host estiver autorizada para uma zona de encaminhamento global padrão 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 vão rotear automaticamente as consultas de saída por endpoints de saída regionais sem exigir modificações no nível do cluster ou zonas de encaminhamento zonais.

Para saber mais sobre como migrar a configuração de encaminhamento de DNS atual 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 e usa a sub-rede somente proxy dessa rede para o endereço IP de origem.

Ao anexar endpoints de saída às zonas de encaminhamento ou à política de servidor, o Cloud DNS tenta primeiro rotear as consultas DNS pelo endpoint de saída com a 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 de menor latência e taxa de erros. Os fatores a seguir aumentam a classificação de um destino de encaminhamento:

  • Maior número de respostas DNS bem-sucedidas processadas pelo destino de encaminhamento. As respostas DNS bem-sucedidas também incluem respostas NXDOMAIN.
  • Menor latência para comunicação com o destino de encaminhamento.
  • Distância geográfica mais curta 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 proteção contra interrupções regionais, é possível configurar 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 mínima de consulta. Se a conectividade híbrida for provisionada apenas em regiões selecionadas, os endpoints em outras regiões de computação ainda poderão ser roteados por essas conexões para alcançar seus 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 ele. 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 aprimorado e começar a preferi-lo novamente para consultas futuras.

É possível ter até 10 endpoints de saída por projeto por região, mas você pode solicitar um aumento de cota no Google Cloud console, se necessário. É possível anexar até 100 endpoints de saída a uma zona de encaminhamento ou política de servidor.

Consultas de rota 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 roteie 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 com acoplamento rígido. Independentemente do local, o Cloud DNS escolhe o endpoint que historicamente forneceu a menor latência.

A seguir, apresentamos uma visão geral detalhada do que é necessário fazer para rotear consultas para resolvedores locais regionais:

  • Criar uma zona com uma política de geolocalização: crie uma nova zona particular 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 seus IPs de servidor DNS local e aplique uma política de roteamento de geolocalização. Configure a política para retornar IPs de resolvedor para consultas originadas dessa região específica. Por exemplo, retorne IPs de resolvedor europeus para consultas originadas de regiões europeias Google Cloud .
  • Usar o FQDN como 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 europeia) a essa zona de encaminhamento.

Quando uma VM em uma região faz uma consulta, o sistema segue um processo de roteamento de 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 será escolhido para uma consulta de uma VM na Europa).
  • Resolução de destino: o endpoint de saída selecionado resolve o FQDN de destino (onprem-resolvers.example.com). Como o endpoint de saída é um recurso regional localizado na região especificada, a política de geolocalização identifica a origem da consulta como essa região e retorna o endereço IP específico configurado para ela. Em seguida, o endpoint de saída encaminha a consulta original para o IP do servidor DNS de destino.

Para mais informações, consulte o tutorial 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 A Google Cloud VPC é um recurso global que pode conter sub-redes em várias regiões. Se uma VM fizer uma consulta de 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 com a classificação mais alta, que existe na mesma rede VPC e está configurado na zona de encaminhamento ou na política de 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 exigir que o resolvedor local veja um endereço IP de origem distinto para cada rede VPC, siga estas etapas:

  1. Criar um endpoint de saída em cada rede VPC: para mais informações, consulte Criar um endpoint de saída.
  2. Criar uma zona de encaminhamento ou 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 resulta em VMs em cada rede VPC enviando consultas pelo endpoint de saída na rede VPC. 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, permitindo que ela aplique configurações diferentes para o tráfego de cada rede.

Encaminhamento unificado em diferentes redes VPC (hub e spoke)

É possível configurar uma zona de encaminhamento ou 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 de hub e a rede VPC em que a consulta é originada (o spoke), já que o Cloud DNS processa 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 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 do hub.
  2. Crie uma zona de encaminhamento ou política de servidor na rede VPC do spoke e configure-a para usar o endpoint de saída da rede do hub.

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

Suporte para VPC compartilhada

Os endpoints de saída oferecem suporte a implantações de VPC compartilhada. O endpoint e a sub-rede somente proxy associada são criados centralmente no projeto host. Os projetos de serviço podem criar zonas de encaminhamento particulares 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 DNS de produção contra mudanças acidentais de infraestrutura, como exclusões ou modificações.

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

Uma sub-rede somente proxy ou 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 todas as zonas de encaminhamento ou 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 somente proxy.
  3. Excluir a sub-rede somente proxy: depois de confirmar que nenhum outro recurso está usando a sub-rede somente proxy, exclua-a.
  4. Excluir a rede VPC: depois que todas as outras dependências da VPC forem removidas, você poderá 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 de serviço. Para modificar a sub-rede, siga as diretrizes atuais e migre primeiro para uma nova sub-rede.

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

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

Previsibilidade de IP de origem dedicado para firewalls locais

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

  • Implantação em uma rede VPC de saída dedicada: crie uma rede VPC dedicada com uma sub-rede normal (para o endereço IP do endpoint de saída) e uma sub-rede somente proxy regional reservada exclusivamente para o Cloud DNS (--purpose=REGIONAL_MANAGED_PROXY e --role=ACTIVE).
  • Isolar 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 roteia consultas internamente na Google Cloud infraestrutura. Portanto, a conectividade de rede direta entre essas redes VPC não é necessária.
  • Conectar a rede VPC de saída dedicada a destinos de encaminhamento externos: Configure a conectividade apenas entre a rede VPC de saída dedicada e seus servidores de nomes de destino externos ou locais. Estabeleça esse caminho usando o seguinte:
    • Peering de rede VPC para uma VPC de trânsito atual: essa é a abordagem recomendada e mais econômica. Se 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 o peering da rede VPC de DNS dedicada para 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:

  • O 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 somente proxy regional 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.

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

  • Suporte apenas para 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.

  • A vinculação de endpoints de saída a uma rede em projetos não é compatível: 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 residir no mesmo projeto que a rede VPC e a sub-rede a que se anexam.

  • Limitado a destinos particulares: os endpoints de saída só oferecem suporte ao encaminhamento para destinos particulares e não podem ser usados como um proxy de saída ou âncora de IP de origem estático para tráfego DNS da Internet pública. As consultas para destinos da Internet pública são resolvidas diretamente pela borda de 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 um mecanismo de encaminhamento: o mecanismo de encaminhamento (o intervalo 35.199.192.0/19 padrão ou endpoints de saída) é configurado na zona de encaminhamento ou no nível da política de servidor. No entanto, não é possível usar os dois métodos simultaneamente para a mesma zona ou política.

A seguir