Google PCNE: Cloud DNS, descubrimiento de servicios y resolución de nombres híbrida — Guía de estudio

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

Forma parte de la Google Professional Cloud Network Engineer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

Cloud DNS es el servicio de DNS escalable y de alta disponibilidad de Google Cloud que admite tanto zonas autoritativas públicas como DNS privado para VPC. También proporciona primitivas de resolución de nombres híbrida (reenvío, peering, servidores de entrada, políticas de respuesta y políticas de DNS) para integrarse con DNS on-premises y multicloud. Esta sección cubre el ciclo de vida del DNS autoritativo, la visibilidad y el uso compartido de zonas privadas, la resolución híbrida, los patrones de descubrimiento de servicios, la seguridad e integridad (incluyendo DNSSEC y transferencias de zona), la gestión avanzada de tráfico con políticas de enrutamiento, el DNS para endpoints de servicios privados y las operaciones del día 2, como la resolución de problemas, el almacenamiento en caché, el registro y las estrategias de migración/coexistencia.

DNS autoritativo y el ciclo de vida del DNS

Zonas administradas y registros
- Una zona administrada (managed zone) es un contenedor para conjuntos de registros de recursos (RRsets) para un único nombre DNS (ápice de la zona).
- Tipos de registro: A, AAAA, CNAME, MX, TXT, SRV, PTR, NS, SOA (y más). Cloud DNS no admite CNAME en el ápice de la zona; utilice A/AAAA con la IP de un balanceador de carga para el mapeo del ápice.
- Ciclo de vida: crear zona, añadir/modificar registros (cambios transaccionales), propagar y operar (monitorizar/registrar/asegurar).
- Importar desde archivos BIND existentes para acelerar la migración:
  - Ejemplo: gcloud dns record-sets import ZONE_FILE –zone-file-format –zone MANAGED_ZONE
Zonas públicas vs. privadas
- Las zonas públicas son accesibles globalmente a través de los servidores de nombres autoritativos públicos de Google. Delegue en el registrador (registrar) actualizando los registros NS en el padre.
- Las zonas privadas solo responden para las redes VPC adjuntas. Son resueltas por los resolutores de ámbito de VPC de Google para las instancias en esas VPC y, opcionalmente, para clientes híbridos a través del reenvío de entrada (inbound forwarding).
Propagación y TTL
- Dentro de Google Cloud, los cambios en los registros se activan en segundos; la invalidación de la caché externa depende del TTL.
- Compensaciones del TTL: los TTL cortos permiten agilidad y transiciones (cutovers) más seguras, pero aumentan la carga de consultas y pueden reducir la eficiencia de la caché; los TTL largos reducen la carga pero prolongan las respuestas obsoletas (stale). Práctica común: 60–300s para servicios dinámicos; 600–3600s para registros estables. Antes de una transición (cutover), reduzca el TTL con 24–48 horas de antelación.

Visibilidad de zonas privadas, asociación con VPC y diseño entre proyectos

Adjuntar zonas privadas a VPC
- Una zona privada se asocia explícitamente con una o más redes VPC. La asociación puede abarcar varios proyectos (con los permisos de IAM apropiados, como dns.admin en la zona y el permiso para vincular redes).
- Precedencia: la coincidencia del sufijo más largo entre las zonas privadas adjuntas a una VPC tiene prioridad; tenga cuidado al superponer zonas privadas (por ejemplo, svc.corp.internal. y corp.internal.).
- Patrones para compartir entre VPC
  - Vinculación directa (Direct attach): adjunte la misma zona privada a múltiples VPC. Es operativamente simple; evite adjuntarla donde no sea necesario para reducir el radio de impacto (blast radius).
  - Shared VPC: centralice la administración de DNS en el proyecto host mientras expone el DNS a los proyectos de servicio adjuntando la VPC de las subredes a las zonas.
  - Zonas de peering de DNS: cuando se utiliza VPC peering entre redes, una zona de peering en la VPC consumidora puede resolver registros privados de la VPC productora sin duplicar zonas.
