Google PCNE: Cloud DNS, Descoberta de Serviços e Resolução de Nomes Híbrida — Guia de estudos

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Faz parte do Google Professional Cloud Network Engineer — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O Cloud DNS é o serviço de DNS escalável e de alta disponibilidade do Google Cloud que suporta tanto zonas autoritativas públicas quanto DNS privado para VPCs. Ele também fornece primitivas de resolução de nomes híbrida — encaminhamento, peering, servidores de entrada, políticas de resposta e políticas de DNS — para integrar com DNS on-premises e multicloud. Esta seção aborda o ciclo de vida do DNS autoritativo, visibilidade e compartilhamento de zonas privadas, resolução híbrida, padrões de descoberta de serviços, segurança e integridade (incluindo DNSSEC e transferências de zona), gerenciamento avançado de tráfego com políticas de roteamento, DNS para endpoints de serviços privados e operações de dia 2, como solução de problemas, cache, logging e estratégias de migração/coexistência.

DNS Autoritativo e o Ciclo de Vida do DNS

Zonas gerenciadas e registros
- Uma zona gerenciada é um contêiner para conjuntos de registros de recursos (RRsets) para um único nome DNS (ápice da zona).
- Tipos de registro: A, AAAA, CNAME, MX, TXT, SRV, PTR, NS, SOA (e mais). O Cloud DNS não suporta CNAME no ápice da zona; use A/AAAA com o IP de um balanceador de carga para o mapeamento do ápice.
- Ciclo de vida: criar zona, adicionar/modificar registros (alterações transacionais), propagar e operar (monitorar/registrar/proteger).
- Importe de arquivos BIND existentes para acelerar a migração:
  - Exemplo: gcloud dns record-sets import ZONE_FILE –zone-file-format –zone MANAGED_ZONE
Zonas públicas vs. privadas
- Zonas públicas são acessíveis globalmente através dos nameservers autoritativos públicos do Google. Delegue no registrador (registrar) atualizando os registros NS no pai.
- Zonas privadas respondem apenas para as redes VPC anexadas. Elas são resolvidas pelos resolvers com escopo de VPC do Google para instâncias nessas VPCs e, opcionalmente, para clientes híbridos via encaminhamento de entrada (inbound forwarding).
Propagação e TTLs
- Dentro do Google Cloud, as alterações de registro se tornam ativas em segundos; a invalidação de cache externo depende do TTL.
- Trade-offs do TTL: TTLs curtos permitem agilidade e cutovers mais seguros, mas aumentam a carga de consultas e podem reduzir a eficiência do cache; TTLs longos reduzem a carga, mas prolongam respostas desatualizadas. Prática comum: 60–300s para serviços dinâmicos; 600–3600s para registros estáveis. Antes de cutovers, reduza o TTL com 24–48 horas de antecedência.

Visibilidade de Zona Privada, Associação de VPC e Design entre Projetos

Anexando zonas privadas a VPCs
- Uma zona privada é explicitamente associada a uma ou mais redes VPC. A associação pode abranger projetos (com o IAM apropriado, como dns.admin na zona e permissão para vincular redes).
- Precedência: a correspondência de sufixo mais longo entre as zonas privadas anexadas a uma VPC prevalece; tenha cuidado ao sobrepor zonas privadas (por exemplo, svc.corp.internal. e corp.internal.).
- Padrões de compartilhamento entre VPCs
  - Anexação direta (Direct attach): anexe a mesma zona privada a múltiplas VPCs. Operacionalmente simples; evite anexar onde não for necessário para reduzir o raio de impacto (blast radius).
  - Shared VPC: centralize a administração do DNS no projeto host enquanto expõe o DNS aos projetos de serviço, anexando a VPC das sub-redes às zonas.
  - Zonas de peering de DNS: quando o VPC peering é usado entre redes, uma zona de peering na VPC consumidora pode resolver registros privados da VPC produtora sem duplicar as zonas.
