DoH/DoT: la victoria de privacidad que rompe el DNS split-horizon (solución incluida)

Qué se rompe realmente: DNS split-horizon vs DNS cifrado

El DNS split-horizon es un truco antiguo y aburrido que funciona porque la elección del resolutor por parte del cliente es predecible. Publicas respuestas diferentes
para el mismo nombre según desde dónde venga la consulta. Dentro de la red, app.corp.example resuelve a una dirección RFC1918.
Fuera, resuelve a una dirección pública o a NXDOMAIN. No es “seguridad” por sí mismo, pero es absolutamente un Mecanismo en el que se apoyan muchos controles de seguridad y diseños de enrutamiento.

El DNS cifrado cambia la relación con el resolutor. Con DoH/DoT, el tráfico DNS va envuelto en TLS y—más importante—los clientes pueden
elegir resolutores fuera de tu control. Eso significa:

• Es posible que tus zonas internas nunca sean consultadas.
• Es posible que tus reenviadores condicionales nunca se ejecuten.
• Es posible que tus controles de acceso basados en DNS (listas de permitir/bloquear, sinkholes, telemetría de seguridad) no vean nada.
• El “te empujamos estos servidores DNS y estos dominios de búsqueda” de la VPN se vuelve más una sugerencia.

La concepción equivocada común es “DoH/DoT solo es cifrado; no cambia DNS”. En la práctica, cambia quién responde. Ese es el rompimiento.
La ganancia de privacidad y la pérdida operacional son el mismo evento.

DoH vs DoT en términos operativos

DoT suele funcionar en TCP/853 hacia un resolutor. Se ve como “un protocolo DNS con TLS”. Se configura a menudo a nivel de SO
(Android “Private DNS” es un ejemplo famoso). Es más fácil de identificar por puerto, pero no siempre es sencillo interceptarlo responsablemente.

DoH corre sobre HTTPS (TCP/443) y usa un formato de petición/respuesta HTTP. Es “DNS camuflado como tráfico web”, y eso
no es ni siquiera un insulto—es exactamente el punto. Se mezcla. Se beneficia de la infraestructura y middleboxes HTTPS existentes. También evita
muchos controles de red porque parece una petición web más.

La falla de split-horizon suele venir de uno de estos patrones:

1. DoH del navegador anula el DNS del SO. Tu resolutor del SO apunta al DNS de la VPN, pero el navegador envía consultas a un endpoint DoH público.
2. DoT a nivel de SO configurado hacia un resolutor público. El endpoint está “seguramente equivocado” todo el día.
3. Pila dual de resolutores compite. El cliente intenta múltiples resolutores; el público gana por latencia y cachea la respuesta incorrecta.
4. Portales cautivos / infraestructura de interceptación crean casos de borde. El cliente ve fallos TLS, cae a un mecanismo alternativo, y ahora tienes nondeterminismo.

Un chiste corto, porque nos lo hemos ganado: El DNS cifrado es como susurrar tu pregunta dentro de un megáfono apuntado al servicio de atención de otro.
¿Privado? Sí. ¿Útil? Depende de quién conteste.

Hechos e historia para discutir con seguridad y producto

Esto no son datos para un trivial. Es el tipo de contexto que usas para tomar una decisión en una revisión de cambios sin necesitar un debate de dos horas.

1. Los problemas de privacidad de DNS preceden a DoH/DoT por décadas. “DNS en texto claro” siempre fue verdad; lo que cambió es que navegadores y SOs comenzaron a actuar sobre ello.
2. DoT (RFC 7858) llegó antes que DoH (RFC 8484). La respuesta estándar de la industria fue primero “TLS en un puerto DNS específico”, no “HTTP para todo”.
3. Los navegadores popularizaron la elección de resolutor como característica de producto. Eso desplazó la selección del resolutor de los operadores de red hacia los proveedores de aplicaciones.
4. El split-horizon DNS es anterior a la mayoría de productos VPN usados hoy. La técnica precede con mucho al etiquetado “zero trust”.
5. El DNS empresarial no es solo nombre→IP. A menudo es el plano de distribución para descubrimiento de servicios, registros SRV y flujos de validación de certificados internos.
6. DNSSEC no cifra. Autentica respuestas, pero no oculta consultas ni evita la observación on-path de nombres.
7. EDNS Client Subnet (ECS) empeoró la privacidad para algunos usuarios. Puede filtrar información de la red del cliente a servidores autoritativos para mejorar el enrutamiento CDN.
8. Algunas plataformas implementan DNS cifrado “oportunista”. Si el resolutor lo soporta, se usa; si no, cae silenciosamente. Eso puede crear comportamiento dependiente del entorno.
9. Los resolutores no son iguales. Diferentes resolutores recursivos tienen políticas de caché, comportamientos de filtrado y caché negativo distintos. Puedes ver respuestas diferentes para el mismo nombre.

