Resolución DNS en topología HUB and SPOKE

El otro día estuve trabajando en un problema donde un cliente tenía configurada una topología HUB and SPOKE autogestionada (no VWAN).
El problema que reportaba era que desde una máquina virtual (VM) en el spoke, no podía conectar a un private endpoint que daba acceso a una Base de Datos SQL.

Diagnóstico inicial

Al hacer desde la VM ubicada en el spoke una resolución DNS del nombre FQDN del private endpoint:

observamos que no existía resolución DNS (no había traslación del nombre FQDN a la IP del private endpoint).
Por lo tanto, la conexión resultaba imposible.

Verificación de la configuración

El siguiente paso fue comprobar si la VNET donde estaba la VM tenía linkada la private DNS zone:

• No la tenía, y por tanto no podía haber resolución DNS.
• Lo que sí tenía configurado esa VNET eran CUSTOM DNS servers ubicados en la subscripción del HUB.

El cliente quería que toda resolución DNS ocurriera en el HUB, porque allí es donde los custom DNS estaban ubicados.

La pregunta clave

En una configuración hub and spoke donde las zonas DNS privadas están enlazadas solo al hub, y no al spoke…

¿Cómo puede el spoke resolver las zonas DNS privadas del hub?

Este es un escenario muy común en topologías hub-and-spoke de Azure.

Comportamiento por defecto

Por defecto, las zonas DNS privadas en Azure solo se pueden resolver desde redes virtuales que estén enlazadas directamente a ellas.
Si solo enlazas tu VNet del hub a las zonas DNS privadas, los spokes no podrán resolver registros a menos que añadas configuración extra.

Opciones de configuración

Existen tres opciones principales para habilitar la resolución:

🔹 1. Usar un reenviador DNS en el Hub

• Implementa un proxy DNS (Azure Firewall, servidor DNS en VM Windows/Linux o un proxy DNS en el hub).
• Configúralo para reenviar consultas al resolvedor de Azure 168.63.129.16.
• Como el hub tiene linkadas las private DNS zones, la resolución funcionará correctamente.

En las VNets spoke, establece custom DNS apuntando al reenviador del hub.
El flujo sería:

Este es el enfoque más común en empresas, porque:

• Centraliza la resolución DNS.
• El hub proporciona DNS a todos los spokes.
• El reenviador puede ser:
  • Una VM ligera.
  • Un proxy DNS.
  • Azure Firewall con proxy DNS habilitado.

🔹 2. Enlaces directos selectivos

• Para spokes críticos (ejemplo: cargas sensibles con requisitos de latencia o alta disponibilidad), puedes enlazar la zona DNS privada directamente.
• Para el resto, confías en el DNS centralizado en el hub.

🔹 3. Mezcla híbrida

• Combinar centralización con algunos enlaces directos específicos según la criticidad de la carga.

Diagrama de referencia

Recursos adicionales

Lista completa de todas las private DNS zones disponibles:
👉 Documentación oficial de Azure