Modos de falha e proteções (guardrails)
- Sombreamento (Shadowing): uma zona privada com o mesmo nome de uma zona pública faz com que os clientes nas VPCs anexadas prefiram as respostas privadas, potencialmente quebrando o acesso a endpoints públicos. Use o split-horizon intencionalmente, documente e teste.
- Anexação excessiva (Over-attachment): anexar uma zona privada de forma ampla pode vazar nomes internos. Siga o princípio do menor privilégio e use subdomínios separados (com escopo de região/serviço) para limitar o escopo.
- Separação de IAM: delegue os direitos de alteração de DNS (dns.admin) separadamente dos direitos de anexação de rede (permissão para vincular redes) para alcançar domínios de administração separados.

Exemplo rápido: criar e anexar uma zona privada

gcloud dns managed-zones create corp-internal \
  --dns-name=corp.internal. \
  --visibility=private \
  --description="Private corp zone" \
  --networks=prod-vpc,stg-vpc

Resolução de Nomes Híbrida: Encaminhamento, Peering e Políticas

Zonas de encaminhamento
- Encaminham autoritativamente consultas para um sufixo (por exemplo, onprem.corp.) para servidores de nomes específicos (on-prem ou em outras nuvens). Use quando você não hospeda a zona no Cloud DNS, mas precisa de resolução transparente a partir do GCP.
- Evite loops: garanta que os encaminhadores on-prem não apontem de volta para o Cloud DNS para o mesmo sufixo.
Zonas de peering
- Resolvem zonas privadas hospedadas em uma VPC em peering. Requer conectividade de VPC Peering; não é transitivo. Use para arquiteturas hub-and-spoke para centralizar o DNS privado em uma VPC hub.
Políticas de DNS
- Encaminhamento de saída (outbound): instâncias em uma VPC enviam consultas recursivas para resolvedores on-prem para domínios não resolvidos nas zonas privadas do Cloud DNS. Configure através de uma política de DNS com IPs de servidores de nomes de destino alcançáveis via Cloud VPN/Interconnect.
- Servidores de entrada (inbound): resolvedores on-prem encaminham consultas para IPs de encaminhamento de entrada fornecidos pelo Google (o range 35.199.192.0/20 é alocado automaticamente) para resolver zonas privadas do Cloud DNS. Use para estender o DNS privado do GCP para o ambiente on-prem e outras nuvens.
- Log de consultas: habilite no nível da política para enviar logs de consulta do resolvedor para o Cloud Logging para análise e solução de problemas. Para zonas públicas, habilite o log de consultas por zona para consultas autoritativas.
Políticas de resposta
- Defina regras para modificar respostas (por exemplo, retornar NXDOMAIN para domínios maliciosos conhecidos ou sintetizar registros A internos para sobrescrever respostas públicas). Aplique com cuidado; valide que domínios críticos de terceiros não sejam bloqueados inadvertidamente.
Pré-requisitos de conectividade
- Para que o encaminhamento de entrada/saída funcione, garanta a conectividade híbrida (Cloud VPN ou Interconnect) e que as regras de firewall permitam UDP/TCP na porta 53 em ambas as direções, conforme necessário. O comportamento da fragmentação de UDP e do EDNS0 varia entre as redes — se ocorrerem problemas de MTU, permita o fallback para TCP e considere ajustar o buffer do EDNS(0) nos resolvedores on-prem.
Armadilhas comuns
- Alcançabilidade assimétrica: se o encaminhamento de saída aponta para resolvedores on-prem, mas o tráfego de retorno é bloqueado por firewall ou assimetria de roteamento, as consultas expiram (timeout). Verifique as rotas aprendidas pelo Cloud Router e permita os fluxos de resposta de DNS.
- Sufixos divididos: sufixos corporativos sobrepostos (corp.local vs. corp.internal) podem causar correspondências inesperadas no caminho de busca do resolvedor. Padronize os caminhos de busca e a propriedade dos sufixos.

Exemplos curtos:

# Outbound forwarding policy to on-prem resolvers
gcloud dns policies create corp-outbound \
  --networks=prod-vpc \
  --forwarding-targets=10.1.0.10,10.1.0.11 \
  --enable-logging

# Forwarding zone for partner domain
gcloud dns managed-zones create partner-fwd \
  --dns-name=partner.example. \
  --visibility=private \
  --forwarding-targets=172.16.10.53,172.16.11.53 \
  --networks=prod-vpc