La conclusión operativa: DoH/DoT no fue inventado para molestar a las empresas. Se inventó porque el DNS en texto claro es una responsabilidad. Tu trabajo es
conservar esa mejora de privacidad sin permitir que el software de endpoints elija aleatoriamente tu plano de control.

Modos de fallo: cómo se manifiesta en producción

1) Nombres internos resuelven a IPs públicas (o no resuelven)

El rompimiento clásico de split-horizon: jira.corp.example resuelve a algo público, o NXDOMAIN, porque el resolutor público no conoce tu zona interna.
Tu DNS interno habría devuelto 10.30.4.17. En su lugar obtienes nada—o peor, un hostname de CDN público que no pretendías.

Esto afecta más a usuarios en VPN porque esperan que “los nombres internos funcionen cuando la VPN está activa.” Pero si el resolutor del cliente evita la VPN,
la VPN es solo un router elegante sin idea del nombre que escribiste.

2) SSO y validación de certificados se descontrolan

Las apps internas a menudo dependen de CAs internas, respondedores OCSP internos, IdPs internos y endpoints de servicio cuyos nombres solo existen internamente.
Si el endpoint pregunta a un resolutor externo y obtiene NXDOMAIN, ves:

• Bucle en redirecciones de SSO (el hostname del IdP no resuelve)
• “No se puede validar el certificado” (endpoints OCSP/CRL no alcanzables)
• Fallos parciales raros donde la app carga pero la autenticación falla

3) Los controles de seguridad basados en DNS pierden visibilidad

Si tu programa de seguridad depende de logs DNS, bloqueo, sinkholing o detección de anomalías, DoH puede abrir un agujero. No porque el cifrado sea malo,
sino porque la consulta nunca llega a tu resolutor. La primera vez que aprendes esto será durante un incidente, que es un momento terrible para aprender.

4) “Solo falla en algunos portátiles” (el peor tipo de fallo)

La diversidad de endpoints convierte esto en una pesadilla. Un usuario tiene Android Private DNS apuntando a un resolutor público. Otro usa un navegador con DoH activado.
Otro está en una build gestionada donde deshabilitaste DoH, pero su cliente VPN tiene su propia pila DNS. Obtienes una mezcla de comportamientos que parecen una red inestable.

5) Kubernetes / service mesh añade una segunda capa de confusión

En clusters ya tienes CoreDNS, stub domains y descubrimiento de servicios en-cluster. Si nodos o pods comienzan a usar DoH/DoT externo, puedes obtener
resolución que difiere entre el host y el pod, o entre pods en distintos nodos. Depurar “DNS” pasa a ser depurar tres pilas DNS a la vez.

Guía de diagnóstico rápido (comprueba 1/2/3)

Cuando los nombres internos fallan, no empieces con capturas de paquetes. Empieza probando qué resolutor está respondiendo y si el cliente está evitando la ruta prevista.
El objetivo es reducir el problema a: resolutor equivocado, resolutor correcto pero respuesta equivocada, o respuesta correcta pero el tráfico no puede alcanzarla.

Comprobación 1: Identificar el resolutor que realmente se usa

• En el cliente, revisa los servidores DNS configurados (interfaz VPN vs interfaz Wi‑Fi).
• Comprueba si el navegador o el SO están usando DoH/DoT hacia un resolutor externo.
• Verifica con una consulta que apunte explícitamente a tu resolutor interno y compara.

Comprobación 2: Comparar respuestas internas vs externas

• Consulta el resolutor interno por el nombre que falla.
• Consulta un resolutor público conocido por el mismo nombre.
• Si las respuestas difieren, tienes split-horizon funcionando—y el cliente está escogiendo el horizonte equivocado.

Comprobación 3: Validar la ruta y la política

• Si el cliente usa correctamente el DNS interno, revisa el reenvío, las views y los ACLs en el resolutor.
• Verifica reglas de firewall: ¿está permitido que el cliente alcance DNS interno por 53/udp y 53/tcp?
• Busca interceptación de DNS en redes de invitados o appliances de “seguridad” que reescriban DNS.

Solo después de estas tres comprobaciones empiezas a indagar en cachés, TTL negativos, comportamiento EDNS y las cosas realmente divertidas.

Tareas prácticas: comandos, salidas y la decisión que tomas

Estas son las tareas que ejecuto en incidentes. Cada una tiene: comando, salida de ejemplo, qué significa y la decisión que impulsa.
Ajusta hostnames e IPs a tu entorno.

Task 1: Ver qué servidores DNS cree usar systemd-resolved (Linux)

