Cómo configurar Conditional Forwarders y Azure DNS Private Resolver en entornos híbridos

Problema

En entornos híbridos donde los controladores de dominio (DC) están tanto on‑premises como en Azure, los servidores Windows suelen apuntar al DC de Azure para resolver nombres internos. Cuando se habilitan Private Endpoints (por ejemplo, para Azure Files) se crea una zona DNS privada como privatelink.file.core.windows.net. Si la resolución de esa zona no llega al Azure DNS Private Resolver, los clientes no pueden autenticar ni montar recursos compartidos. El síntoma típico es un error de autenticación al intentar mapear un drive o una falla de resolución de *.privatelink.* desde máquinas en Azure o desde la red on‑prem.

El patrón que se repite es: un cliente consulta su DNS local, la consulta se queda en un DC que no sabe cómo dirigir el nombre privado, y la respuesta nunca llega al resolver privado. La solución pasa por diseñar la cadena de forwarders de forma que la zona privada sea siempre enviada al resolver de Azure, sin crear bucles ni dependencias circulares.

Causa

1. Forwarder condicional inexistente o mal apuntado

   • El DC on‑prem no tiene un forwarder para privatelink.file.core.windows.net (o para el dominio público file.core.windows.net).
   • Cuando existe, suele apuntar a un DC en Azure que también tiene un forwarder para la misma zona, creando un bucle de resolución.

2. Replicación de forwarders en AD

   • Replicar la configuración de forwarder a todos los DC (incluidos los de Azure) hace que cada uno intente resolver la zona de forma local, impidiendo que la petición alcance el Private Resolver.

3. Uso del DNS público (168.63.129.16) en los DC de Azure

   • Si el DC de Azure delega la zona a su propio DNS público, la cadena de CNAME que lleva a privatelink.* se resuelve públicamente, devolviendo la IP pública en lugar de la privada.

4. Falta de zona privada vinculada al VNet

   • La zona privatelink.file.core.windows.net no está enlazada al VNet donde reside el Private Resolver, por lo que el resolver nunca la “ve”.

5. Configuración de red mixta

   • Clientes en Azure que usan el DC on‑prem como DNS primario nunca llegan al resolver privado porque la ruta de forwarder está rota.

Solución

1. Diseñar la topología de forwarders

Pasos concretos

1. Crear el Private Resolver (si no existe).

   • Inbound endpoint en la subred del VNet donde están los recursos con Private Endpoint.
   • Anotar la IP interna del endpoint (ej. 192.168.10.4).

2. Vincular la zona privada

   • En Azure DNS, crear la zona privatelink.file.core.windows.net.
   • Asociar la zona al VNet que contiene el Private Resolver.

3. Configurar forwarder condicional en el DC on‑prem

   • No replicar la zona; la configuración queda solo en los DC on‑prem que sirven a la red corporativa.
   • Apuntar la zona a la IP del inbound endpoint.

4. Asegurar que los DC en Azure no tengan forwarder para la zona

   • Si usan DNS de Windows, elimine cualquier forwarder condicional para privatelink.*.
   • Opcional: configure esos DC para usar 168.63.129.16 como DNS externo, de modo que cualquier consulta que no sea interna se resuelva públicamente.

5. Validar la cadena de resolución

   • Desde una VM en Azure, ejecutar nslookup <storageaccount>.file.core.windows.net.
   • La respuesta debe ser una IP privada (por ejemplo, 10.0.5.4) proveniente de la zona privada.

2. Alternativa ligera: zona on‑prem con registros A

Si la complejidad de forwarders no es viable, se puede crear una zona local privatelink.file.core.windows.net en el DC on‑prem y añadir registros A que apunten a la IP privada del Private Endpoint. Esta solución evita forwarders pero requiere mantenimiento manual cada vez que cambie la IP del endpoint.

3. Uso de PowerShell / dnscmd para automatizar

# En el DC on‑prem (PowerShell)
Add-DnsServerConditionalForwarderZone -Name "privatelink.file.core.windows.net" -MasterServers 192.168.10.4 -PassThru

# Verificar
Get-DnsServerConditionalForwarderZone -Name "privatelink.file.core.windows.net"

Para eliminar un forwarder replicado accidentalmente en los DC de Azure:

# En el DC de Azure
Remove-DnsServerConditionalForwarderZone -Name "privatelink.file.core.windows.net" -Force

Cuándo aplicar esta solución

• Entorno híbrido con DCs en ambas nubes y al menos un Private Endpoint que requiera resolución interna.
• Fallos de autenticación a Azure Files, Azure SQL o cualquier recurso con Private Link donde la resolución devuelve la IP pública o falla.
• Se desea mantener una única fuente de verdad (el Private Resolver) para todas las zonas privadas, evitando duplicación de registros.

No aplicar si:

• Solo se usan recursos públicos y no hay Private Endpoints.
• La infraestructura DNS está completamente externalizada (por ejemplo, usando solo Azure DNS público y no hay DC locales).

Verificación

1. Desde una máquina on‑prem, ejecutar:

   nslookup myshare.file.core.windows.net
   

   La respuesta debe ser la IP privada del Private Endpoint.

2. Desde una VM en Azure que usa el DC on‑prem como DNS primario, repetir el mismo nslookup.
   La ruta de resolución debe pasar por el DC on‑prem → Private Resolver → zona privada.

3. Probar el acceso al recurso:

   net use Z: \\myshare.file.core.windows.net\share /user:domain\user
   

   Si el mapeo funciona sin solicitar credenciales adicionales, la configuración está correcta.

4. Revisar los logs del Private Resolver (Azure Monitor) para confirmar que la consulta llegó y se resolvió.

Notas adicionales

• Orden de los forwarders: el Private Resolver tiene prioridad sobre el DNS público solo cuando la zona está vinculada al VNet. Mantener la zona privada fuera de la configuración de DNS público evita colisiones.
• TTL bajo: al crear registros A en una zona on‑prem, configure un TTL corto (300 s) para que cambios de IP del Private Endpoint se propaguen rápidamente.
• Seguridad: limite el acceso al inbound endpoint a subredes específicas mediante NSG; no exponerlo a Internet.
• Monitoreo: habilite diagnósticos de Azure DNS Private Resolver para detectar consultas fallidas y latencias inusuales.
• Documentación interna: registre la IP del inbound endpoint y la zona asociada en la wiki de infraestructura; la IP puede cambiar al recrear el endpoint.