Descoberta de Serviços, Split-Horizon e Endpoints Privados

DNS Split-horizon
- Serve respostas diferentes para o mesmo nome, interna e externamente. Padrão típico: o nome público foo.example.com resolve para um IP Anycast público; o nome interno foo.example.com resolve para um endereço RFC1918 de um ILB. Implemente com uma zona pública e uma zona privada de mesmo nome, delimitando cuidadosamente o escopo da zona privada para as VPCs apropriadas.
Nomenclatura de serviços internos
- Use sufixos internos consistentes (por exemplo, svc.corp.internal) e registros orientados a serviço (A/AAAA, SRV ou TXT específicos para descoberta). Mantenha TTLs baixos para serviços escalados dinamicamente.
- Descoberta de serviços no GKE: nomes internos do cluster permanecem dentro do CoreDNS (svc.cluster.local). Para exposição entre namespaces/VPCs, publique VIPs de ILB em zonas privadas do Cloud DNS ou use a integração com o Service Directory.
Integração com o Service Directory
- Publique endpoints de serviço no DNS automaticamente via Service Directory e Cloud DNS, emitindo registros SRV e A por namespace/serviço. Útil para desacoplar produtores e consumidores e suportar a descoberta de instâncias de serviço ciente do estado de saúde (health-aware).
Endpoints de serviço privados
- Private Service Connect (PSC) para APIs do Google: direcione googleapis.com de forma privada usando endpoints do PSC, ou use os VIPs restritos das APIs do Google (199.36.153.8/30) com uma zona privada para googleapis.com. O PSC oferece conectividade IP privada e localmente regional com controle por endpoint; o VIP restrito é mais simples, mas ainda usa faixas de IP públicas alcançáveis por meio de rotas padrão.
- PSC para serviços de produtores: crie registros A/AAAA em uma zona privada apontando para o endpoint do PSC ou para o VIP do ILB. Para domínios internos personalizados, gerencie a zona privada no Cloud DNS e anexe-a às VPCs consumidoras.
Trade-offs
- PSC vs. VIP Restrito: o PSC oferece controle granular e evita caminhos de inspeção de saída (egress); requer configuração de endpoint/DNS por região. O VIP Restrito é rápido de implantar, mas usa VIPs compartilhados e pode interagir com políticas de roteamento de saída.
- Risco do Split-horizon: zonas privadas com escopo incorreto podem criar um “black-hole” no acesso a SaaS públicos. Valide por meio de VMs canário e logs de consulta antes de uma implementação ampla.

Exemplo curto: mapeamento de ILB interno

; Private zone: corp.internal.
web.svc.corp.internal.  60  IN  A 10.20.0.15

Segurança, Gerenciamento de Tráfego, Operações e Migração