cr0x@server:~$ resolvectl status
Global
       Protocols: +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 resolv.conf mode: stub
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53 1.1.1.1
        DNS Domain: corp.example

Link 2 (wg0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53
        DNS Domain: corp.example

Significado: Tienes tanto un resolutor interno (10.20.0.53) como un resolutor público configurado (1.1.1.1).
Incluso si wg0 parece correcto, algunos resolutores competirán o caerán como fallback.

Decisión: Elimina resolutores públicos de clientes gestionados cuando se requiera split-horizon, o aplica enrutamiento por dominio con un resolutor stub local.

Task 2: Comprobar si systemd-resolved usa DNS-over-TLS

cr0x@server:~$ resolvectl dnsovertls
Global setting: no
Link 2 (wg0): no
Link 3 (wlp0s20f3): no

Significado: Aquí no está habilitado DoT. Si aún ves rupturas de split-horizon, busca DoH del navegador o un agente de terceros.

Decisión: Cambia el foco a la configuración del navegador, software de seguridad en el endpoint o funciones Private DNS en Android/iOS.

Task 3: Comparar respuestas de resolutores interno vs público (dig)

cr0x@server:~$ dig +short jira.corp.example @10.20.0.53
10.30.4.17

cr0x@server:~$ dig +short jira.corp.example @1.1.1.1

Significado: El resolutor interno devuelve la IP privada; el resolutor público no devuelve nada (NXDOMAIN o vacío por política).

Decisión: Esto no es un incidente de “app caída”. Es un problema de selección de resolutor. Arregla el enrutamiento del resolutor en el cliente, no la app.

Task 4: Confirmar si un navegador hace DoH observando conexiones (Linux)

cr0x@server:~$ sudo ss -tpn | grep -E ':443' | head
ESTAB 0 0 192.168.1.50:52114 104.16.248.249:443 users:(("firefox",pid=2148,fd=91))
ESTAB 0 0 192.168.1.50:52122 8.8.8.8:443 users:(("firefox",pid=2148,fd=93))

Significado: El navegador habla con IPs públicas en 443. Eso es normal para web. La pregunta es si alguna de esas es un endpoint DoH.
Si sospechas DoH hacia un proveedor específico, correlaciona con IPs de endpoints conocidas de tu allowlist/intel, o inspecciona SNI/rutas HTTP en un entorno controlado.

Decisión: Si esto es un entorno empresarial gestionado, deshabilita DoH del navegador vía política o apúntalo a tu servicio DoH interno.

Task 5: Confirmar que las consultas DNS llegan a tu resolutor (tcpdump en el resolutor)

cr0x@server:~$ sudo tcpdump -ni eth0 port 53 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:41:11.225318 IP 10.20.14.22.52433 > 10.20.0.53.53: 12345+ A? jira.corp.example. (35)
12:41:11.225902 IP 10.20.0.53.53 > 10.20.14.22.52433: 12345* 1/0/0 A 10.30.4.17 (51)

Significado: Al menos un cliente está usando tu resolutor para ese nombre. Si el usuario aún reporta fallo, el problema podría ser caché en el cliente,
un resolutor diferente usado de forma intermitente, o enrutamiento/firewall hacia la IP devuelta.

Decisión: Si no ves consultas durante una prueba del usuario, el cliente está evadiendo tu resolutor (DoH/DoT o servidor DNS distinto).

Task 6: Buscar tráfico DoT (TCP/853) saliendo de un subnet de clientes (firewall u host)

cr0x@server:~$ sudo tcpdump -ni eth0 tcp port 853 -c 3
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:42:09.114220 IP 10.20.14.22.48932 > 9.9.9.9.853: Flags [S], seq 366451, win 64240, options [mss 1460,sackOK,TS val 248490 ecr 0,nop,wscale 7], length 0

Significado: Ese cliente intenta DoT hacia un resolutor público. Si tu split-horizon depende del DNS interno, esto es una causa directa.

Decisión: Bloquea 853 saliente desde redes corporativas (con excepciones para tu propio servicio DoT) y aplica política en endpoints.

Task 7: Inspeccionar selección de servidores DNS en Windows (PowerShell)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"
InterfaceAlias ServerAddresses
-------------- --------------
Wi-Fi          {192.168.1.1}
CorpVPN        {10.20.0.53, 10.20.0.54}

Significado: Wi‑Fi tiene su propio DNS (a menudo el router doméstico), y la VPN tiene DNS interno. Windows típicamente prefiere la interfaz VPN para DNS cuando está configurado correctamente,
pero las métricas y reglas NRPT importan.

Decisión: Confirma métricas de interfaz y añade reglas de resolución de nombres para que corp.example siempre use el resolutor de la VPN.

Task 8: Revisar la tabla de políticas de nombre en Windows (NRPT)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-DnsClientNrptRule | Select-Object Namespace,NameServers,DirectAccess | Format-List"
Namespace    : .corp.example
NameServers  : {10.20.0.53, 10.20.0.54}
DirectAccess : False

Significado: Las consultas para *.corp.example deben ir a los resolutores internos independientemente de la configuración DNS general.

Decisión: Si falta, añade NRPT (vía GPO/MDM). Es una de las maneras más limpias de preservar split-horizon en una flota Windows.

Task 9: Confirmar dominios y orden de resolutores en macOS

cr0x@server:~$ scutil --dns | sed -n '1,80p'
DNS configuration

resolver #1
  search domain[0] : corp.example
  nameserver[0] : 10.20.0.53
  nameserver[1] : 10.20.0.54
  if_index : 12 (utun3)
  flags    : Request A records
  reach    : 0x00000002 (Reachable)

resolver #2
  nameserver[0] : 192.168.1.1
  if_index : 6 (en0)
  reach    : 0x00000002 (Reachable)

Significado: El resolutor de la VPN está acotado a corp.example. Eso es bueno. Si los usuarios aún fallan, sospecha DoH a nivel de aplicación o un resolutor que no respete dominios acotados.

Decisión: Mantén resolutores acotados; publica un perfil DoH gestionado si necesitas DNS cifrado sin perder split-horizon.

Task 10: Probar si el resolutor interno puede recursar y reenviar correctamente

cr0x@server:~$ dig +nocmd +noall +answer www.example.net @10.20.0.53
www.example.net.  300  IN  A  93.184.216.34

Significado: El resolutor interno puede alcanzar upstreams y responder nombres de internet. Si no puede, los clientes pueden “ayudar” cambiando a resolutores públicos.

Decisión: Arregla el egress y la latencia del resolutor interno. Si el DNS interno es lento o inestable, la adopción de DoH multiplica los fallos.

Task 11: Revisar lógica de views/ACL en BIND (named-checkconf)

cr0x@server:~$ sudo named-checkconf -z /etc/bind/named.conf
zone corp.example/IN: loaded serial 2026020401
zone 0.20.10.in-addr.arpa/IN: loaded serial 2026020401
zone example.com/IN: loaded serial 2026011502

Significado: La configuración se parsea y las zonas se cargan. Esto no prueba que la vista correcta coincida con el cliente, pero elimina el “error tipográfico” como causa inmediata.

Decisión: Si las zonas cargan pero los clientes obtienen respuestas equivocadas, valida la coincidencia de view por IP de origen y prueba desde múltiples subredes.

Task 12: Validar reenvío y comportamiento de local-zone en Unbound

cr0x@server:~$ sudo unbound-control status
version: 1.17.1
verbosity: 1
threads: 4
modules: 2 [ validator iterator ]
uptime: 86400 seconds
options: control(yes)

cr0x@server:~$ sudo unbound-control list_local_zones | grep corp.example
corp.example. transparent

Significado: Unbound está activo y tiene una entrada local-zone para el dominio interno. “transparent” significa que resolverá usando local-data si está presente, si no recursará/reencaminará.

Decisión: Si requieres comportamiento estrictamente interno, prefiere “static” o usa local-data explícita y bloquea la fuga hacia la recursión pública.

Task 13: Detectar caché negativo que te perjudica (dig +trace y TTL de SOA)

cr0x@server:~$ dig jira.corp.example @1.1.1.1 +noall +authority
corp.example.  900  IN  SOA  ns1.public-dns.example. hostmaster.public-dns.example. 1 7200 900 1209600 900

Significado: Si un resolutor público devuelve un SOA en la sección de autoridad para NXDOMAIN, el TTL de caché negativo puede causar “sigue fallando incluso después de arreglarlo.”

Decisión: Vacía cachés en cliente/resolutor cuando sea posible, y reduce TTL negativos en zonas públicas donde tengas control.

Task 14: Detectar clientes que evaden DNS revisando logs de resolutor (ejemplo: BIND querylog)

cr0x@server:~$ sudo tail -n 3 /var/log/named/query.log
04-Feb-2026 12:44:11.112 client @0x7f0a3c: query: jira.corp.example IN A +E(0)K (10.20.14.22)
04-Feb-2026 12:44:11.114 client @0x7f0a3c: query: ocsp.corp.example IN A +E(0)K (10.20.14.22)
04-Feb-2026 12:44:11.116 client @0x7f0a3c: query: idp.corp.example IN A +E(0)K (10.20.14.22)

Significado: Puedes confirmar qué clientes realmente consultan el DNS interno. Si un usuario reproduce un fallo y no ves líneas de log correspondientes,
su dispositivo no te está preguntando. Esa es la evidencia clave que necesitas para una conversación de políticas.

Decisión: Trata la evasión como un asunto de cumplimiento de endpoints gestionados, no como “ajuste del servidor DNS”.

La solución: preservar la privacidad y mantener split-horizon

La solución correcta depende de tu modelo de amenazas y de tu tolerancia a la autonomía del endpoint. Pero la solución equivocada siempre es la misma:
fingir que el DNS cifrado no ocurrirá. Ya ocurrió.

Aquí está el objetivo de diseño: los clientes deben usar DNS cifrado hacia resolutores que tú operes o en quienes confíes explícitamente, y deben usar
tu resolutor interno para dominios internos siempre. Puedes lograrlo con políticas, arquitectura o una mezcla de ambas.

Patrón A: Ejecuta tus propios endpoints de DNS cifrado (recomendado)

Si quieres la ganancia de privacidad y gestionas una red seria, deberías ofrecer un servicio de DNS cifrado:
DoT en 853 y/o DoH en 443. Ponlo cerca de los usuarios, anycastéalo si puedes, y registra responsablemente.

Luego configura endpoints (vía MDM/GPO) para usar tu servicio de DNS cifrado, no uno público cualquiera.
Para split-horizon, tu resolutor debe tener la misma lógica de vistas que tu DNS interno existente, o debe reenviar las zonas internas al lugar correcto.

Detalle operacional que importa: necesitas planificación de capacidad y monitorización de latencia. Si tu endpoint de DNS cifrado es más lento que los resolutores públicos,
los clientes y apps “ayudarán” cambiando. No es mala intención; es experiencia de usuario.

Patrón B: Aplicar enrutamiento por dominio (NRPT / resolutores acotados / split DNS)

Si no puedes centralizar completamente la elección del resolutor, aplica al menos el enrutamiento por dominio interno:
*.corp.example, *.svc.cluster.local y otros namespaces internos deben ir a resolutores internos.
Esta es la mínima barrera de seguridad viable para split-horizon.

• Windows: Las reglas NRPT son tus aliadas. Son aburridas, por eso funcionan.
• macOS: resolutores acotados vía perfiles VPN; verifica con scutil --dns.
• Linux: systemd-resolved soporta dominios por enlace; NetworkManager puede empujarlos vía VPN.

Patrón C: Bloquea lo que debas, pero no finjas que está “resuelto”

Bloquear TCP/853 saliente reduce la evasión por DoT. Bloquear DoH es más difícil porque viaja sobre HTTPS.
Puedes bloquear endpoints conocidos de DoH, pero las listas de endpoints cambian y los CDNs se movien.

Si eliges bloquear DoH en la red, hazlo con los ojos abiertos:

• Jugarás al gato y al ratón a menos que uses también gestión de endpoints.
• Podrías romper servicios HTTPS legítimos si vas demasiado amplio.
• Algunos clientes caerán a DNS en texto claro. Eso puede ser aceptable o inaceptable según tu política.

Patrón D: Deja de usar nombres solo-internos que colisionan con DNS público

Una gran parte del dolor proviene de namespaces internos que no están bien separados. Si usas nombres que colisionan con dominios públicos reales,
creas ambigüedad incluso sin DoH. El DNS cifrado simplemente hace que la ambigüedad se note más rápido.

Usa un subdominio que controles públicamente (como corp.example) para uso interno. Evita TLDs internos “atajo” y evita nombres que dependen
de la magia de sufijos de búsqueda para sistemas críticos. Si debes mantener nombres legacy, trátalos como deuda técnica y planifica la migración.

Patrón E: Haz que el DNS interno sea lo suficientemente fiable como para que los usuarios no busquen alternativas

Esta es la verdad poco glamorosa: la gente activa DoH/DoT porque el DNS es un problema de privacidad y porque el DNS del ISP suele ser lento o dudoso.
Si tu DNS interno es lento, inestable o bloqueado por tus propias reglas de firewall, los usuarios lo evitarán.

Fundamentos de fiabilidad:

• Resolutores redundantes en cada sitio/región importante.
• Política de reenvío clara para zonas internas y para la recursión a internet.
• Monitorización: latencia, tasa de SERVFAIL, tasa de NXDOMAIN, QNAMEs principales, estado de upstreams.
• Control estricto de cambios para delegaciones de zona y registros de split-horizon.

Una cita, porque sigue siendo cierta en el mundo DNS. Werner Vogels (idea parafraseada): “Todo falla todo el tiempo; diseña para que los sistemas sigan funcionando de todas formas.”

Segundo chiste corto, y volvemos al trabajo: El DNS split-horizon es mucho como los organigramas corporativos—todos creen saber quién responde, hasta que preguntan a la persona equivocada.

Tres microhistorias corporativas desde las trincheras

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa mediana desplegó un nuevo cliente VPN con “DNS seguro” en la copia de marketing. El equipo de red asumió que eso significaba “usa nuestros servidores DNS,
pero cifrados.” Lo aprobaron rápidamente porque, francamente, estaban cansados de las discusiones sobre DNS en texto claro y querían la mejora.

Dos semanas después, los desarrolladores empezaron a reportar que Git interno sobre HTTPS fallaba intermitentemente con errores de certificado.
El hostname resolvía a veces a una IP interna, a veces a una IP pública perteneciente a un servicio completamente distinto con un nombre similar.
El navegador mostraba un mismatch de certificado, los usuarios a veces hacían clic en continuar (porque claro que lo harían), y ahora tenías un incidente con un lado de malas prácticas.

La causa raíz no fue TLS. No fue el servicio Git. Fue la elección del resolutor. La función “DNS seguro” del cliente VPN habilitó DoH hacia un resolutor de terceros por defecto.
Cuando la VPN estaba activa, el DNS interno aún funcionaba para algunas apps. Pero los navegadores con DoH acabaron siendo coherentes con el resolutor equivocado, y los fallos parecían aleatorios porque distintas apps usaban pilas distintas.

La solución fue dolorosamente simple y políticamente molesta: deshabilitaron DoH de terceros en el cliente VPN y publicaron un endpoint DoH interno.
Luego escribieron una política de una página: “Dispositivos corporativos usan resolutores corporativos. Dispositivos personales en Wi‑Fi de invitados pueden hacer lo que quieran.”
La lección real también fue simple: nunca apruebes “DNS seguro” sin preguntar “¿seguro hacia qué resolutor?”

Microhistoria 2: La optimización que salió mal

Otra organización intentó mejorar el rendimiento para trabajadores remotos empujando un resolutor público como servidor DNS secundario.
El resolutor interno era alcanzable por la VPN, pero la latencia era mayor desde algunas regiones. El pensamiento fue: “Si el interno es lento, el público será rápido, y solo los nombres internos necesitan DNS interno.”
Esa frase contiene la semilla del fallo.

El primer signo de problemas fue un pico en tickets de helpdesk: “Algunas herramientas internas están caídas, pero solo para personas remotas.”
Ingenieros hicieron pruebas rápidas y vieron que los resolutores internos estaban bien. Las apps estaban arriba. La VPN estaba arriba. Sin embargo la resolución de nombres era inconsistente.
Algunos clientes resolvían api.corp.example a una IP interna, otros obtenían NXDOMAIN.

El problema vino del comportamiento de carrera entre resolutores y caché. Algunos clientes consultaron ambos resolutores; el público respondió más rápido con NXDOMAIN,
que se cacheó. Más tarde, incluso cuando el resolutor interno hubiera respondido correctamente, el cliente no preguntó—confió en la caché negativa.
Una “optimización” de rendimiento se volvió una falla de corrección.

La solución fue eliminar resolutores públicos de la configuración VPN y, en su lugar, desplegar resolutores internos regionales (o forwarders) cerca de los usuarios.
También revisaron TTLs de caché negativo donde tenían control. La nueva regla: nunca añadas un “resolutor de respaldo” que no pueda responder tus zonas internas.
Eso no es un respaldo. Es una bifurcación en la realidad.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una gran empresa ya había estandarizado en un namespace interno dedicado (corp.example) y había documentado reglas de reenvío condicional
entre su DNS on‑prem y sus zonas privadas en la nube. También tenían políticas de endpoint que deshabilitaban DoH gestionado por el navegador a menos que apuntara al servicio DoH corporativo.
Era aburrido. También era efectivo.

Durante un incidente de internet más amplio que afectó a la red de un resolutor público popular, ellos sufrieron menos problemas que sus pares.
Sus dispositivos corporativos no dependían de DNS externo para nombres internos, y sus resolutores internos tenían upstreams redundantes para la recursión a internet.
Las apps internas siguieron accesibles. Los usuarios en VPN siguieron trabajando. El helpdesk tuvo un día tranquilo, que es lo más parecido a un trofeo que consigue la gente de ops.

El momento que importó ocurrió en la sala de guerra: alguien sugirió “simplemente decirle a la gente que use este DNS público temporalmente.”
El equipo de DNS se negó—no por terquedad, sino porque ya habían visto esa película y no les gustó el final.
En su lugar, aumentaron la capacidad en los resolutores internos y ajustaron temporalmente reglas de egress que permitían DoT no gestionado.

El postmortem fue corto y casi aburrido: la práctica aburrida (namespaces estables, reenvío documentado, política de endpoints) redujo el radio de impacto.
No todo requiere una solución innovadora. A veces solo necesitas una política que sobreviva a la realidad.

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

1) Síntoma: “La VPN está conectada pero los dominios internos no resuelven”

