Servir DoH/DoT en Windows Server DNS: estado, alternativas y guía práctica

¿Quieres cifrar consultas DNS en tu infraestructura Windows sin romper Active Directory ni migrar tu rol de DNS? En este artículo encontrarás el estado real de soporte DoH/DoT en Windows Server, alternativas que funcionan hoy, arquitecturas de referencia y guías paso a paso para desplegar un proxy seguro delante de tu servidor DNS de Windows.

Índice

Resumen de la pregunta

¿El rol DNS Server de Windows Server puede servir consultas usando DoH o DoT (lado servidor)? ¿Si no, está en el roadmap y cómo solicitarlo?

Respuesta y solución

Estado actual: El rol DNS Server de Windows Server no ofrece hoy la capacidad de servir DNS sobre HTTPS (DoH) ni DNS sobre TLS (DoT). Esto aplica también a Windows Server 2022 y a las vistas previas públicas conocidas de Windows Server 2025.
Roadmap / solicitud: Para que se priorice esta característica, envía feedback mediante los canales oficiales (Feedback Hub, Programa Windows Insider y el portal de comentarios de Windows Server). El volumen/claridad de los casos de uso reportados suele influir en la priorización.

Contexto técnico imprescindible

El rol DNS de Windows Server es el pilar de muchas implementaciones de Active Directory (AD DS). Resuelve nombres internos, aloja zonas integradas en AD y, en muchos entornos, actúa además como recursor para dominios públicos. DoH y DoT no cambian el protocolo DNS “clásico” (RFC 1035); lo encapsulan en un canal TLS autenticado:

DoT escucha en TCP 853 y crea un túnel TLS estable para transportar mensajes DNS binarios.
DoH usa HTTPS (típicamente TCP 443) y representa el mensaje DNS como binario (application/dns-message) sobre HTTP/2 o HTTP/3.

Para “hablar” DoH/DoT, un servidor debe terminar TLS, gestionar certificados, exponer endpoints y, tras descifrar, reenviar/servir la consulta a su motor DNS. El rol DNS de Windows, a día de hoy, no incluye esa capa TLS a modo de servicio integrado.

Alternativas prácticas hoy

Si necesitas DoH/DoT del lado servidor en entornos Windows, estas rutas funcionan en producción sin alterar tu DNS de Windows:

Proxy o resolvedor delante del DNS de Windows

Ejecuta un servicio que escuche en 443 (DoH) y/o 853 (DoT), y reemita las consultas en DNS “clásico” (UDP/TCP 53) a tu servidor DNS de Windows.
Opciones habituales que funcionan en Windows, contenedores o VM:
- Technitium DNS Server
- AdGuard Home
- dnsdist (PowerDNS)
Ventajas: habilitas cifrado sin tocar tu infraestructura AD/DNS actual.
Consideraciones: certificados TLS (ACME/Let’s Encrypt o PKI corporativa), apertura de puertos 443/853, control de acceso (ACL/rate‑limit) y monitoreo.

Resolver paralelo con split‑horizon

Mantén Windows DNS como autoridad para zonas internas (integradas o no en AD).
Usa el proxy DoH/DoT como recursor:
- Reenvía a Windows DNS para dominios internos.
- Resuelve o reenvía a upstreams externos para dominios públicos, según tu política.
Útil si clientes internos exigen cifrado sin ceder control de las zonas.

Clientes Windows con DoH

Si el objetivo es solo cifrar el tramo cliente → resolutor, habilita DoH en clientes Windows (Windows 11/10 compatibles) apuntando a:
- Un resolutor DoH interno (tu propio proxy).
- Un resolutor DoH externo (si la política lo permite).

Arquitecturas de referencia

Patrón	Flujo	Cuándo usar	Puertos
Proxy frontal	Cliente → DoH/DoT → Proxy → DNS Windows (53)	Quiero cifrado ya, sin cambiar DNS Windows	443/853 externos, 53 internos
Split‑horizon	Cliente → DoH/DoT → Resolver → (interno: Windows / externo: upstream)	Políticas diferentes para interno/externo	443/853 y 53
Solo clientes	Cliente (DoH) → Resolver externo	Solo cifrado de salida, tolero dependencia externa	443