DNSSEC e integridade
- Zonas públicas: ative a assinatura DNSSEC no Cloud DNS e publique o registro DS no registrador para proteger contra spoofing e envenenamento de cache. Planeje janelas de rotação de chaves e monitore falhas de validação.
- Zonas privadas: a validação/assinatura DNSSEC geralmente é desnecessária porque a resolução ocorre em redes confiáveis; foque na segurança do transporte (links híbridos) e no fortalecimento (hardening) do resolvedor.
Transferências de zonas gerenciadas
- O Cloud DNS pode atuar como primário ou secundário para AXFR/IXFR. Use TSIG para autenticar/autorizar transferências e NOTIFY para propagação em tempo hábil. Padrões de transferência de zona simplificam a coexistência durante migrações e suportam secundários on-premise para necessidades regulatórias ou de resiliência.
- Modos de falha: transferência bloqueada por firewalls, incompatibilidade de chave TSIG, serial SOA não incrementado ou IXFR desativado no primário causando AXFRs completos.
Políticas de roteamento e verificações de integridade
- O Cloud DNS suporta políticas de direcionamento de tráfego (ponderada, geográfica, de latência e de failover). Anexe verificações de integridade aos endpoints para remover automaticamente respostas de endpoints não íntegros.
- Dicas de design: mantenha pequenos os conjuntos de registros por alvo da política; prefira o escopo regional alinhado à presença do usuário; combine TTLs baixos com intervalos de detecção de falhas para limitar o tempo de failover.
- Armadilhas: mapas geográficos excessivamente granulares podem causar complexidade operacional; a falta de um sinal de integridade consistente leva à oscilação (flapping) — use limiares de estabilização e timeouts de verificação de integridade alinhados ao comportamento da aplicação.
Solução de problemas
- Ferramentas: dig/nslookup com +trace, +short e +dnssec para validar as cadeias; revise o Cloud Logging para logs de consulta do resolvedor (políticas de DNS) e logs de consulta autoritativa (zonas gerenciadas).
- Cache: confirme qual resolvedor você está testando (o /etc/resolv.conf da VM geralmente aponta para o resolvedor da VPC do Google). Limpe os caches do resolvedor local ao testar alterações de TTL. Considere o cache negativo (RFC 2308): respostas NXDOMAIN são armazenadas em cache conforme o SOA MINIMUM/TTL negativo.
- Problemas comuns: loops entre o encaminhamento de saída e encaminhadores condicionais on-premise; bloqueio da porta UDP 53 ou problemas de MTU causando respostas truncadas; zonas públicas ofuscadas por zonas privadas.
Padrões operacionais
- Controle de alterações: agrupe alterações com transações, reduza os TTLs antes dos cutovers e use a anexação de VPC canário para validar a visibilidade.
- Logging e monitoramento: ative o log de consultas seletivamente; exporte logs para o BigQuery para análise de tendências e crie alertas sobre picos de SERVFAIL/NXDOMAIN.
- Controle de acesso: separe as funções de alteração de registros das funções de anexação de rede; aplique o princípio do menor privilégio nos editores de políticas de resposta para evitar bloqueios de domínio inadvertidos.
Migração e coexistência
- Coexistência: configure o Cloud DNS como secundário via AXFR/IXFR enquanto o DNS on-premise permanece como primário; ou o inverso (Cloud DNS como primário, secundários on-premise). Use TSIG e allow-listing.
- Encaminhamento condicional: para domínios que permanecem on-premise, crie zonas de encaminhamento ou políticas de encaminhamento de saída. Garanta que os links híbridos tenham alta disponibilidade (VPNs duplas com peers distintos e Cloud Router).
- Ponte entre múltiplas organizações: conecte VPCs via Cloud VPN/Cloud Router, estabeleça encaminhamento condicional mútuo ou peering conforme apropriado e use transferências de zona para zonas sendo realocadas. Reduza os TTLs bem antes das alterações de NS ou DS no registrador.

Exemplos curtos:

# Enable authoritative query logging for a public zone
gcloud dns managed-zones update prod-public --enable-logging

# Create inbound servers policy (IP allocation is automatic)
gcloud dns policies create corp-inbound --networks=prod-vpc

Cenário de Problema Prático

A Contoso Retail e a Fabrikam Payments são organizações separadas do Google Cloud que precisam interoperar por um ano enquanto integram redes e DNS com o mínimo de tempo de inatividade. Cada organização usa um espaço não sobreposto de 10.0.0.0/8. A Contoso hospedará serviços internos em svc.contoso.internal; a Fabrikam continuará a hospedar pay.fabrikam.internal on-premise. Ambos os lados precisam resolver os nomes privados um do outro e migrar gradualmente algumas zonas para o Cloud DNS.

Abordagem:

