DNS seguro en Windows: DoH/DoT — Qué funciona realmente

Qué significa realmente “DNS seguro” en Windows

El DNS es el servicio de directorio que toda tu pila da por fiable hasta que deja de serlo. El DNS tradicional usa mayormente UDP/53, no autenticado, y con frecuencia es observable o manipulado en el camino. “DNS seguro” suele referirse a uno de dos transportes:

• DoT (DNS sobre TLS): mensajes DNS dentro de TLS, típicamente TCP/853. Se percibe como “algo DNS” en la red. Más fácil de identificar y bloquear; a veces más fácil de permitir de forma intencionada.
• DoH (DNS sobre HTTPS): mensajes DNS dentro de HTTPS, típicamente TCP/443. Se mezcla con el tráfico web. Ideal para sortear captive portals y middleboxes problemáticos; también ideal para eludir la política DNS corporativa si no tienes cuidado.

Ni DoH ni DoT convierten automáticamente al DNS en algo “confiable”. Aún puedes consultar un resolutor que miente. Aún puedes filtrar consultas mediante fallback. Y aún puedes romper la resolución de nombres internos al enviar zonas privadas a resolutores públicos. El cifrado del transporte es una capa: ayuda la privacidad e integridad en tránsito, pero no es gobernanza.

En Windows, “DNS seguro” tiene un significado operativo específico: el cliente DNS de Windows (Dnscache) enviando consultas a un resolutor configurado usando DoH (y en algunos casos volviendo a texto claro). DoT no es la historia principal a nivel de SO como ocurre en otras plataformas; lo verás más en clientes dedicados, appliances o donde una empresa tiene forwarders compatibles con DoT.

Y luego hay un tercer eje: los navegadores. Chrome, Edge y Firefox pueden realizar su propio DoH independientemente de la configuración de Windows, dependiendo de políticas y ajustes. Así que puedes “activar DoH en Windows” y aún tener aplicaciones que lo evadan. O desactivarlo y seguir teniendo navegadores que lo usen. Aquí es donde a tu equipo de cumplimiento de repente le interesan las capturas de paquetes.

Una regla operativa: si no puedes probar qué resolutor respondió y por qué transporte, no tienes una configuración—tienes un sistema de creencias.

Hechos interesantes y contexto histórico (corto, útil, ocasionalmente molesto)

1. El DNS existía antes de la web por varios años. El trabajo en las especificaciones de DNS comenzó a inicios de los 80 como reemplazo escalable del enfoque de HOSTS.TXT.
2. DNSSEC es anterior a DoH/DoT. Los RFCs núcleo de DNSSEC aparecieron a mediados de los 2000; resuelven la autenticidad de los datos, no la privacidad del transporte.
3. DoT se estandarizó antes que DoH. DoT (RFC 7858) llegó primero; DoH (RFC 8484) siguió, impulsado en gran parte por comunidades de navegadores y privacidad.
4. Muchos “filtros DNS” dependen de la visibilidad en texto claro. Cuando cifras el DNS cambias no solo la privacidad, sino el plano de aplicación de políticas—a menudo sin avisar a quienes lo gestionan.
5. EDNS Client Subnet (ECS) complica la privacidad. Algunos resolutores envían fragmentos de la subred del cliente upstream para mejorar la localización de CDNs, intercambiando rendimiento por privacidad.
6. La resolución de nombres en Windows no es solo DNS. Existe LLMNR, mDNS, NetBIOS y reglas NRPT en algunos entornos; DoH solo cubre las consultas DNS que el cliente DNS de Windows realmente hace.
7. Los captive portals odian el DNS cifrado. A menudo dependen de interceptar DNS para redirigirte a una página de acceso; DoH evita eso—a veces bien, a veces “¿por qué no puedo conectarme al Wi‑Fi del hotel?”.
8. Las empresas históricamente usaron DNS como plano de control. Bloquear dominios, dirigir tráfico, sinkholing de malware o dividir vistas internas/externas—los transportes seguros no eliminan estas necesidades; cambian cómo las implementas.

Matriz de soporte en Windows: DoH vs DoT vs “magia del navegador”

Qué hace (y no hace) Windows

Windows 11 y builds modernas de Windows 10 soportan DoH a nivel del SO para el cliente DNS de Windows. Puedes configurarlo por interfaz y por resolutor. El SO intenta usar DoH para resolutores elegibles; dependiendo de la configuración, puede volver a texto claro si DoH falla. Ese comportamiento de fallback es la diferencia entre “bastante privado” y “silenciosamente filtrado”.