Causa raíz: DoH del navegador o Private DNS del SO evaden el resolutor provisto por la VPN.

Solución: Imponer política en endpoints: deshabilitar DoH/DoT de terceros o apuntarlo al DNS cifrado corporativo; añadir reglas por dominio para corp.example.

2) Síntoma: “Funciona con ping, falla en el navegador”

Causa raíz: Pilas de resolutor distintas. Herramientas CLI usan DNS del SO; el navegador usa DoH.

Solución: Alinear la política de resolutor. En entornos gestionados, configura DoH del navegador centralmente. En no gestionados, publica guías y haz accesibles apps internas vía DNS público + autenticación si procede.

3) Síntoma: “Algunos usuarios obtienen NXDOMAIN para nombres internos después de un cambio”

Causa raíz: Caché negativo de un resolutor público o un forwarder interno que devuelve NXDOMAIN con TTL largo.

Solución: Vacía cachés donde sea posible; reduce TTLs negativos en zonas que gestionas; deja de enviar nombres internos a resolutores que no puedan responderlos.

4) Síntoma: “Los logs DNS no muestran nada durante pruebas de usuario”

Causa raíz: Evasión por DoH/DoT, resolutores hardcodeados o agente local.

Solución: Identifica la evasión: bloquea 853 saliente donde la política lo permita; aplica configuraciones de DoH; usa comprobaciones de cumplimiento de endpoints para detectar ajustes DNS no conformes.