Estabelecer conectividade híbrida resiliente
- Crie dois túneis Cloud VPN entre a VPC hub da Contoso e os roteadores on-premise da Fabrikam, cada um para um IP público distinto da Fabrikam, com BGP do Cloud Router em ambos os túneis.
- Justificativa: Túneis duplos mais roteamento dinâmico fornecem redundância de caminho e propagam rotas para os alvos de DNS automaticamente, reduzindo os riscos de roteamento assimétrico para UDP/TCP 53.
Implementar resolução de nomes condicional em ambas as direções
- Na Contoso, crie uma zona de encaminhamento fabrikam.internal que encaminha para os servidores DNS on-premise da Fabrikam (por exemplo, 172.20.10.53 e 172.20.11.53) e anexe-a às VPCs das aplicações.
- Na Fabrikam, configure encaminhadores condicionais no DNS on-premise para encaminhar svc.contoso.internal para os IPs de encaminhamento de entrada do Cloud DNS da Contoso, fornecidos por uma política de entrada do Cloud DNS.
- Justificativa: Zonas de encaminhamento evitam a duplicação de autoridade e permitem que cada lado mantenha seu DNS onde está hoje. Servidores de entrada estendem a resolução privada do Cloud DNS para a Fabrikam sem alterar amplamente seus resolvedores.
Proteger contra loops de encaminhamento e impor limites de visibilidade
- Garanta que os encaminhadores condicionais da Fabrikam não encaminhem contoso.internal de volta para a Contoso para nomes que a Fabrikam ainda possui; da mesma forma, a Contoso deve encaminhar apenas fabrikam.internal.
- Anexe as zonas privadas da Contoso apenas às VPCs que precisam delas; não anexe globalmente para reduzir o raio de impacto.
- Justificativa: Elimina loops de recursão de DNS e impede o ofuscamento de domínios públicos por zonas privadas.
Migrar uma zona compartilhada usando transferências de zonas gerenciadas
- Para uma zona compartilhada legada legacy.shared.internal atualmente hospedada no BIND primário da Fabrikam, configure o Cloud DNS como secundário com TSIG e adicione o primário da Fabrikam à lista de permissões (allow-list) para AXFR/IXFR. Mantenha a Fabrikam como primária durante o período de coexistência.
- Justificativa: O modo secundário fornece sincronização em tempo real sem alterar os clientes. Ele permite uma validação segura na Contoso, mantendo uma única fonte da verdade.
Introduzir split-horizon para serviços expostos externamente
- Crie uma zona pública contoso.example com registros apontando para o IP de um balanceador de carga HTTPS global para clientes. Crie uma zona privada de nome idêntico anexada às VPCs internas que mapeia os mesmos nomes para endereços de ILB internos.
- Justificativa: Usuários externos continuam a acessar os balanceadores de carga de borda; serviços internos acessam os ILBs privados sobre RFC1918, otimizando a latência e o custo, mantendo nomes de host consistentes.
Fornecer acesso privado às APIs do Google sem sair através de firewalls
- Para VMs da Contoso sem IPs externos, ative o Private Service Connect para APIs do Google e crie a zona DNS privada gerenciada para googleapis.com que mapeia para os endpoints do PSC.
- Justificativa: Garante que o acesso ao BigQuery e ao Pub/Sub permaneça privado e local à VPC, evitando dispositivos de egresso de terceiros e preservando a postura de segurança.
Habilitar observabilidade e controle
- Ative o log de consultas do Cloud DNS na política de DNS da Contoso para as VPCs envolvidas e o log de consultas autoritativas nas zonas públicas. Crie regras de política de resposta para bloquear domínios maliciosos conhecidos em toda a organização.
- Justificativa: A telemetria de consultas auxilia na solução de problemas e no planejamento de capacidade; as políticas de resposta fornecem controle central para segurança sem precisar alterar cada resolvedor.
Executar o gerenciamento de mudanças com TTLs seguros
- Reduza os TTLs para 60s para os registros que estão sendo migrados uma semana antes das mudanças. Após a validação e o cutover (por exemplo, ao mudar um serviço de on-premise para um ILB do GCP), aumente gradualmente os TTLs para 300–600s.
- Justificativa: TTLs curtos limitam o risco durante as transições; restaurar TTLs mais altos melhora a eficiência do cache após a estabilização.
Testar, validar e fortalecer (hardening)
- A partir de VMs canário em ambos os lados, execute dig com +trace e verifique os caminhos autoritativos, confirme que não há picos de SERVFAIL/NXDOMAIN nos logs e simule falhas de link para observar o comportamento do DNS com a redundância da VPN.
- Justificativa: A validação proativa detecta problemas de loop/visibilidade precocemente; simulações de falha verificam se a resolução híbrida sobrevive a incidentes de transporte sem impacto para o usuário.