Modos de fallo y medidas de protección (guardrails)
- Solapamiento (Shadowing): una zona privada con el mismo nombre que una zona pública hace que los clientes en las VPC adjuntas prefieran las respuestas privadas, lo que puede interrumpir el acceso a los endpoints públicos. Use split-horizon de forma intencionada, documéntelo y pruébelo.
- Vinculación excesiva (Over-attachment): adjuntar una zona privada de forma amplia puede filtrar nombres internos. Siga el principio de privilegio mínimo y use subdominios separados (con ámbito de región/servicio) para limitar el alcance.
- Separación de IAM: delegue los derechos de cambio de DNS (dns.admin) por separado de los derechos de vinculación de red (permiso para vincular redes) para lograr dominios de administración separados.

Ejemplo corto: crear y adjuntar una zona privada

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

Resolución de nombres híbrida: reenvío, peering y políticas

Zonas de reenvío
- Reenvían autoritativamente consultas para un sufijo (por ejemplo, onprem.corp.) a servidores de nombres específicos (locales o en otras nubes). Úsalas cuando no alojas la zona en Cloud DNS pero necesitas una resolución fluida desde GCP.
- Evita bucles: asegúrate de que los reenviadores locales no apunten de vuelta a Cloud DNS para el mismo sufijo.
Zonas de peering
- Resuelven zonas privadas alojadas en una VPC interconectada (peered). Requiere conectividad de VPC peering; no es transitivo. Úsalas para diseños de tipo hub-and-spoke para centralizar el DNS privado en una VPC hub.
Políticas de DNS
- Reenvío de salida: las instancias en una VPC envían consultas recursivas a resolutores locales para dominios que no se resuelven en las zonas privadas de Cloud DNS. Configúralo mediante una política de DNS con las IP de los servidores de nombres de destino, accesibles a través de Cloud VPN/Interconnect.
- Servidores de entrada: los resolutores locales reenvían consultas a las IP de reenvío de entrada proporcionadas por Google (autoasignadas en 35.199.192.0/20) para resolver las zonas privadas de Cloud DNS. Úsalo para extender el DNS privado de GCP al entorno local y a otras nubes.
- Registro de consultas: habilítalo a nivel de política para enviar los registros de consultas del resolutor a Cloud Logging para su análisis y solución de problemas. Para zonas públicas, habilita el registro de consultas por zona para las consultas autoritativas.
Políticas de respuesta
- Define reglas para modificar respuestas (por ejemplo, devolver NXDOMAIN para dominios maliciosos conocidos, o sintetizar registros A internos para sobrescribir respuestas públicas). Aplícalas con cuidado; valida que los dominios críticos de terceros no se bloqueen inadvertidamente.
Prerrequisitos de conectividad
- Para que el tráfico de entrada/salida funcione, asegura la conectividad híbrida (Cloud VPN o Interconnect) y que las reglas de firewall permitan UDP/TCP 53 en ambas direcciones según sea necesario. El comportamiento de EDNS0 y la fragmentación UDP varían entre redes; si ocurren problemas de MTU, permite el fallback a TCP y considera ajustar el búfer de EDNS(0) en los resolutores locales.
Errores comunes
- Alcanzabilidad asimétrica: si el reenvío de salida apunta a resolutores locales pero el tráfico de retorno está bloqueado por un firewall o por asimetría de enrutamiento, las consultas expirarán (timeout). Verifica las rutas aprendidas por Cloud Router y permite los flujos de respuesta de DNS.
- Sufijos divididos: los sufijos empresariales superpuestos (corp.local vs corp.internal) pueden causar coincidencias inesperadas en la ruta de búsqueda del resolutor. Estandariza las rutas de búsqueda y la propiedad de los sufijos.

Ejemplos cortos:

# 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

Descubrimiento de servicios, Split-Horizon y Endpoints privados