DoT a nivel de todo el SO no es la característica principal en endpoints Windows. Verás DoT en equipos de red, forwarders DNS y clientes de terceros. En endpoints Windows, cuando la gente dice “DNS seguro”, casi siempre se refiere a DoH.

Navegadores: un universo paralelo

Los navegadores pueden hacer DoH independientemente de Windows. Esto significa:

• Tu navegador puede usar DoH aunque Windows esté configurado para DNS en texto claro.
• Tu navegador puede seguir usando DNS en texto claro aunque Windows use DoH, según ajustes y políticas del navegador.
• El split DNS (zonas internas) puede fallar de formas creativas si un navegador usa un resolutor público para nombres que solo existen internamente.

En entornos corporativos necesitas una respuesta clara a: ¿aplicamos DoH en el SO, en el navegador, en la red, o no lo aplicamos? Mezclar “un poco de todo” es cómo obtienes fallos intermitentes que solo ocurren los martes, en salas de reuniones, cuando hay VPN y con Outlook abierto.

Los resolutores importan más que el marketing

DoH en Windows no es “activa cifrado y ya funciona”. Windows necesita un resolutor que soporte DoH y, según cómo lo configures, una plantilla mapeada conocida. Los resolutores públicos tienden a funcionar. Tu resolutor interno puede no hacerlo, a menos que hayas desplegado o comprado capacidad DoH.

Además: si ejecutas tu propio DoH, los detalles de certificados y SNI importan. TLS no es intuición; es estricto.

Broma #1: El DNS es como la política de oficina—todo funciona hasta que alguien dice “cámbialo rápido”.

Qué recomiendo (y qué evito)

Para la mayoría de las empresas: elige uno de estos dos modelos sensatos

Modelo A: resolutor empresarial + transporte cifrado hacia él. Los endpoints usan el resolutor corporativo (o un forwarder) como de costumbre, pero el transporte del endpoint al resolutor está cifrado (DoH si estás en Windows, DoT si lo estandarizas en otra parte). El resolutor aplica políticas, split DNS, registro y necesidades de respuesta a incidentes. Este es el modelo de “mantener gobernanza”.

Modelo B: resolutor público gestionado con controles estrictos de política. Si eres una organización pequeña o no manejas zonas internas, puedes usar resolutores públicos verificados con DoH y aplicarlo mediante políticas de endpoint. Pierdes capacidades de split DNS internas a menos que añadas otra cosa, pero también eliminas mucha complejidad.

Qué evito

• Fallback silencioso a texto claro a menos que hayas aceptado explícitamente el riesgo. Si la finalidad es privacidad/integridad, “mejor esfuerzo” se convierte en “mejor excusa”.
• Ejecutar zonas internas permitiendo que navegadores usen DoH público sin controles. Así es como el “intranet” deja de resolverse en el navegador pero sigue funcionando con ping, y todos culpan al proxy.
• Asumir que los clientes VPN no interferirán. Muchas VPN instalan su propio DNS, cambian métricas de interfaz o fuerzan resolutores específicos. Trata a la VPN como un motor de configuración DNS.
• Asumir que las herramientas de seguridad no interferirán. Algunos stacks de seguridad de endpoint y proxies de inspección TLS rompen o degradan DoH según la política.

Una cita para mantenerte honesto: La esperanza no es una estrategia. (idea parafraseada, común en operaciones y confiabilidad)

Tareas prácticas de verificación (comandos, salidas, decisiones)

Estas son tareas reales que puedes ejecutar desde una máquina Windows (PowerShell) o desde una jump box Linux en la misma red. Cada tarea incluye: comando, un fragmento realista de salida, qué significa y la decisión que debes tomar.

Task 1 — Identificar qué servidores DNS cree Windows que debe usar

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"
InterfaceAlias ServerAddresses
-------------- --------------
Ethernet       {10.20.0.10, 10.20.0.11}
Wi-Fi          {192.168.1.1}

Significado: Windows consultará 10.20.0.10/11 en Ethernet y 192.168.1.1 en Wi‑Fi. Si DoH está configurado, estará ligado a estas IPs de resolutor (y a veces a plantillas).

Decisión: Si esperas DNS empresarial en todas partes, 192.168.1.1 es una bandera roja. Arregla las reglas DHCP/VPN o las métricas de interfaz antes de perseguir fantasmas de DoH.