Guías paso a paso

Opción A: Technitium DNS Server como proxy DoH/DoT

Qué es: Servidor DNS completo con soporte de DoH/DoT, UI web, listas de bloqueo y reenvíos por dominio. Funciona bien como proxy delante de Windows DNS.

Prerequisitos: Windows Server/Windows 11, puertos 443/853 libres, .NET instalado (si aplica), certificados TLS (o capacidad ACME), IP del DNS de Windows (p. ej., 10.0.0.10:53).

Instalación: Descarga el instalador, ejecútalo como servicio. Verifica el panel web local.
Listeners: En la configuración de DNS, habilita:
- DoT: escucha en 0.0.0.0:853.
- DoH: escucha en 0.0.0.0:443, ruta /dns-query.
- Limita orígenes (ACL) a tus rangos internos.
Certificados: Carga tu certificado/clave (PEM/PFX). Si usas ACME, configura la obtención/renovación automática (HTTP‑01 o DNS‑01).
Reenvío a Windows DNS: En Forwarders define:
- Regla por dominio para corp.local → 10.0.0.10 (tu servidor Windows).
- Upstreams externos para dominios públicos (si quieres recursión completa), o usa solo Windows DNS como forwarder central.
Firewall de Windows: netsh advfirewall firewall add rule name="DNS DoH In" dir=in action=allow protocol=TCP localport=443 netsh advfirewall firewall add rule name="DNS DoT In" dir=in action=allow protocol=TCP localport=853
Validación: Comprueba que el endpoint DoH responde (consulta desde un cliente con DoH) y que las resoluciones internas salen del Windows DNS (logs de Technitium).

Opción B: AdGuard Home como proxy DoH/DoT

Qué es: Servidor DNS enfocado a privacidad y filtrado, con soporte DoH/DoT, buen panel web y configuración simple. Se integra muy bien como stub hacia Windows DNS.

Instalación rápida en Windows como servicio:

AdGuardHome.exe -s install
AdGuardHome.exe -s start

Configuración básica en AdGuardHome.yaml:

dns:
  bind_hosts:
    - 0.0.0.0
  port: 53
  upstream_dns:
    # Reenviar todo a tu DNS de Windows
    - 'tcp://10.0.0.10:53'
    - 'udp://10.0.0.10:53'
  # Reglas por dominio (split-horizon)
  # - '[/corp.local/]10.0.0.10:53'

tls:
enabled: true
server\_name: 'dns.int.ejemplo'

Rutas a los ficheros del certificado

certificate\_chain: 'C:\certs\fullchain.pem'
private\_key: 'C:\certs\privkey.pem'
port\_https: 443
port\dns\over\_tls: 853

Admin web opcional

http:
address: 0.0.0.0:80

Recomendaciones: activa rate limiting, aplica listas de acceso por red, y usa certificados con renovación automática (por ejemplo, con un programador que llame a tu cliente ACME).

Opción C: dnsdist (PowerDNS) como frontend DoH/DoT

Qué es: Un equilibrador/proxy DNS de altas prestaciones. Excelente si prevés alto tráfico o múltiples backends. Puede ejecutarse en Windows a través de contenedor/VM o nativo según distribución disponible.

Ejemplo de configuración mínima (adaptar rutas en Windows):

-- Escucha DoH y DoT, y reenvía a Windows DNS en 10.0.0.10:53
newServer({address="10.0.0.10:53", name="win-dns"})
setACL({"10.0.0.0/8", "192.168.0.0/16"})

\-- DoH en 443
addDOHLocal("0.0.0.0:443", "/dns-query", "C:\certs\fullchain.pem", "C:\certs\privkey.pem")

\-- DoT en 853
addTLSLocal("0.0.0.0:853", "C:\certs\fullchain.pem", "C:\certs\privkey.pem")

\-- Métricas y política por defecto
addAction(AllRule(), PoolAction("default"))

Consejos: activa reuseport si está disponible, define límites de concurrencia, y utiliza health checks hacia el backend de Windows para retirar nodos cuando no respondan.

Cómo habilitar DoH en clientes Windows

