El DNS es el servicio del que nadie se acuerda hasta que falla, y en una arquitectura híbrida falla de una forma especialmente traicionera: la red está arriba, los túneles también, pero una aplicación en la nube no consigue resolver erp.empresa.local porque la respuesta del DNS de la oficina no sabe volver. Durante años, en Google Cloud, buena parte de esos sustos tenía el mismo origen: el rango 35.199.192.0/19.
Google ha publicado los Cloud DNS Outbound Endpoints, de momento en Preview, y la novedad interesa más a los equipos de redes y de seguridad que a los de DNS. Partimos de un análisis de Juan Gd en Medium que lo resume bien y lo hemos contrastado con la documentación oficial, que añade detalles y alguna precisión.
Cloud DNS permite crear zonas de reenvío (corp.ejemplo.com se pregunta a tal servidor) y políticas de servidor que mandan todas las consultas de una VPC a resolvers alternativos. Cuando el destino es privado, una IP de tu centro de datos o de otra nube alcanzable por VPN o interconexión, Cloud DNS envía la consulta desde un rango fijo: 35.199.192.0/19.
Ese rango tiene una particularidad: solo es accesible desde una VPC de Google Cloud o desde una red local conectada a ella. No es Internet, pero tampoco es tuyo. Y para que funcionase había que hacer tres cosas en el otro extremo:
Funcionaba, pero chocaba con la manera en que piensan las redes corporativas. Meter un prefijo público ajeno en las tablas de rutas internas, permitirlo en el cortafuegos y explicárselo al auditor genera reticencias razonables. Y había un problema más fino: todas las VPC consultaban desde el mismo rango. El resolver de la oficina no podía distinguir si la pregunta venía de producción, de preproducción o de la VPC de un proveedor, así que no había forma de aplicar reglas distintas a cada entorno.
Un Outbound Endpoint es un recurso regional que se crea dentro de una VPC y se asocia a una zona de reenvío o a una política de servidor. Para crearlo hacen falta, en cada región:
| Pieza | Para qué sirve |
|---|---|
| Una VPC y una región | El endpoint es regional; se crea uno por región donde haya cargas |
| Una subred normal y una IPv4 privada dentro de ella | Colocar el endpoint en la pila de red de la VPC |
Una subred proxy-only regional activa, de /26 como mínimo (--purpose=REGIONAL_MANAGED_PROXY, --role=ACTIVE) | El origen real de las consultas DNS que salen hacia los destinos |
El borrador del que partimos hablaba de una subred «reversed proxy-only»; el nombre correcto es subred proxy-only regional, la misma familia de subredes que usan los balanceadores de aplicación regionales, y de hecho puede compartirse con ellos dentro de la misma región.
Lo importante está en la tercera fila. La documentación lo dice sin ambigüedad: las consultas salen únicamente del rango de la subred proxy-only, no de la IP del endpoint. Quien configure el cortafuegos del resolver remoto mirando la IP del endpoint se encontrará con que no llega nada.
| Reenvío clásico | Con Outbound Endpoint | |
|---|---|---|
| Origen que ve el resolver remoto | 35.199.192.0/19, igual para todas las VPC | La subred proxy-only que tú defines |
| Ruta de vuelta | Anunciar un prefijo de Google en tu red | Un prefijo privado de tu propio plan de direccionamiento |
| Reglas por entorno | Imposible distinguir VPC por origen | Un rango distinto por VPC si se quiere |
| Destinos | Privados y públicos | Solo privados (RFC 1918, RFC 6598 o privados declarados) |
| Protocolo | IPv4 | IPv4 |
Esa fila de «reglas por entorno» es, para nosotros, la mejora de fondo. Google lo plantea así en su documentación: crear un endpoint y una zona en cada VPC, cada uno autorizado solo para la suya, permite que el resolver local vea un rango de origen distinto por VPC. Producción puede consultar la zona del ERP y desarrollo no, y eso se decide en el cortafuegos del centro de datos, con las mismas reglas con las que se gobierna el resto del tráfico. Es la idea de la microsegmentación aplicada al DNS.
La comparación con las otras dos grandes nubes es inevitable, porque ambas resolvieron esto hace años con un modelo más directo:
| Nube | Servicio | De dónde salen las consultas |
|---|---|---|
| AWS | Route 53 Resolver, outbound endpoint | De las IP privadas que eliges para el endpoint en las subredes de tu VPC |
| Azure | DNS Private Resolver, outbound endpoint | De una subred dedicada y delegada en exclusiva al resolver (de /28 a /24) |
| Google Cloud | Cloud DNS, Outbound Endpoint (Preview) | De la subred proxy-only regional, no de la IP del endpoint |
En AWS, lo que configuras es lo que ves: la IP del endpoint es la IP de origen. En Google hay una capa de indirección, el endpoint por un lado y el rango de salida por otro, que obliga a explicar bien el diseño a quien opera el otro extremo. Coincidimos con la conclusión del artículo de origen: no es tan limpio como el modelo de AWS o Azure, pero resuelve lo que importaba, que era sacar el DNS de un rango ajeno y meterlo en el direccionamiento privado propio.
Hay un detalle de diseño que facilita mucho la vida en organizaciones con decenas de proyectos. Un endpoint no tiene por qué estar en la VPC donde nace la consulta. Las zonas y políticas de una VPC spoke pueden usar un endpoint alojado en una VPC central, un hub de DNS, y Cloud DNS se encarga internamente de llevar la consulta hasta él. Según la documentación, no hace falta conectividad de red entre el hub y la VPC de origen: la que sí necesita alcanzar los destinos es la red del endpoint, por Cloud VPN, Cloud Interconnect o peering con otra VPC.
El resultado es un único punto de salida del DNS hacia la red corporativa, con un único rango que anunciar y que abrir, aunque detrás haya muchas VPC. Para usar un endpoint de otro proyecto hacen falta los permisos de enlace (dns.outboundEndpoints.bindPrivateDNSZone y bindPrivateDNSPolicy). En una VPC compartida, el endpoint y sus subredes se crean en el proyecto anfitrión; no se pueden crear desde un proyecto de servicio.
Si lo que se busca es que las spokes hereden toda la configuración DNS del hub (zonas privadas incluidas), el camino sigue siendo el DNS peering de Cloud DNS, que es independiente de esto.
Los endpoints son regionales, así que la redundancia hay que diseñarla. Google recomienda al menos dos regiones. Cloud DNS ordena los endpoints asociados a una zona por latencia y tasa de error, prueba primero el mejor y salta al siguiente si falla; cuando el caído se recupera, vuelve a preferirlo. Una VM en una región sin endpoint propio sigue resolviendo a través del mejor endpoint de su VPC.
Los límites que conviene tener presentes antes de diseñar:
BACKUP, promoverla y esperar a que se vacíe.Con la herramienta de línea de comandos, el flujo es crear la subred proxy-only, crear el endpoint y asociarlo. Los nombres y rangos son de ejemplo:
# 1. Subred proxy-only regional (mínimo /26): será el origen de las consultas
gcloud compute networks subnets create dns-egress-euw1 \
--network=hub-dns --region=europe-west1 \
--range=10.200.0.0/26 \
--purpose=REGIONAL_MANAGED_PROXY --role=ACTIVE
# 2. El endpoint, con una IP de una subred normal de la misma VPC
gcloud beta dns outbound-endpoints create dns-out-euw1 \
--network=hub-dns --subnetwork=hub-dns-euw1 \
--location=europe-west1 --endpoint-ip=10.10.0.53
# 3. Asociarlo a una zona de reenvío (o a una política con "dns policies update")
gcloud beta dns managed-zones update corp-ejemplo \
--outbound-endpoints=projects/PROYECTO/locations/europe-west1/outboundEndpoints/dns-out-euw1,projects/PROYECTO/locations/europe-southwest1/outboundEndpoints/dns-out-esw1Son comandos beta porque la función está en Preview, con las condiciones habituales de Google para lo que aún no es GA: sin compromiso de soporte completo y con posibilidad de cambios. Para crearlos hacen falta los roles roles/dns.admin y roles/compute.networkAdmin.
Aquí está la mitad del trabajo que no sale en los anuncios. El resolver al que se reenvía vive en tu centro de datos, en tu cloud privado o en otra nube, y allí hay que preparar dos cosas:
La guía de migración de Google propone un orden prudente, y lo suscribimos: crear subredes y endpoints, preparar rutas y cortafuegos, probar con una zona temporal y una VM, y solo entonces mover las zonas reales. La regla para 35.199.192.0/19 no se quita hasta el final, tras confirmar en los registros que ya no llega nada desde ese rango y que ningún otro servicio de Google depende de ella. Si algo falla, la vuelta atrás es apuntar la zona otra vez al mecanismo clásico.
Un aviso que no es evidente: en migraciones con mucho volumen, Google advierte de unos diez minutos de escalado del nuevo camino, y recomienda mover las zonas de una en una para no perder consultas.
Más allá de Google Cloud, el anuncio refuerza una idea que vemos a menudo en proyectos híbridos y multicloud: el DNS forma parte del plano de red, no es un servicio aparte. Cuando una empresa conecta su infraestructura privada con una o varias nubes públicas, la resolución de nombres cruza las mismas fronteras que el tráfico de aplicación, y debería gobernarse igual:
La mejora de Google no cambia la arquitectura de nadie de la noche a la mañana, pero quita una excepción incómoda. Y en redes, cada excepción que desaparece es una regla menos que explicar en la próxima auditoría.
¿Qué IP ve mi DNS local cuando recibe una consulta de Cloud DNS con un Outbound Endpoint? Una dirección de la subred proxy-only regional de la VPC donde está el endpoint. No la IP del endpoint, que solo sirve para colocarlo en la red.
¿Puedo seguir usando 35.199.192.0/19? Sí. El reenvío clásico sigue existiendo. Lo que no se puede es combinar ambos mecanismos en la misma zona de reenvío o política de servidor.
¿Necesito conectar por peering las VPC spoke con la VPC del endpoint? No. Según la documentación de Google, no hace falta conectividad entre el hub y la VPC de origen. La red del endpoint sí debe alcanzar los resolvers de destino.
¿Sirve para reenviar a un DNS público con una IP de salida fija? No. Los Outbound Endpoints solo admiten destinos privados. Las consultas a servidores públicos se resuelven por la infraestructura de Google, sin pasar por el endpoint.
¿Está listo para producción? Está en Preview. Para cargas críticas, lo razonable es probarlo en una zona no esencial, desplegarlo en dos regiones y mantener el camino clásico preparado como vuelta atrás.
¿Conectas tu infraestructura privada con una o varias nubes públicas y el DNS se ha convertido en una colección de excepciones? En Cloud Privado diseñamos entornos híbridos y multicloud sobre centros de datos en España y los conectamos con las nubes públicas que ya uses. Si quieres revisarlo con alguien que mire las dos orillas, hablemos.
WPL7 convierte un servidor Ubuntu en un hosting de WordPress con un contenedor por sitio, copias, correo firmado con DKIM, escáner de malware, gestión masiva de plugins y un servidor MCP para la IA. Es gratuito, AGPL y no depende de ninguna nube ajena, pero lleva un mes en beta. Lo hemos leído a fondo y lo comparamos con los demás paneles autoalojados.
ZFS es el mismo código en Linux y en FreeBSD, pero no llega igual al servidor. En FreeBSD forma parte del sistema base; en Linux es un módulo aparte que, por un choque de licencias, cada distribución integra a su manera. Contamos el origen del conflicto, cuánto tarda OpenZFS en soportar cada kernel nuevo (una mediana de 38 días) y qué hace cada plataforma para que la actualización no te deje sin sistema de ficheros.
Cuando una API o una web va lenta, la tentación es subir de plan: más vCPU, más RAM, discos más rápidos. Antes conviene saber qué está frenando de verdad al servidor. Repasamos las seis señales que lo delatan (CPU, memoria, disco, red, límites y latencia de la aplicación), con los comandos para medirlas, cómo leerlos sin engañarse y lo que hemos comprobado en Debian y Ubuntu.