5) Síntoma: “Nombres internos a veces resuelven a IPs públicas”

Causa raíz: Existe split-horizon pero el cliente usa el horizonte equivocado de forma intermitente (DNS multihomed, comportamiento de carrera).

Solución: Elimina resolutores públicos de configuraciones corporativas; usa dominios acotados/NRPT; asegura que los resolutores internos tengan baja latencia y alta disponibilidad.

6) Síntoma: “El equipo de seguridad ve una caída en la telemetría DNS”

Causa raíz: DoH hacia resolutores de terceros; el filtrado DNS se movió fuera de tu trayectoria.

Solución: Proporciona DoH/DoT corporativo con logging y políticas; aplica uso de resolutores vía MDM/GPO; considera controles a nivel de aplicación que no asuman visibilidad DNS.

7) Síntoma: “Los pods de Kubernetes no resuelven zonas internas pero los nodos sí”

Causa raíz: Configuración DNS de los pods o caché local del nodo reenviando a resolutores externos; faltan stub domains.

Solución: Configura CoreDNS stubDomains/forward para zonas internas; asegura que los resolutores de nodo no usen DoH/DoT público para namespaces internos.

Listas de verificación / plan paso a paso

Paso a paso: estabilizar split-horizon bajo presión DoH/DoT

1. Inventario de namespaces internos. Lista zonas internas y hostnames críticos. Si no puedes listarlos, no puedes protegerlos.
2. Decide la política de resolutor. Elige uno: “solo resolutores corporativos” (gestionado) o “solo aplicación de reglas por dominio” (híbrido).
3. Despliega endpoints de DNS cifrado corporativos. Ofrece DoH/DoT como servicio soportado con HA, monitorización y control de cambios.
4. Configura endpoints vía MDM/GPO. Deshabilita DoH/DoT de terceros; configura resolutores corporativos; aplica NRPT/dominios acotados.
5. Bloquea TCP/853 saliente donde sea apropiado. Permite excepciones para tus propios resolutores. Documenta excepciones explícitamente.
6. Maneja DoH deliberadamente. O bien:
   • Permite DoH corporativo y bloquea DoH de terceros conocidos donde sea factible, o
   • Permite DoH ampliamente pero asegura que los dominios internos se resuelvan vía canales internos (NRPT/resolutores acotados).
