Un nombre, dos respuestas
La IP escrita en la configuración
La API llega a Cuentasver en el mapa por la línea dedicada, y en su configuración pone 10.0.12.20. Un sábado, el CPD cambia Cuentas de máquina, la IP cambia, y el lunes Ana vuelve a ver «saldo no disponible» hasta que alguien encuentra ese número en un fichero y lo cambia.
Por eso las aplicaciones llaman por nombre: cuentas.cpd.bcps.example, y que el DNS diga cuál es la IP hoy. El problema es que el CPD tiene su DNS, la nube tiene el suyo, y cada uno solo conoce sus propios nombres. En el otro sentido pasa lo mismo: Tarjetasver en el mapa, en el CPD, necesita avisar a Notificaciones, que vive en la nube.
Y aparece un tercer nombre, uno que no es de nadie del banco: el del almacenamiento del proveedor, donde la API guarda los extractos de los clientes.
Llamar por nombre
La red es la del episodio 3, con la línea dedicada. Cada lado tiene ahora su DNS: el de la nube, dentro de la VPC, y el del CPD. A la izquierda, cada uno va por su cuenta. A la derecha, los dos se reenvían las preguntas: lo del CPD, al DNS del CPD, y lo de la nube, al de la nube. Arriba, en internet, el DNS público que usa el móvil de Ana y el almacenamiento de extractos del proveedor.
Traza el saldo de Ana, que ahora usa nombres, y mira en la ficha quién contesta cada pregunta y con qué IP. Luego resuelve el mismo nombre desde dentro, llama a la nube desde el CPD y guarda un extracto: primero sin endpoint, luego con endpoint y, por último, con endpoint y su nombre.
Qué ha pasado
El camino existe; el nombre, no
A la izquierda, el saldo de Ana vuelve a fallar, y esta vez el motivo es nuevo: el nombre no resuelve.probar en el laboratorio La API pregunta al DNS de la nube por cuentas.cpd.bcps.example, y el DNS de la nube busca en lo que conoce: sus zonas privadas y, si no, internet. En ningún sitio está ese nombre, así que responde NXDOMAIN, «no existe». La línea funciona y Cuentas también; lo que falta es saber a qué IP ir.
Reenvío condicional
A la derecha, el DNS de la nube tiene una regla: «lo que acabe en cpd.bcps.example, pregúntaselo al DNS del CPD». Es el reenvío condicional. La pregunta viaja por la línea como cualquier otro paquete, el DNS del CPD contesta 10.0.12.20 y la API sigue como en el episodio 3. En la ficha verás la fila «reenvía a».
En el otro sentido pasa lo mismo.probar en el laboratorio Tarjetas quiere avisar a notificaciones.nube.bcps.example, que está en una zona privada de la nube: solo existe para la VPC. A la izquierda, el DNS del CPD no la conoce y la busca en internet, sin éxito. A la derecha, reenvía lo de nube.bcps.example al DNS de la nube, que escucha en una IP privada de la VPC para recibir preguntas de fuera. Hacen falta las dos reglas, una en cada lado.
Un nombre, dos respuestas: split-horizon
Mira el primer tramo del saldo: el móvil de Ana pregunta por api.bcps.example al DNS público y recibe 192.0.2.20, la IP pública del balanceador. Ahora resuelve el mismo nombre desde dentro de la VPC.probar en el laboratorio La respuesta es 10.64.0.10, la privada. La VPC tiene asociada una zona privada con el mismo dominio, bcps.example, y desde dentro manda sobre la pública. Es el split-horizon: el mismo nombre resuelve a una IP u otra según quién pregunte, y el tráfico de dentro no sale a internet para volver a entrar.
Tiene su trampa: cuando existe la zona privada, desde dentro solo vale lo que haya en ella. Si la pública tiene www.bcps.example y la privada no, desde la VPC ese nombre no existe. Por eso el DNS de la izquierda contesta NXDOMAIN para Cuentas en vez de seguir buscando: la zona privada bcps.example dice que no lo conoce.
Endpoints privados
La API guarda cada extracto en el almacenamiento del proveedor. Es un servicio gestionado con IP pública, así que la API llega a él como a cualquier web: por el NAT, a internet y de vuelta.probar en el laboratorio Funciona, y cuesta 0,18 €/GB, porque el NAT cobra por cada GB y la salida a internet también.
Un endpoint privado pone el servicio dentro de la VPC: una IP privada de la subred (10.64.0.140) que lleva al almacenamiento por la red del proveedor, sin salir a internet. Pero crearlo no basta.
Cuándo hace daño: el endpoint que nadie usa
Crea el endpoint y vuelve a guardar el extracto.probar en el laboratorio Todo funciona igual… y ese es el problema. El nombre extractos.almacen.example sigue resolviendo a la IP pública, así que el tráfico sigue saliendo por el NAT. Nadie se entera, porque no hay ningún error: el extracto se guarda. Solo el marcador lo enseña: el coste no baja.
Marca «En la zona privada».probar en el laboratorio Una zona privada hace que ese nombre, desde la VPC, resuelva a la IP del endpoint. Ahora sí: 0,01 €/GB, sin NAT ni internet. Un endpoint privado son dos piezas, el endpoint y su nombre, y la segunda es la que se olvida.
Cuándo hace daño: el DNS en el camino
Tira el DNS del CPD y traza el saldo.probar en el laboratorio A la derecha, el DNS de la nube reenvía la pregunta y nadie contesta: SERVFAIL. La línea funciona, Cuentas funciona, la ruta está, y Ana ve «saldo no disponible». Llamar por nombre ha puesto una pieza más en el camino de cada llamada, y el DNS del CPD es ahora un punto único de fallo para la nube. Se resuelve como cualquier otro: dos servidores DNS en el CPD (y dos direcciones en la regla de reenvío), y cachés que aguanten las respuestas un rato.
Criterio
| Necesidad | Pieza | Cuidado con |
|---|---|---|
| La nube resuelve nombres del CPD | Reenvío condicional nube → CPD | El DNS del CPD pasa a estar en el camino: que sea redundante |
| El CPD resuelve nombres de la nube | DNS de la nube escuchando en una IP privada, y reenvío CPD → nube | Hace falta la regla en los dos lados |
| Un nombre público que desde dentro debe ir por dentro | Zona privada con el mismo dominio (split-horizon) | Desde dentro solo existe lo que esté en la zona privada |
| Hablar con un servicio gestionado sin pasar por internet | Endpoint privado y su registro en una zona privada | Sin el registro, el endpoint no se usa y nadie lo nota |
-
¿El nombre vive en una sola red y solo lo usa esa red?Nombres internos de la VPC.zona privada de esa red, y ya
-
¿Lo tiene que resolver la otra red (la nube, el CPD)?reenvío condicional hacia el DNS que lo conoce, redundante
-
¿Es un nombre público que desde dentro debería dar otra IP?El balanceador, un endpoint privado.split-horizon: zona privada con el mismo nombre
- DNS público, sin más.
Llamar por IP no siempre es un error: entre dos piezas que no cambian nunca y en el camino más crítico, quitar el DNS quita un punto de fallo. Pero es la excepción, y hay que apuntarla en algún sitio.
En el mundo real
Las tres nubes resuelven el DNS híbrido con las mismas piezas: zonas privadas asociadas a redes, puntos de entrada (inbound) con una IP privada para que el CPD pregunte, y puntos de salida (outbound) con reglas de reenvío por dominio. En AWS son Route 53 Resolver y sus endpoints; en Azure, DNS Private Resolver; en Google Cloud, las zonas de reenvío y las políticas de servidor de Cloud DNS.
El endpoint olvidado es uno de los sustos de factura más conocidos. El caso típico es el almacenamiento de objetos: en AWS, S3 tiene un gateway endpoint gratuito que se instala con una ruta, y los equipos que no lo ponen pagan el NAT por cada GB que suben o bajan. En Azure, los private endpoints necesitan su zona privada (privatelink.blob.core.windows.net y compañía), y olvidarla o no enlazarla a la red es un clásico de los foros: el endpoint existe y el tráfico sigue saliendo por la IP pública.
Y el DNS en el camino crítico también tiene historia. En 2016, un ataque contra el proveedor de DNS Dyn dejó sin resolver durante horas a Twitter, GitHub y Netflix, que funcionaban perfectamente. En octubre de 2025, una caída larga de AWS en su región más grande empezó por un registro DNS vacío: el del endpoint de DynamoDB. Los servidores estaban bien; nadie sabía a qué IP llamarlos.
Equivalencias
| En la serie | AWS | Azure | Google Cloud |
|---|---|---|---|
| DNS de la nube | Route 53 Resolver | Azure DNS (168.63.129.16) / DNS Private Resolver | Cloud DNS (resolución de la VPC) |
| Zona privada | Private hosted zone | Private DNS zone | Private zone |
| Reenvío nube → CPD | Outbound endpoint + forwarding rule | Outbound endpoint + forwarding ruleset | Forwarding zone |
| El CPD pregunta a la nube | Inbound endpoint | Inbound endpoint | Inbound server policy |
| Endpoint privado | Interface endpoint (PrivateLink) / gateway endpoint | Private Endpoint (Private Link) | Private Service Connect |
Siguiente episodio
Tras la API llegan más equipos: Notificaciones, Reporting, Transferencias… cada uno con su VPC para desarrollo, preproducción y producción. Todos quieren hablar entre sí y con el CPD. Unir redes de dos en dos parece lo más sencillo, hasta que son nueve.
Episodio 5 Muchos equipos, una red Peering frente a hub-and-spoke, segmentación e inspección central.