Task 2 — Comprobar la configuración DNS por interfaz y si es probable que filtres por “interfaz equivocada”

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Format-Table ifIndex,InterfaceAlias,InterfaceMetric,NlMtu -AutoSize"
ifIndex InterfaceAlias InterfaceMetric NlMtu
------ -------------- -------------- -----
12     Ethernet       15             1500
7      Wi-Fi          55             1500

Significado: Gana la métrica más baja. Ethernet será preferida para enrutamiento y a menudo para el comportamiento DNS alrededor de la “interfaz principal”.

Decisión: Si Wi‑Fi nunca debe usarse para resolución de nombres corporativa (común en escenarios de docking), aplica métricas o deshabilita la interfaz cuando estés en la estación.

Task 3 — Confirmar si Windows tiene DoH habilitado y para qué resolutores

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientDohServerAddress | Format-Table -AutoSize"
ServerAddress Template               AllowFallback AutoUpgrade
------------- --------               ------------- -----------
10.20.0.10    https://dns.corp/dns-query False         False
10.20.0.11    https://dns.corp/dns-query False         False

Significado: Windows tiene mapeos DoH explícitos para los resolutores corporativos, y AllowFallback False significa que no debe revertir silenciosamente a DNS en texto claro hacia esas IPs.

Decisión: Si no ves entradas, probablemente DoH no está configurado a nivel del SO. Si AllowFallback True, decide si aceptas el riesgo de filtrado por diseño ante fallos.

Task 4 — Inspeccionar el impacto de la Name Resolution Policy Table (NRPT) (común con VPN)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptRule | Select-Object -First 5 | Format-List"
Namespace : .corp.example
NameServers : {10.20.0.10, 10.20.0.11}
DirectAccessDnsServers :
DnsSecValidationRequired : False

Significado: Las consultas para .corp.example se fuerzan a servidores específicos. Esto puede anular elecciones “globales” de resolutor y es a menudo lo que quieres para split DNS.

Decisión: Si tu zona interna está definida aquí pero faltan mapeos DoH para esos servidores, obtendrás DNS en texto claro (o fallos) para nombres internos. Alinea NRPT y configuración DoH.

Task 5 — Consultar un registro y verificar qué servidor respondió (funcionalidad básica)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName intranet.corp.example -Type A -Server 10.20.0.10"
Name                           Type   TTL   Section    IPAddress
----                           ----   ---   -------    ---------
intranet.corp.example          A      60    Answer     10.30.4.25

Significado: La resolución básica funciona contra el resolutor corporativo.

Decisión: Si esto falla pero los nombres públicos sí se resuelven, tienes un problema de ruta para split-DNS—no un problema genérico de “DNS caído”.

Task 6 — Comprobar si el resolutor es alcanzable en el endpoint DoH desde el cliente

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection dns.corp -Port 443"
ComputerName     : dns.corp
RemoteAddress    : 10.20.0.10
RemotePort       : 443
InterfaceAlias   : Ethernet
TcpTestSucceeded : True

Significado: TCP/443 hacia el endpoint DoH es alcanzable desde este cliente en la interfaz esperada.

Decisión: Si esto es falso, deja de culpar a Windows DoH. Arregla enrutamiento, firewall, interceptación de proxy o split tunneling de la VPN primero.

Task 7 — Verificar la cadena de certificados que Windows verá (falla empresarial común)

cr0x@server:~$ powershell -NoProfile -Command "openssl s_client -connect dns.corp:443 -servername dns.corp -showcerts < NUL | findstr /R /C:\"subject=\" /C:\"issuer=\""
subject=CN = dns.corp
issuer=CN = Corp Issuing CA 01

Significado: El servicio presenta un certificado para dns.corp emitido por una CA interna.

Decisión: Si los endpoints no confían en esa CA, DoH fallará y puede hacer fallback. Distribuye la CA a todos los endpoints o usa certificados con confianza pública cuando sea apropiado.

Task 8 — Validar eventos operativos del cliente DNS de Windows (qué intentó hacer)

cr0x@server:~$ powershell -NoProfile -Command "wevtutil qe Microsoft-Windows-DNS-Client/Operational /c:5 /f:text"
Event[0]:
  Provider Name: Microsoft-Windows-DNS-Client
  Event ID: 3018
  Level: Warning
  Description: Name resolution for the name intranet.corp.example timed out after none of the configured DNS servers responded.