7. Haz el DNS interno rápido. Añade forwarders regionales, caching y redundancia. Monitoriza latencia y tasas de fallo.
8. Prueba con clientes reales. Valida en Windows/macOS/Linux y al menos una plataforma móvil si la soportas.
9. Operacionaliza: logging + dashboards. Rastrea volumen de consultas por resolutor, SERVFAIL, NXDOMAIN y dominios principales. Vigila caídas bruscas (evasión).
10. Escribe el runbook. Incluye la Guía de diagnóstico rápido y las 12+ tareas anteriores. El tú del futuro lo agradecerá.

Checklist de revisión de cambios (lógica imprimible)

• ¿Este cambio afectará qué resolutor responde nombres corporativos?
• ¿La solución soporta vistas split-horizon o reenvío condicional?
• ¿Tenemos una respuesta para DoH a nivel de navegador y DoT a nivel de SO?
• ¿Qué pasa durante una falla parcial (comportamiento de fallback)?
• ¿Tenemos métricas de latencia y tasas de error en resolutores corporativos?
• ¿Existe una política explícita para dispositivos no gestionados?

Preguntas frecuentes

1) ¿Es DoH “malo para empresas”?

No. DoH no gestionado es malo para las empresas. DoH gestionado está bien, y a menudo es mejor. El conflicto es sobre el plano de control, no sobre el cifrado.