Si tu meta es proteger el tramo cliente → resolutor, configura DoH en los equipos. Para un resolutor DoH interno en dns.int.ejemplo (IP 10.0.0.20):

netsh dns add encryption server=10.0.0.20 dohtemplate=https://dns.int.ejemplo/dns-query autoupgrade=yes udpfallback=no
netsh dns show encryption

Distribuye el servidor DNS por DHCP (opción 6) o por Directivas de Grupo. En entornos Windows 11/10 modernos, existe una directiva administrativa para forzar el uso de DoH cuando esté disponible; acompáñala de la tabla de mapeo IP → plantilla DoH (como en el ejemplo anterior).

Seguridad y cumplimiento

Certificados: usa nombres internos válidos (SAN), automatiza la renovación (60–90 días si empleas ACME), y protege la clave privada.
Protocolos: prioriza HTTP/2/3 en DoH (soporte del servidor) y TLS 1.2+ con suites modernas. Deshabilita renegociación insegura.
Exposición: limita el acceso por red (ACL), aplica rate‑limit por IP/ASN y considera WAF/LB delante del proxy si es público.
Privacidad: revisa el registro de consultas (retención mínima necesaria). En sectores regulados, anonimiza IPs o agrega por subred.
DNSSEC/EDNS: el proxy no sustituye la validación: si necesitas validación, habilítala en el recursor o en tu upstream.

Operación, monitoreo y observabilidad

Métricas clave: latencia P50/P95, tasa de aciertos (cache hit), errores TLS, QPS por origen, límites alcanzados, CPU y sockets en uso.
Logs útiles: conexiones TLS establecidas/fallidas, tamaño de respuesta, dominio consultado (anonimizado si aplica), upstream elegido.
Alarmas: picos de 4xx/5xx en DoH, timeouts hacia Windows DNS, incremento brusco de NXDOMAIN o SERVFAIL.

Pruebas y validación

Conectividad TLS: desde un host de pruebas, verifica que 443 y 853 aceptan TLS y presentan el certificado esperado.
Resolución interna: consulta un nombre de tu zona AD (p. ej., dc01.corp.local). Debe resolver a través del proxy, con upstream Windows DNS.
Resolución externa: prueba un dominio público y confirma tiempos y respuestas esperadas.
Failover: detén temporalmente el servicio DNS de Windows y confirma que el proxy reporta fallo del backend (y recupera al volver).

Preguntas frecuentes

¿Puedo publicar DoH/DoT a Internet? Sí, pero exige controles adicionales: listas de acceso, límites de tasa, detección de abuso y aislamiento de recursos para evitar que terceros consuman tu capacidad.

¿Cómo afecta a herramientas de red? Inspecciones intermedias que dependían de DNS en claro ya no verán el tráfico; planifica nuevas fuentes de observabilidad (logs del proxy, muestreos del backend).

¿Qué pasa con DNSSEC? DoH/DoT cifran el transporte; DNSSEC valida origen e integridad de los datos. Son complementarios; habilita ambos si tu política lo requiere.

¿Y con EDNS Client Subnet (ECS)? Si lo usas para geolocalización de CDN, revisa que tus upstreams lo admitan y que tu política de privacidad lo permita.

Checklist de despliegue

Definir arquitectura (proxy frontal vs. split‑horizon vs. solo clientes).
Asignar nombres y certificados (SAN correctos y renovación automatizada).
Desplegar proxy DoH/DoT y probar localmente.
Configurar reenvíos a Windows DNS e introducir reglas por dominio si aplica.
Endurecer firewall, ACL y límites.
Configurar clientes (DHCP/GPO) y habilitar DoH cuando corresponda.
Establecer métricas, logs y alertas.
Plan de reversión y documentación de operación.

Pros y contras

Aspecto	Pros	Contras
Cifrado de transporte	Privacidad, cumplimiento y resistencia a interferencias	Gestión de TLS (certificados, renovaciones, caducidad)
Compatibilidad	No tocas tu rol DNS de Windows ni AD	Dos capas a operar: proxy y backend
Rendimiento	HTTP/2/3 multiplexado, caché en proxy	Ligero aumento de latencia por handshake y cifrado
Seguridad	Autenticidad del servidor, control de acceso	Superficie TLS expuesta a Internet si publicas