Significado: El cliente DNS agotó el tiempo de espera. Esto todavía no te dice DoH vs texto claro, pero demuestra que el problema está en la ruta del resolutor en el cliente (no en la app).

Decisión: Correlaciona marcas temporales con registros de firewall y con capturas de paquetes. Si los timeouts ocurren solo cuando DoH está habilitado, sospecha problemas de TLS/proxy.

Task 9 — Comprobar si un navegador está evitando el DNS del SO (Firefox es famoso por ser independiente)

cr0x@server:~$ powershell -NoProfile -Command "Get-Process firefox -ErrorAction SilentlyContinue | Select-Object -First 1 | Format-Table Name,Id"
Name    Id
----    --
firefox 10432

Significado: Firefox está en ejecución. Eso no es prueba de DoH, pero es un recordatorio: los navegadores pueden ignorar las decisiones del resolvedor del SO.

Decisión: Si los nombres internos fallan en el navegador pero funcionan en Resolve-DnsName, revisa las políticas de DoH del navegador antes de tocar la configuración DoH de Windows.

Task 10 — Confirmar si las solicitudes DNS aún usan UDP/53 (test de fuga mediante captura en una caja Linux)

cr0x@server:~$ sudo tcpdump -ni eth0 'host 10.20.0.50 and (udp port 53 or tcp port 53 or tcp port 443)' -c 10
IP 10.20.0.50.51722 > 10.20.0.10.443: Flags [S], seq 11223344, win 64240, options [mss 1460], length 0
IP 10.20.0.10.443 > 10.20.0.50.51722: Flags [S.], seq 99887766, ack 11223345, win 65160, options [mss 1460], length 0
IP 10.20.0.50.51722 > 10.20.0.10.443: Flags [.], ack 1, win 64240, length 0

Significado: Estás viendo handshakes TCP/443 hacia el resolutor. No estás viendo UDP/53 en estos primeros paquetes, lo cual es una buena señal para uso de DoH (no definitivo sin inspección más profunda).

Decisión: Si ves UDP/53 hacia el resolutor mientras crees que DoH está forzado, o bien el fallback está habilitado, falta el mapeo DoH o se está usando otro resolutor.

Task 11 — Confirmar ajustes de proxy que puedan interceptar o bloquear DoH

cr0x@server:~$ powershell -NoProfile -Command "netsh winhttp show proxy"
Current WinHTTP proxy settings:

    Proxy Server(s) : 10.20.1.25:8080
    Bypass List     : (none)

Significado: Los servicios del sistema que usan WinHTTP pasarán por un proxy salvo excepciones. Algunas implementaciones y endpoints DoH no funcionan bien con esta disposición.

Decisión: Si el endpoint DoH es interno, añádelo a la lista de bypass. Si es externo, decide si la inspección del proxy está permitida y si rompe la semántica DoH.

Task 12 — Inspeccionar el comportamiento de la caché DNS local (la obsolescencia puede parecer “DoH roto”)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientCache | Select-Object -First 5 | Format-Table -AutoSize Entry,Data,TimeToLive"
Entry                 Data           TimeToLive
-----                 ----           ----------
intranet.corp.example 10.30.4.25     00:00:42
wpad.corp.example     10.20.1.25     00:12:10

Significado: La caché del cliente tiene entradas con TTL. Si cambiaste registros recientemente y “aún resuelve mal”, puede que esté en caché.

Decisión: Si estás diagnosticando corrección, vacía la caché y vuelve a probar. Si diagnosticas rendimiento, la caché es parte de la historia—no la vacíes salvo que necesites.

Task 13 — Vaciar la caché DNS para aislar resolutor vs caché

cr0x@server:~$ powershell -NoProfile -Command "Clear-DnsClientCache; Write-Output 'cache cleared'"
cache cleared

Significado: Caché vaciada en el cliente.

Decisión: Si los problemas desaparecen tras vaciar la caché y luego regresan, persigues TTL/caché negativa o respuestas inconsistentes upstream—no un problema de transporte.

Task 14 — Probar qué proceso usa el puerto 53 localmente (raro, pero sucede)

cr0x@server:~$ powershell -NoProfile -Command "netstat -ano | findstr \":53 \" | more"
  UDP    0.0.0.0:5353           *:*                                    1234
  UDP    192.168.1.10:49712     192.168.1.1:53                         0

Significado: Tienes mDNS (5353) y tráfico saliente UDP/53 desde el host. La línea UDP/53 implica que todavía se usa DNS en texto claro en alguna parte.

