DNS privado de Azure sobre VPN: punto de conexión del resolver o forwarder
Ambos diseños responden zonas privadas por el túnel. Compara un punto de conexión de entrada gestionado con una VM forwarder y luego revisa la ruta que debe existir en cualquier caso.
Un servidor local llega a una máquina virtual de Azure por dirección privada y aun así no puede resolver su nombre de host privado, lo que lleva a la gente a buscar un túnel roto. El túnel está bien. Lo que falta es un límite de DNS: nada en el lado local sabe que una zona privada concreta de Azure debe ser respondida por un resolver dentro de la VNet. Dos diseños cierran esa brecha, y difieren en lo que acabas operando, no en si las consultas funcionan.
El túnel transporta consultas, no conocimiento de zonas
Una conexión de sitio a sitio da a los paquetes una ruta entre las dos redes. No dice al servidor DNS local qué espacio de nombres pertenece a Azure ni qué dirección debe responder, así que la consulta o va a Internet y vuelve vacía o nunca sale del resolver local.
La solución tiene dos mitades fáciles de separar. Una mitad es un resolver dentro de la VNet que acepta consultas que llegan por el túnel. La otra es un forwarder condicional en el lado local que envía exactamente un espacio de nombres a ese resolver. Ninguna mitad funciona sola.
Supón que la zona es cloud.corp.example durante el resto de este recorrido, y trata cada dirección como ilustrativa.
Opción A: el punto de conexión de entrada gestionado
Azure DNS Private Resolver ofrece un punto de conexión de entrada que acepta consultas DNS desde fuera de la VNet. Lo despliegas en una subred delegada dedicada, vinculas la zona privada a esa VNet y anotas la dirección de entrada que asigna el servicio.
En el servidor DNS local creas entonces un forwarder condicional para el espacio de nombres exacto hacia esa dirección:
Namespace: cloud.corp.example
Forward to: 10.20.2.4El procedimiento de DNS híbrido de Microsoft documenta tanto el vínculo de la zona como el paso del forwarder. La ruta gestionada te deja sin software DNS que parchear, y la dirección del punto de conexión se mantiene estable durante toda la vida del recurso.
El precio es que ahora posees un recurso de resolver, su delegación de subred y su coste, que es real incluso cuando el volumen de consultas es mínimo.
Opción B: una VM forwarder dentro de la VNet
El diseño más antiguo ejecuta software DNS en una VM corriente dentro de la VNet: Windows DNS, BIND o dnsmasq, con la zona privada alojada localmente o reenviada al resolver de Azure en 168.63.129.16. El forwarder condicional local apunta a la dirección privada de esa VM.
Esta opción resulta familiar a los equipos que ya operan servidores DNS, y puede llevar lógica extra como registro o respuestas split-horizon. También hereda todos los deberes operativos de un servidor DNS: parchear, una segunda instancia para la disponibilidad, monitorización y una ruta de reconstrucción cuando la VM se sustituye y su dirección cambia.
Un host corriente de VNet no es un proxy DNS hasta que el servicio está instalado y se le permite responder a esos clientes, y ese es el paso que la gente se salta al clonar una VM.
Cuál encaja con tu operación
La comparación no va de qué diseño es más rápido. Va de si quieres operar software DNS o no, y de si el volumen de consultas justifica un recurso gestionado que factura por punto de conexión y por consulta.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
Sea cual sea la fila que lo decida, la regla del forwarder local es la misma. Esa es la parte que debe existir en ambos diseños, y es la que más a menudo falta cuando alguien informa de que la resolución funciona desde dentro de Azure pero no desde la oficina.
Comprueba la ruta por orden
Confirma que la zona está vinculada a la VNet que contiene el resolver y que el forwarder local nombra el espacio de nombres y no un dominio padre. Un forwarder para corp.example no coincidirá con cloud.corp.example a menos que el propio resolver delegue, y la discrepancia produce una respuesta negativa limpia que parece un registro ausente.
Después comprueba que la consulta llega al punto de conexión: el origen local necesita una ruta hacia la dirección del resolver y una ruta de vuelta, y tanto el puerto 53 UDP como el TCP deberían estar permitidos donde la política lo permita. Un NSG no puede aportar un registro de zona ausente, y una zona correcta no puede responder a una consulta que nunca llega.
Mantén el FQDN solicitado junto al resolver que elegiste cuando diagnostiques, y separa un tiempo de espera de una respuesta negativa. Un tiempo de espera es un problema de ruta o de política. Una respuesta negativa significa que la consulta llegó y el espacio de nombres no coincidía. Orden de trabajo: vincula la zona, añade el forwarder condicional, abre el puerto 53 en ambos sentidos, prueba un nombre desde local y solo entonces mira la autorización propia de la aplicación.