Comparativa breve de soluciones

Solución	Instalación en Windows	DoH	DoT	Reenvíos por dominio	ACME integrado	UI/Facilidad	Escalabilidad
Technitium DNS Server	Servicio nativo	Sí	Sí	Sí (reglas por zona)	Sí (según versión/config)	Alta	Media‑alta
AdGuard Home	Servicio nativo	Sí	Sí	Sí (patrones por dominio)	No siempre; fácil con cliente externo	Alta	Media
dnsdist	Contenedor/VM o nativo	Sí	Sí	Con reglas Lua	No (usa ACME externo)	Media	Alta

Buenas prácticas de producción

Separación de funciones: si esperas alto tráfico, dedica hosts para el proxy y deja el DNS Windows enfocado en zonas AD.
Alta disponibilidad: al menos dos proxies DoH/DoT detrás de un balanceador (L4 o Anycast). Mantén múltiples controladores de dominio con DNS.
Rotación de certificados: automatiza y alerta antes del vencimiento. Ensaya renovaciones en “modo ensayo”.
Capacidad: calcula en base a QPS esperados ×2 con margen para picos. Pre‑calienta cachés cuando despliegues.
Compatibilidad de clientes: confirma que endpoints móviles/IoT aceptan DoT si no soportan DoH.

Cómo solicitar la característica a Microsoft

Cuantos más equipos con casos de uso claros reporten la necesidad, mayor probabilidad de que se incorpore soporte nativo DoH/DoT en el rol DNS de Windows Server. Para enviar feedback efectivo:

Usa Feedback Hub desde un equipo afectado. Selecciona la categoría de red/DNS.
Describe el impacto: cumplimiento normativo, privacidad, clientes que exigen cifrado, auditorías, etc.
Aporta datos: número de endpoints, QPS aproximados, requisitos de rendimiento y seguridad.
Si participas en Windows Insider, reporta también desde compilaciones preliminares, adjuntando diagnósticos.
Monitorea y anima a tu comunidad a votar o añadir escenarios adicionales en el portal de comentarios.

Ejemplos de configuración y automatización

Renovación con un cliente ACME (idea general)

# Renovar certificado (tarea programada)
C:\acme\wacs.exe --target manual --host dns.int.ejemplo `
  --installation none --store pemfiles `
  --pemfilespath C:\certs --closeonfinish

Recargar servicio tras renovar (post-hook)

powershell -Command "Restart-Service AdGuardHome"

o

powershell -Command "Restart-Service TechnitiumDNS"

Políticas de red y DHCP

# Establecer servidor DNS por interfaz (ejemplo)
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 10.0.0.20

Validar servidores DoH registrados

netsh dns show encryption

Errores comunes y cómo evitarlos

Certificados sin SAN correctos: el nombre del endpoint DoH/DoT debe aparecer en el certificado.
Olvido del mapeo IP→DoH en clientes Windows: sin él, no “autoupgradean” a DoH.
Exponer 53 a Internet por accidente: filtra 53/UDP y 53/TCP en bordes si solo publicarás 443/853.
QoS mal dimensionada: saturarás sockets TLS si no ajustas límites y keep‑alive.

Conclusiones y siguientes pasos

Hoy, el rol DNS de Windows Server no sirve DoH/DoT de forma nativa. Si necesitas cifrado ya, la estrategia ganadora es colocar un proxy DoH/DoT delante de tu DNS de Windows o incorporar un resolver paralelo con reglas por dominio. Empieza pequeño (un proxy en loopback), automatiza certificados, aplica ACL y rate‑limit, y después escala a alta disponibilidad. En paralelo, envía feedback a Microsoft con casos de uso cuantificados para impulsar el soporte nativo.

Resumen ejecutivo: Hoy no existe soporte nativo en el rol DNS Server de Windows Server para servir DoH/DoT. Si lo necesitas ya, coloca un proxy DoH/DoT delante de tu DNS de Windows y envía feedback a Microsoft por los canales oficiales para impulsar el soporte nativo.