Decisión: Si esperabas solo DoH, averigua por qué existe UDP/53: otra interfaz, otro resolutor, fallback o un servicio local (VPN, agente de seguridad) que realiza su propia resolución.

Task 15 — Comprobar sobrescrituras en hosts (porque alguien siempre “arregló DNS” localmente)

cr0x@server:~$ powershell -NoProfile -Command "Get-Content C:\Windows\System32\drivers\etc\hosts | Select-Object -Last 5"
# ::1             localhost
10.30.4.99        intranet.corp.example

Significado: El archivo hosts fuerza intranet.corp.example a 10.30.4.99. Aquí el transporte DNS es irrelevante.

Decisión: Elimina sobrescrituras no autorizadas y vuelve a probar. En una empresa, trata esto como un incidente de desviación de configuración, no como un “ajuste del usuario”.

Guía rápida de diagnóstico

Este es el orden que encuentra el cuello de botella rápido sin ahogarte en teoría.

Primero: ¿es selección de DNS, no cifrado del DNS?

• Ejecuta Get-DnsClientServerAddress y confirma que las IPs de resolutor esperadas estén realmente configuradas.
• Revisa métricas de interfaz con Get-NetIPInterface cuando existan múltiples adaptadores (Wi‑Fi + Ethernet + VPN).
• Revisa reglas NRPT si tienes VPN o split DNS.

Si se seleccionó el resolutor equivocado: arregla DHCP/VPN/política/prioridad de interfaz. No empieces por ajustar plantillas DoH.

Segundo: ¿es alcanzable y confiable el endpoint DoH?

• Test-NetConnection a TCP/443 en el hostname DoH.
• openssl s_client para verificar sujeto/issuer del certificado y comportamiento SNI.
• Revisa proxy WinHTTP con netsh winhttp show proxy.

Si TLS/cert/proxy es el problema: verás timeouts o fallos de handshake; arregla la cadena de confianza y bypass del proxy. No sigas alternando fallback esperando que “se estabilice”.

Tercero: ¿estás filtrando mediante fallback u otras pilas?

• Revisa Get-DnsClientDohServerAddress por AllowFallback.
• Captura tráfico (tcpdump/Wireshark) buscando presencia de UDP/53.
• Valida comportamiento/política DoH a nivel de navegador si los síntomas son específicos de una app.

Si existe filtrado: decide si impones “solo DoH” (y aceptas roturas cuando falla) o permites fallback (y aceptas brechas de privacidad/integridad). Elige deliberadamente.

Cuarto: ¿es realmente un problema de rendimiento del resolutor?

• Compara latencia de consultas (percepción del cliente) antes y después de activar DoH.
• Busca churn de sesiones TLS (conexiones nuevas frecuentes) versus reutilización.
• Revisa síntomas de tasa de aciertos de caché local (los problemas desaparecen tras calentar la caché).

Si es rendimiento: probablemente necesites ajustar capacidad del resolutor, comportamiento keep-alive o coste del motor de políticas—not “más cifrado”.

Tres micro-historias corporativas desde el campo

Incidente #1 — El corte causado por una suposición equivocada

El plan era simple: habilitar DoH en portátiles Windows para reducir el snooping DNS en Wi‑Fi público. El despliegue fue por fases, la política estaba acotada y el ticket CAB tenía ese aura familiar de “mejora inofensiva”.

Dos días después, las aplicaciones web internas empezaron a fallar—solo en navegadores, solo para algunos usuarios y solo cuando estaban fuera de la oficina. Hacer ping a nombres internos funcionaba. Remote Desktop funcionaba. Pero el portal intranet devolvía “host not found” en Edge y Chrome.

La suposición equivocada fue sutil: todos pensaron que “la configuración DNS de Windows” controlaba “el DNS”. En realidad, los navegadores tenían DoH oportunista habilitado con un resolutor público. Cuando los usuarios estaban fuera, el navegador enviaba nombres internos al resolutor público, que obviamente no los conocía. Mientras tanto, Windows resolvía esos nombres vía DNS proporcionado por la VPN sin problemas, así que las apps no navegador parecían sanas.

La solución no fue heroica. Hicieron cumplir una política de navegador: o desactivar DoH del navegador o apuntarlo al endpoint DoH corporativo que entendiera split DNS. Tras eso, los síntomas desaparecieron. La lección quedó: la resolución de nombres es una pila de pilas, y los navegadores ya no son “solo aplicaciones”—son plataformas con opiniones.