DNS Split-horizon
- Sirve respuestas diferentes para el mismo nombre interna y externamente. Patrón típico: el foo.example.com público resuelve a una IP pública Anycast; el foo.example.com interno resuelve a una dirección RFC1918 de un ILB. Impleméntalo con una zona pública y una zona privada del mismo nombre, acotando cuidadosamente la zona privada a las VPC apropiadas.
Nomenclatura de servicios internos
- Usa sufijos internos consistentes (por ejemplo, svc.corp.internal) y registros orientados a servicios (A/AAAA, SRV o TXT específicos para descubrimiento). Mantén TTLs bajos para servicios que escalan dinámicamente.
- Descubrimiento de servicios en GKE: los nombres internos del clúster permanecen dentro de CoreDNS (svc.cluster.local). Para la exposición entre namespaces/VPC, publica las VIP de los ILB en zonas privadas de Cloud DNS o usa la integración con Service Directory.
Integración con Service Directory
- Publica endpoints de servicio en DNS automáticamente a través de Service Directory y Cloud DNS, emitiendo registros SRV y A por cada namespace/servicio. Útil para desacoplar productores y consumidores y para soportar un descubrimiento de instancias de servicio consciente de su estado de salud (health-aware).
Endpoints de servicio privados
- Private Service Connect (PSC) para las API de Google: dirige googleapis.com de forma privada usando endpoints de PSC, o usa las VIP de las API de Google restringidas (199.36.153.8/30) con una zona privada para googleapis.com. PSC proporciona conectividad IP privada y local a nivel regional con control por endpoint; la VIP restringida es más simple pero sigue usando rangos de IP públicas accesibles a través de rutas por defecto.
- PSC para servicios de productor: crea registros A/AAAA en una zona privada que apunten al endpoint de PSC o a la VIP del ILB. Para dominios internos personalizados, gestiona la zona privada en Cloud DNS y vincúlala a las VPC consumidoras.
Ventajas y desventajas
- PSC vs. VIP restringida: PSC ofrece control granular y evita las rutas de inspección de salida; requiere configuración de endpoint/DNS por región. La VIP restringida es rápida de desplegar pero usa VIP compartidas y puede interactuar con las políticas de enrutamiento de salida.
- Riesgo de Split-horizon: las zonas privadas con un alcance mal definido pueden crear un agujero negro (black-hole) en el acceso a SaaS públicos. Valida mediante VMs canario y el registro de consultas antes de un despliegue generalizado.

Ejemplo corto: mapeo de ILB interno

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

Seguridad, gestión del tráfico, operaciones y migración

