Cómo dividir zona DNS entre Windows DNS y BIND9 sin wildcards

Problema

En entornos donde el mismo dominio (por ejemplo, example.domain) se utiliza tanto para servicios internos como para recursos expuestos al exterior, los administradores suelen querer que los clientes internos resuelvan los nombres internos directamente, mientras que cualquier nombre que no exista en la zona interna se delegue a un servidor externo (BIND9 en DMZ). La dificultad aparece cuando el DNS de Windows, que es autoritativo para la zona, responde con NXDOMAIN a cualquier registro que no tenga, impidiendo que la consulta sea reenviada automáticamente al servidor externo. Mantener dos zonas idénticas o crear registros “pinpoint” para cada host externo genera una carga operativa innecesaria y propensa a errores.

Causa

1. Autoridad total del servidor Windows
   Cuando una zona está configurada como Primary en Windows Server, el servidor asume que es la única fuente de verdad. Cualquier nombre que no exista en esa zona termina en NXDOMAIN, sin intentar buscarlo en otro servidor.

2. Falta de delegación granular
   La zona completa no se puede dividir en sub‑zonas sin crear zonas secundarias o delegaciones explícitas. Sin sub‑zonas, no hay punto de anclaje para que el servidor Windows “paso a paso” consulte a BIND9.

3. Políticas DNS no activadas
   En versiones recientes de Windows Server es posible aplicar DNS Policies que filtran consultas por cliente, red o tipo de registro, pero si no se configuran, el comportamiento por defecto sigue siendo autoritario.

4. Configuración de forwarder global
   Un forwarder global se usa sólo cuando el servidor no es autoritativo para la zona consultada. En un escenario de zona compartida, el forwarder nunca se dispara.

Solución

1. Convertir la zona interna en zona secundaria y crear una zona primaria en BIND9

• BIND9 mantiene la zona completa (internos + externos).
• Windows Server actúa como Secondary y sólo sirve los registros que tiene en su copia.
• Cuando la copia secundaria no contiene un registro (porque BIND9 no lo ha replicado), el servidor responde con REFUSED; la consulta puede ser reenviada a un forwarder condicional.

Ventajas:

• No hay duplicación manual.
• La autoridad sigue estando en BIND9, lo que simplifica la gestión de cambios.

Pasos resumidos

1. En BIND9, declara la zona como master.
2. En Windows DNS, crea una zona Secondary apuntando al IP de BIND9.
3. Configura un Conditional Forwarder en Windows para la zona example.domain que apunte a BIND9 (solo se usará si la zona secundaria no responde).

2. Usar Forwarder condicional + DNS Policy en Windows

Esta alternativa mantiene la zona primaria en Windows (para los registros internos) y delega todo lo que no conoce a BIND9 sin crear una zona secundaria.

1. Crear forwarder condicional para la zona completa:

   Add-DnsServerConditionalForwarderZone -Name "example.domain" -MasterServers 10.0.2.53
   

2. Definir una política DNS que aplique el forwarder solo cuando la respuesta sea NXDOMAIN:

   Add-DnsServerQueryResolutionPolicy -Name "Forward-Unknown" `
       -Action Forward -ForwarderIPAddress 10.0.2.53 `
       -ApplyOnQueryResponse NXDomain -ZoneScope "example.domain"
   

3. Mantener la zona primaria con los registros internos habituales.

Con esta combinación, Windows responde primero con sus propios registros. Si la consulta termina en NXDOMAIN, la política la redirige al forwarder, que consulta a BIND9 y devuelve la respuesta al cliente.

3. Delegar sub‑zonas específicas a BIND9

Si sólo un subconjunto de nombres (por ejemplo, *.public.example.domain) está en DMZ, crea una sub‑zona public.example.domain en Windows como Stub Zone que apunta a BIND9. Los clientes internos siguen resolviendo host1.example.domain localmente y cualquier nombre bajo public.example.domain se delega automáticamente.

Configuración rápida

Add-DnsServerStubZone -Name "public.example.domain" -MasterServers 10.0.2.53

Cuándo aplicar esta solución

No apliques estas configuraciones si:

• Tu infraestructura DNS es exclusivamente Windows y no tienes BIND9 disponible.
• Necesitas soporte para registros dinámicos (DDNS) en la zona externa; la zona secundaria no permite actualizaciones dinámicas desde Windows.

Código

# 1. Crear forwarder condicional para la zona completa
Add-DnsServerConditionalForwarderZone -Name "example.domain" -MasterServers 10.0.2.53

# 2. Política que reenvía solo respuestas NXDOMAIN
Add-DnsServerQueryResolutionPolicy -Name "Forward-Unknown" `
    -Action Forward -ForwarderIPAddress 10.0.2.53 `
    -ApplyOnQueryResponse NXDomain -ZoneScope "example.domain"

# 3. (Opcional) Crear zona secundaria si prefieres replicar toda la zona
Add-DnsServerSecondaryZone -Name "example.domain" -MasterServers 10.0.2.53

# 4. (Opcional) Stub zone para sub‑zona pública
Add-DnsServerStubZone -Name "public.example.domain" -MasterServers 10.0.2.53

Verificación

1. Consulta interna conocida

   nslookup host-internal.example.domain <IP_Windows_DNS>
   

   Debe devolver la IP interna sin pasar por BIND9 (puedes observar el tráfico con Wireshark o con Get-DnsServerCache).

2. Consulta externa no presente en Windows

   nslookup host-public.example.domain <IP_Windows_DNS>
   

   La respuesta debe provenir de BIND9 (verifica la dirección IP del servidor que respondió en la traza).

3. Forzar NXDOMAIN

   nslookup inexistente.example.domain <IP_Windows_DNS>
   

   La política debe redirigir la consulta; si el forwarder está bien configurado, la respuesta será REFUSED o la IP del registro externo, no NXDOMAIN.

4. Revisar logs
   En Windows, habilita el registro de eventos de DNS (Microsoft-Windows-DNS-Server/Analytic) y busca entradas con QueryResolutionPolicy para confirmar que la política se disparó.

Notas adicionales

• Orden de resolución: Windows evalúa primero sus propias zonas, luego las políticas y por último los forwarders globales. Asegúrate de que la política tenga prioridad sobre cualquier forwarder global que ya exista.
• TTL coherente: Cuando usas zona secundaria, los TTL de los registros se sincronizan automáticamente con BIND9, evitando inconsistencias de caché.
• Seguridad: Limita la lista de MasterServers a IPs internas de la DMZ. Un forwarder abierto a Internet puede ser vector de amplificación DNS.
• Monitoreo: Añade una alerta en tu sistema de monitoring (Zabbix, Prometheus, etc.) que dispare si el número de respuestas NXDOMAIN de la zona supera un umbral; podría indicar que la zona secundaria dejó de replicarse.
• Compatibilidad: Las DNS Policies están disponibles a partir de Windows Server 2016. Si tu entorno usa versiones anteriores, la única opción viable es la zona secundaria + forwarder condicional.