Incidente #2 — La optimización que salió mal

Otra compañía tuvo una queja de rendimiento: “DNS lento en Windows cuando DoH está habilitado”. Alguien notó que el endpoint DoH estaba detrás de un proxy de capa 7 que hacía inspección TLS y autenticación. La optimización rápida fue mover el servicio DoH detrás de un balanceador de carga global con health checks agresivos y timeouts de conexión cortos. En papel: menor latencia, mejor disponibilidad.

En la práctica, el balanceador terminaba TLS y lo restablecía hacia upstream. Eso no era automáticamente malo, pero creó churn constante de conexiones. Algunos clientes se reconectaban con frecuencia y el servicio DoH gastaba mucho CPU en handshakes. En horas pico, el resolutor era efectivamente una fábrica de TLS con un negocio secundario en respuestas DNS.

Peor aún: los health checks parecían “tráfico HTTPS válido” pero no probaban consistentemente el handler real de DoH. El LB declaró backends saludables incluso cuando la ruta DoH estaba degradada, porque la capa TCP/TLS estaba bien. Los usuarios vieron fallos intermitentes que no correlacionaban con nada obvio salvo “después de comer”.

Revirtieron la “optimización” y luego reintrodujeron cambios con cuidado: keep-alive ajustado, health checks apuntando a la ruta DoH real y evitando terminaciones TLS innecesarias. El rendimiento mejoró, pero la victoria real fue la claridad operativa: si no puedes medir el handler DoH separado del TLS, vas a volar a ciegas.

Incidente #3 — La práctica aburrida pero correcta que salvó el día

Una gran empresa tenía una práctica de cambios estricta: antes de cualquier cambio en el transporte DNS, actualizaban un runbook interno con “patrones de paquete esperados”, logs de eventos a chequear y un plan simple de rollback. La gente se quejaba de que era lento. También fue la razón por la que no se derritieron.

Durante un ciclo global de actualización de Windows, un subconjunto de dispositivos empezó a fallar en DoH por un problema de confianza de certificados. La cadena de certificados del resolutor era correcta, pero una rotación de CA intermedia no estaba completamente desplegada en todas las imágenes de dispositivo. Algunos portátiles podían validar la cadena; otros no. El comportamiento resultante dependía de las configuraciones de fallback y de si el dispositivo estaba en VPN.

Puesto que el equipo tenía una lista de comprobación definida, el helpdesk no perdió días culpando a “internet”. Reunieron un paquete estándar: salida de mapeos DoH, logs de eventos y una comprobación TLS rápida. El patrón fue evidente en horas: los dispositivos sin la CA intermedia no podían hacer DoH, y los dispositivos con fallback deshabilitado tenían fallos duros.

La solución fue aburrida también: distribuir la intermedia faltante vía gestión de endpoints, confirmar mediante una comprobación dirigida del almacén de certificados y volver a ejecutar las tareas de validación. Nadie ganó un trofeo. Pero nadie tuvo un incidente de una semana. En operaciones, el aburrimiento a menudo es la forma más alta de competencia.

Errores comunes: síntomas → causa raíz → solución

1) “DNS seguro habilitado” pero la captura muestra UDP/53

Síntomas: Sigues viendo consultas DNS a UDP/53 saliendo del host; herramientas de privacidad reportan fugas.

Causa raíz: DoH no está configurado para las IPs reales del resolutor; fallback permitido; o otra interfaz/adaptador VPN aún usa DNS en texto claro.

Solución: Verifica las IPs del resolutor (Get-DnsClientServerAddress), verifica mapeos DoH (Get-DnsClientDohServerAddress), configura AllowFallback False donde corresponda y arregla la prioridad de adaptadores.

2) Nombres internos fallan solo en el navegador

Síntomas: Resolve-DnsName intranet.corp.example funciona; el navegador muestra NXDOMAIN o no puede resolver.

Causa raíz: DoH a nivel de navegador usando resolutores públicos; split DNS no respetado.

Solución: Impone política de navegador para deshabilitar DoH o usar DoH corporativo; asegura que las zonas internas se resuelvan por la ruta del resolutor corporativo.

3) DoH funciona en la sede pero falla en VPN

Síntomas: En LAN: bien. En VPN: timeouts. Desactivar “DNS seguro” hace que funcione.