DNSSEC e integridad
- Zonas públicas: habilite la firma DNSSEC en Cloud DNS y publique los registros DS en el registrador para protegerse contra la suplantación de identidad (spoofing) y el envenenamiento de caché. Planifique las ventanas de rotación de claves y supervise los fallos de validación.
- Zonas privadas: la validación/firma de DNSSEC suele ser innecesaria porque la resolución se produce en redes de confianza; céntrese en la seguridad del transporte (enlaces híbridos) y en el fortalecimiento (hardening) de los resolutores.
Transferencias de zonas administradas
- Cloud DNS puede actuar como primario o secundario para AXFR/IXFR. Use TSIG para autenticar/autorizar transferencias y NOTIFY para una propagación oportuna. Los patrones de transferencia de zona simplifican la coexistencia durante las migraciones y admiten secundarios on-prem para necesidades regulatorias o de resiliencia.
- Modos de fallo: transferencia bloqueada por firewalls, discrepancia de la clave TSIG, número de serie SOA no incrementado o IXFR deshabilitado en el primario, lo que provoca transferencias AXFR completas.
Políticas de enrutamiento y verificaciones de estado
- Cloud DNS admite políticas de direccionamiento de tráfico (ponderado, geográfico, de latencia y de conmutación por error). Asocie verificaciones de estado a los endpoints para retirar automáticamente las respuestas no saludables.
- Consejos de diseño: mantenga pequeños los conjuntos de registros por cada objetivo de la política; prefiera un alcance regional alineado con la huella de los usuarios; combine TTL bajos con intervalos de detección de fallos para acotar el tiempo de conmutación por error.
- Errores comunes: los mapas geográficos demasiado granulares pueden causar complejidad operativa; la falta de una señal de estado consistente conduce a la inestabilidad (flapping); utilice umbrales de estabilización y tiempos de espera de verificación de estado alineados con el comportamiento de la aplicación.
Solución de problemas
- Herramientas: dig/nslookup con +trace, +short y +dnssec para validar las cadenas; revise Cloud Logging para ver los registros de consultas del resolutor (políticas de DNS) y los registros de consultas autoritativas (zonas administradas).
- Almacenamiento en caché: confirme qué resolutor está probando (el archivo /etc/resolv.conf de la VM generalmente apunta al resolutor de la VPC de Google). Vacíe las cachés del resolutor local al probar cambios de TTL. Considere el almacenamiento en caché negativo (RFC 2308): las respuestas NXDOMAIN se almacenan en caché según el TTL MÍNIMO/negativo del SOA.
- Problemas comunes: bucles entre el reenvío de salida y los reenviadores condicionales on-prem; bloqueo del puerto UDP 53 o problemas de MTU que causan respuestas truncadas; zonas públicas eclipsadas por zonas privadas.
Patrones operativos
- Control de cambios: agrupe los cambios con transacciones, reduzca los TTL antes de las transiciones (cutovers) y use la vinculación de VPC canary para validar la visibilidad.
- Registro y supervisión: habilite el registro de consultas de forma selectiva; exporte los registros a BigQuery para el análisis de tendencias y cree alertas sobre picos de SERVFAIL/NXDOMAIN.
- Control de acceso: separe los roles de cambio de registros de los roles de vinculación de red; aplique el mínimo privilegio en los editores de políticas de respuesta para evitar bloqueos de dominio involuntarios.
Migración y coexistencia
- Coexistencia: configure Cloud DNS como secundario a través de AXFR/IXFR mientras el DNS on-prem sigue siendo el primario; o a la inversa (Cloud DNS como primario, secundarios on-prem). Use TSIG y listas de permitidos (allow-listing).
- Reenvío condicional: para los dominios que permanecen on-prem, cree zonas de reenvío o políticas de reenvío de salida. Asegúrese de que los enlaces híbridos tengan alta disponibilidad (VPN duales con peers distintos y Cloud Router).
- Interconexión multiorganización: conecte las VPC a través de Cloud VPN/Cloud Router, establezca reenvío condicional mutuo o peering según corresponda, y use transferencias de zona para las zonas que se están reubicando. Reduzca los TTL mucho antes de los cambios de NS o DS en el registrador.

Ejemplos cortos:

# 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

Escenario de problema práctico

Contoso Retail y Fabrikam Payments son organizaciones de Google Cloud separadas que deben interoperar durante un año mientras integran sus redes y DNS con un tiempo de inactividad mínimo. Cada organización utiliza un espacio 10.0.0.0/8 que no se superpone. Contoso alojará servicios internos bajo svc.contoso.internal; Fabrikam continuará alojando pay.fabrikam.internal on-prem. Ambas partes necesitan resolver los nombres privados de la otra y migrar gradualmente algunas zonas a Cloud DNS.

Enfoque:

Establecer conectividad híbrida resiliente
- Crear dos túneles de Cloud VPN entre la VPC central (hub) de Contoso y los enrutadores on-prem de Fabrikam, cada uno hacia una IP pública distinta de Fabrikam, con BGP de Cloud Router en ambos túneles.
- Justificación: Los túneles duales más el enrutamiento dinámico proporcionan redundancia de ruta y propagan las rutas para los destinos de DNS automáticamente, reduciendo los riesgos de enrutamiento asimétrico para UDP/TCP 53.
Implementar la resolución de nombres condicional en ambas direcciones
- En Contoso, crear una zona de reenvío fabrikam.internal que reenvíe a los servidores DNS on-prem de Fabrikam (por ejemplo, 172.20.10.53 y 172.20.11.53) y vincularla a las VPC de las aplicaciones.
- En Fabrikam, configurar reenviadores condicionales en el DNS on-prem para reenviar svc.contoso.internal a las IP de reenvío de entrada de Cloud DNS de Contoso, proporcionadas por una política de entrada de Cloud DNS.
- Justificación: Las zonas de reenvío evitan duplicar la autoridad y permiten que cada parte mantenga su DNS donde está actualmente. Los servidores de entrada extienden la resolución privada de Cloud DNS a Fabrikam sin cambiar sus resolutores de forma generalizada.
Protegerse contra bucles de reenvío y aplicar límites de visibilidad
- Asegurarse de que los reenviadores condicionales de Fabrikam no reenvíen contoso.internal de vuelta a Contoso para nombres que Fabrikam todavía posee; de manera similar, Contoso solo debe reenviar fabrikam.internal.
- Vincular las zonas privadas de Contoso solo a las VPC que las requieran; no vincularlas globalmente para reducir el radio de impacto (blast radius).
- Justificación: Elimina los bucles de recursión de DNS y evita que las zonas privadas eclipsen los dominios públicos.
Migrar una zona compartida mediante transferencias de zonas administradas
- Para una zona compartida heredada legacy.shared.internal actualmente alojada en el servidor primario BIND de Fabrikam, configure Cloud DNS como secundario con TSIG y añada a la lista de permitidos (allow-list) el primario de Fabrikam para AXFR/IXFR. Mantenga a Fabrikam como primario durante el período de coexistencia.
- Justificación: El modo secundario proporciona sincronización en tiempo real sin cambiar los clientes. Permite una validación segura en Contoso mientras se mantiene una única fuente de verdad.
Introducir split-horizon para servicios expuestos externamente
- Crear una zona pública contoso.example con registros que apunten a la IP de un balanceador de carga HTTPS global para los clientes. Crear una zona privada con el mismo nombre vinculada a las VPC internas que asigne los mismos nombres a direcciones de ILB internas.
- Justificación: Los usuarios externos continúan llegando a los balanceadores de carga perimetrales; los servicios internos llegan a los ILB privados a través de RFC1918, optimizando la latencia y el costo mientras se mantienen nombres de host consistentes.
Proporcionar acceso privado a las API de Google sin salida a través de firewalls
- Para las VM de Contoso sin IP externas, habilite Private Service Connect para las API de Google y cree la zona DNS privada administrada para googleapis.com que se asigna a los endpoints de PSC.
- Justificación: Asegura que el acceso a BigQuery y Pub/Sub permanezca privado y local a la VPC, evitando dispositivos de salida de terceros y preservando la postura de seguridad.
Habilitar la observabilidad y el control
- Active el registro de consultas de Cloud DNS en la política de DNS de Contoso para las VPC involucradas y el registro de consultas autoritativas en las zonas públicas. Cree reglas de política de respuesta para bloquear dominios maliciosos conocidos en toda la organización.
- Justificación: La telemetría de consultas apoya la solución de problemas y la planificación de capacidad; las políticas de respuesta proporcionan un control central para la seguridad sin tocar cada resolutor.
Ejecutar la gestión de cambios con TTL seguros
- Reduzca los TTL a 60 segundos para los registros que se están migrando una semana antes de los cambios. Después de la validación y la transición (cutover) (por ejemplo, cambiar un servicio de on-prem a un ILB de GCP), aumente gradualmente los TTL a 300–600 segundos.
- Justificación: Los TTL cortos limitan el riesgo durante las transiciones; restaurar TTL más altos mejora la eficiencia de la caché después de la estabilización.
Probar, validar y fortalecer (harden)
- Desde VM canary en ambos lados, ejecute dig con +trace y verifique las rutas autoritativas, confirme que no haya picos de SERVFAIL/NXDOMAIN en los registros y simule fallos de enlace para observar el comportamiento del DNS con la redundancia de la VPN.
- Justificación: La validación proactiva detecta problemas de bucles/visibilidad de manera temprana; las simulaciones de fallos verifican que la resolución híbrida sobrevive a incidentes de transporte sin impacto para el usuario.