2) ¿Debería bloquear DoH por todas partes?

Solo si puedes imponer una alternativa que cumpla con privacidad y fiabilidad. Bloquear a ciegas suele causar fallback a DNS en texto claro o empuja a los usuarios a soluciones alternativas.
Mejor: ofrece DoH/DoT corporativo y gestiona la elección del resolutor.

3) ¿Por qué existe el DNS split-horizon si es tan frágil?

Porque es efectivo y sencillo cuando la ruta del resolutor es estable. Se vuelve frágil cuando los endpoints eligen resolutores dinámicamente o evaden por completo el resolutor de la red.
Esa fragilidad es manejable con políticas y enrutamiento por dominio.

4) ¿DNSSEC soluciona esto?

DNSSEC ayuda a verificar la autenticidad de las respuestas DNS. No cifra las consultas y no impide que los endpoints usen el resolutor equivocado.
Puedes (y a menudo debes) usar DNSSEC junto con DoH/DoT, pero no es un sustituto.

5) Si ejecuto DoH interno, ¿sigo necesitando split-horizon?

Si tienes endpoints internos exclusivos, sí. DoH no reemplaza split-horizon; cambia el transporte. Sigues necesitando vistas/reenvíos para que los nombres internos resuelvan correctamente.

6) ¿Cuál es la solución mínima más segura si no puedo hacer un gran proyecto?