Causa raíz: La VPN empuja reglas NRPT o servidores DNS que no tienen mapeos DoH; la VPN bloquea acceso al endpoint DoH; las configuraciones de proxy difieren en VPN.

Solución: Alinea los resolutores entregados por VPN con mapeos DoH; asegura que el hostname DoH sea alcanzable sobre VPN; añade bypass de proxy correcto para el endpoint DoH.

4) Fallos intermitentes tras habilitar DoH

Síntomas: Algunas consultas cuelgan y luego tienen éxito. Timeouts aleatorios de aplicaciones. “Funciona tras reiniciar”.

Causa raíz: Inestabilidad de handshake TLS (proxy de inspección, problemas MTU), restricciones de capacidad del resolutor o balanceador de carga cerrando conexiones inactivas agresivamente.

Solución: Valida path MTU; revisa reachability TCP/443 y la cadena TLS; ajusta keep-alives/timeouts del LB; escala el resolutor o reduce coste de evaluación de políticas.

5) “El endpoint DoH está arriba” pero Windows no lo usa

Síntomas: HTTPS al endpoint funciona en un navegador; Windows sigue usando DNS en texto claro o falla.

Causa raíz: Falta mapeo/plantilla DoH para la IP del resolutor; mismatch de nombre de certificado; problemas SNI.

Solución: Asegura que la plantilla DoH coincida con el resolutor y que el certificado sea válido para el hostname usado por Windows; valida con openssl s_client -servername.

6) El filtrado DNS dejó de funcionar “misteriosamente”

Síntomas: Dominios que antes se bloqueaban ahora resuelven; el equipo de seguridad ve menos telemetría DNS.

Causa raíz: Endpoints/navegadores migraron a resolutores DoH externos, saltándose controles DNS empresariales.

Solución: Haz cumplir la política de resolutor (endpoint y/o control de egress en red). Si necesitas filtrado, mantén la resolución en resolutores que controles.

Broma #2: El DNS cifrado es genial hasta que te das cuenta de que la herramienta favorita del helpdesk era “ver qué dominio escribió la gente”.

Listas de verificación / plan paso a paso

Plan A — Despliegue DoH en Windows de grado empresarial (sin heridas autoinfligidas)

1. Inventario tus resolutores: lista las IPs de servidores DNS que los endpoints reciben en LAN, Wi‑Fi y VPN. Si no puedes listarlos, no estás listo.
2. Decide tu postura de aplicación: permitir fallback (menos riesgo de caída, más fugas) vs sin fallback (garantía más fuerte, más frágil). Escríbelo.
3. Pon en marcha/valida un endpoint DoH: asegura reachability TCP/443 desde todas las redes, certificados correctos, comportamiento SNI correcto y balanceo predecible.
4. Implementa mapeos DoH: mapea cada IP de resolutor a una plantilla endpoint DoH y configura comportamiento de fallback.
5. Maneja el split DNS explícitamente: reglas NRPT para zonas internas que apunten a resolutores corporativos con DoH habilitado.
6. Alinea la política de navegadores: o deshabilita DoH en navegadores o apúntalos al mismo endpoint DoH corporativo para evitar roturas de split-DNS.
7. Mide antes/después: latencia de resolución, tasa de fallos y presencia de egress UDP/53. “Se siente bien” no es una métrica.
8. Despliega por anillos: IT, usuarios avanzados y luego despliegue amplio. Captura logs y muestras de paquetes en cada anillo.
9. Tener un rollback: un solo toggle de política para volver a DNS en texto claro mientras diagnosticas.

Plan B — Organización pequeña / sin zonas internas (simple y robusto)

1. Elige una estrategia de resolutor: un proveedor, dos IPs para redundancia, endpoint DoH estable.
2. Habilita DoH a nivel del SO con mapeo explícito y decide sobre fallback. Si lo haces por privacidad, no pongas fallback a “vale, lo que sea”.
3. Valida egress: confirma que solo se usa TCP/443 hacia el resolutor y que UDP/53 no escapa a routers aleatorios.
4. Mantén los navegadores consistentes: no dejes que el navegador elija un resolutor distinto del SO a menos que te guste depurar.

Checklist operativo — Antes de culpar a DoH

• ¿Es correcta la IP del resolutor para esta red?
• ¿Es alcanzable el hostname DoH en TCP/443 desde esta red?
• ¿Confía en la cadena de certificados el endpoint?
• ¿Está un proxy interceptando o bloqueando el flujo DoH?
• ¿Está el navegador usando su propia configuración DoH?
• ¿Las capturas muestran UDP/53 (fuga) o solo 443 (esperado)?

Preguntas frecuentes

1) ¿Habilitar DoH en Windows asegura automáticamente todo el DNS en la máquina?

No. Asegura las consultas DNS hechas vía el cliente DNS de Windows a resolutores que estén configurados/mapeados para DoH. Las apps y navegadores pueden hacer su propio DNS (incluyendo su propio DoH), y otros protocolos como mDNS/LLMNR son independientes.

2) ¿Es DoH “mejor” que DoT?

Operativamente: DoT es más fácil de identificar y gestionar a nivel de red; DoH es más difícil de distinguir del HTTPS normal y por tanto más difícil de controlar. En privacidad pueden ser ambos buenos. En empresas, “mejor” suele significar “encaja con nuestra política y no rompe split DNS”.

3) ¿Por qué se rompe el split DNS interno cuando se habilita DoH?

Se rompe cuando las consultas de zonas internas van a un resolutor que no las conoce—a menudo un resolutor público DoH usado por un navegador. Soluciona imponiendo la política de navegador y asegurando que las zonas internas se resuelvan a través de resolutores corporativos (NRPT ayuda).

4) Si desactivo el fallback, ¿se romperá algo?

A veces, y ese es el punto: fallarás cerrado en lugar de filtrar silenciosamente. Si tu endpoint DoH es poco fiable o está bloqueado en algunas redes, desactivar el fallback hará que eso sea visible como fallos para el usuario. Decide según tu modelo de amenazas y tolerancia a caídas.

5) ¿Puede un proxy de inspección TLS romper DoH?

Sí. Algunos proxies bloquean o interfieren con endpoints DoH; otros “funcionan” pero añaden latencia y modos de fallo. Si debes inspeccionar, trata DoH como una aplicación con sus propios SLOs y pruébala como tal.

6) ¿Cómo demuestro que DoH realmente se está usando?

Usa una combinación: revisa mapeos DoH en Windows, verifica conectividad TCP/443 al endpoint DoH y captura tráfico para confirmar ausencia de UDP/53 hacia tus resolutores. Para prueba profunda, inspecciona peticiones HTTPS a la ruta DoH en el servidor (logs) o con telemetría de endpoint.

7) ¿Por qué veo UDP/53 aun cuando DoH está configurado?

Razones comunes: fallback activado, otra interfaz usando DNS en texto claro, VPN inyectó resolutor sin mapeo DoH o un agente local hace su propia resolución. Trata UDP/53 como síntoma y traza qué proceso/interfaz lo generó.

8) ¿DoH reemplaza a DNSSEC?

No. DoH cifra el transporte; DNSSEC firma registros para autenticidad (cuando se valida correctamente). Resuelven problemas distintos y pueden usarse juntos.

9) ¿DoH mejorará el rendimiento del DNS?

A veces, pero no cuentes con ello. DoH añade sobrecarga TLS y puede ser más lento si las conexiones churnean o si los proxies interfieren. Las mejoras de rendimiento suelen venir de mejores resolutores, caché y enrutamiento—no solo del cifrado.

10) ¿Cuál es la configuración más segura por defecto para portátiles corporativos?

Resolutor corporativo + mapeo DoH explícito + política de navegador alineada a la resolución corporativa + una decisión deliberada sobre fallback. “Más seguro” es consistencia. La resolución inconsistente es cómo obtienes brechas de seguridad y caídas al mismo tiempo.

Próximos pasos que no arruinarán tu lunes

Haz esto en orden:

1. Elige tu modelo: resolutor corporativo con transporte DoH, o resolutor público gestionado. No hagas ambos sin límites claros.
2. Hazlo observable: decide cómo probarás transporte e identidad del resolutor (logs de eventos, capturas de paquetes, logs del servidor).
3. Alinea navegadores: aplica políticas para que los navegadores no evadan tu estrategia DNS.
4. Decide el fallback: acepta fugas (fallback activado) o acepta caídas (fallback desactivado). Documenta la decisión y el rollback.
5. Ejecuta las tareas arriba en tres redes: LAN de HQ, Wi‑Fi doméstico y VPN. La mayoría de fallos DNS son “funciona en un sitio”.

Si no haces otra cosa: deja de depender de suposiciones. El DNS seguro en Windows funciona—cuando lo tratas como plomería de producción, no como una etiqueta de privacidad.