Aplica enrutamiento por dominio para namespaces internos (NRPT/dominios acotados) y elimina resolutores públicos de configuraciones gestionadas.
Luego bloquea TCP/853 saliente para reducir DoT no gestionado.

7) ¿Cómo manejo dispositivos móviles?

Trátalos como una clase separada. Si están gestionados, empuja un perfil DNS y restringe settings de Private DNS. Si son BYOD no gestionados, no asumas que split-horizon funcionará.
Ofrece apps internas vía DNS público con autenticación fuerte, o usa un contenedor/perfil gestionado.

8) ¿Por qué añadir un servidor DNS público “de respaldo” causa interrupciones?

Porque no es respaldo para zonas internas. Algunos clientes lo usarán primero por latencia, métricas de interfaz o lógica de reintento. Luego la caché negativa puede hacer que el fallo sea persistente.
Si un resolutor no puede responder tus zonas internas, no es un secundario seguro.

9) ¿Puedo confiar en sufijos de búsqueda en lugar de nombres totalmente calificados?

Para conveniencia, sí. Para fiabilidad crítica, no. Los sufijos de búsqueda multiplican la ambigüedad y crean rutas de fuga confusas cuando los clientes usan resolutores públicos.
Usa FQDNs para servicios críticos y mantén namespaces internos sin ambigüedad.

10) ¿Cuál es la mejor métrica para detectar evasión por DoH?

Una caída brusca en el volumen de consultas a tus resolutores internos, especialmente desde redes donde el conteo de endpoints no cambió.
Combínala con observaciones de egress (TCP/853, endpoints DoH conocidos) y reportes de cumplimiento de endpoints.

Conclusión: siguientes pasos que puedes ejecutar esta semana

DoH y DoT no son una moda, y no son tu enemigo. Son la dirección por defecto de la industria: más cifrado, más autonomía de endpoints, menos suposiciones sobre la red.
El DNS split-horizon sigue funcionando—si dejas de asumir que los clientes te preguntarán por favor.

Pasos prácticos:

1. Ejecuta la Guía de diagnóstico rápido contra un usuario real que falle y documenta qué resolutor respondió.
2. Elimina “DNS público secundario” de perfiles VPN y configuraciones de endpoints gestionados.
3. Implementa enrutamiento por dominio para namespaces internos (NRPT/resolutores acotados) como línea base.
4. Planifica y despliega endpoints DoH/DoT corporativos, y empújalos vía MDM/GPO.
5. Monitorea latencia y tasas de error de resolutores; trata el DNS como infraestructura de producción, porque lo es.

La privacidad es una victoria. La fiabilidad es innegociable. Puedes tener ambas—pero solo si diseñas para el DNS cifrado en lugar de esperar que no note tu split-horizon.