DNS sobre HTTPS y DNS sobre TLS: privacidad sin romper las redes corporativas

Lo que realmente cambias al habilitar DoH/DoT

El DNS clásico es mayormente UDP/53 (más TCP/53 para respuestas grandes, DNSSEC y transferencias de zona). Es rápido, omnipresente,
y terriblemente observable. La observabilidad va en ambas direcciones: tu ISP puede ver a dónde vas, y también cualquiera
que esté en el camino con una captura de paquetes y mala intención.

DoT (DNS over TLS) envuelve DNS en TLS, normalmente en el puerto 853. DoH (DNS over HTTPS) envuelve DNS en HTTP/2 o HTTP/3 sobre TLS,
normalmente en el puerto 443. Ambos cifran la pregunta y la respuesta. Ambos protegen contra observadores pasivos en la red.
Ninguno convierte mágicamente al DNS en “seguro” en el sentido de “correcto”: eso sigue siendo una combinación de integridad del resolutor,
validación DNSSEC y no ejecutar toda tu infraestructura sobre corazonadas.

En redes corporativas, el DNS es más que resolución de nombres:

• Pegamento de identidad: descubrimiento de servicios internos, AD, Kerberos y flujos SSO.
• Punto de política: listas de bloqueo, sinkholes, filtrado por categoría y controles de pérdida de datos.
• Telemetría: los registros DNS son un sistema de alerta temprana barato.
• Segmentación: el split-horizon DNS es cómo mantienes los nombres internos como internos.

Cifra el DNS sin un plan y no solo “aumentas la privacidad”. Te saltas tus propios controles, silenciosamente.
Entonces la primera vez que alguien no puede alcanzar un host interno porque su portátil está preguntando a un resolutor público,
escucharás una frase que debería ser ilegal en industrias reguladas: “Pero funciona en mi Wi‑Fi doméstico.”

Hechos e historia que importan en operaciones

• El DNS se lanzó en 1983 (era RFC 882/883). Se diseñó para una red más amable donde “cifrado en todas partes” no era la norma.
• DNSSEC comenzó a finales de los 90 y maduró durante los 2000. Protege autenticidad, no privacidad. La gente confunde esto constantemente.
• La firma de la zona raíz se activó en 2010, haciendo la validación DNSSEC significativa de extremo a extremo para muchos dominios, si tu resolutor realmente valida.
• DoT se estandarizó en 2016 (RFC 7858). Es claro, directo y fácil de notar en la red: TLS al puerto 853 suele destacar.
• DoH se estandarizó en 2018 (RFC 8484). Se oculta dentro del HTTPS normal, que es tanto el objetivo como la molestia operativa.
• Firefox habilitó DoH por defecto en algunas regiones alrededor de 2019–2020 mediante el despliegue “TRR”. Las empresas lo descubrieron de forma divertida: recibiendo tickets.
• EDNS0 expandió el DNS para que las respuestas puedan superar los 512 bytes sobre UDP, reduciendo el fallback a TCP—genial para rendimiento, problemático para middleboxes que nunca aprendieron.
• La minimización de QNAME se volvió buena práctica para reducir fuga de datos a servidores autoritativos. Es ayuda para la privacidad incluso sin DoH/DoT, pero depende del comportamiento del resolutor.
• Encrypted ClientHello (ECH) es la próxima frontera: puede ocultar el SNI. Cuando ECH sea común, “bloquear DoH por SNI” quedará obsoleto rápidamente.

La industria no se despertó una mañana y decidió cifrar el DNS por diversión. Fue una reacción al monitoreo generalizado,
la manipulación de DNS a nivel ISP y al hecho de que el DNS sin cifrar es un faro de seguimiento con excelente disponibilidad.

Modelo de amenazas: a quién proteges y de qué

“Privacidad” no es una característica; es una decisión sobre adversarios. Para redes corporativas, normalmente tienes tres:

1) Observadores pasivos en redes no confiables

Wi‑Fi de cafetería, redes de hoteles, aeropuertos. DoH/DoT ayuda mucho aquí. Si tienes trabajadores remotos y no hay VPN siempre activa,
el DNS cifrado es uno de los pocos controles que aún funciona cuando la red es hostil.

2) Manipulación en el camino

Portales cautivos, malware inyectando NXDOMAINs, “ayuda” del ISP que redirige errores tipográficos a páginas con anuncios. TLS elimina la mayor parte de esto.
DNSSEC también ayuda, pero la implementación de DNSSEC es desigual y muchos stubs no validan; los resolutores lo hacen.

3) Tus propios controles empresariales (sí, aquí eres un adversario)

Registras DNS para detección. Bloqueas dominios maliciosos. Enrutas zonas internas a servidores internos.
El DNS cifrado puede evitar esos controles a menos que proveas un resolutor cifrado sancionado y obligues a los clientes a usarlo.

El objetivo real de la empresa no es “desactivar DoH”. Es “hacer que el DNS cifrado pase por nuestro resolutor donde corresponde.”
Bloquear es un instrumento contundente. A veces necesario, rara vez suficiente.

Una idea parafraseada que ha perseguido a operaciones durante décadas: idea parafraseada: “La esperanza no es una estrategia.” — atribuida a Edsger W. Dijkstra (paráfrasis, no literal).
Si “esperas” que los clientes no usen endpoints DoH públicos, ya estás detrás.

DoH vs DoT: diferencias prácticas (no marketing)

Transporte y visibilidad

• DoT: TLS en el puerto 853. Fácil de identificar y aplicar políticas en el firewall. También fácil de romper accidentalmente si las reglas de salida son estrictas.
• DoH: HTTPS en el puerto 443. Más difícil de distinguir del tráfico web ordinario sin inspección TLS, controles en el endpoint o listas de endpoints conocidas.

Puntos de control operativos

Si puedes administrar endpoints (MDM/GPO), DoH es controlable: puedes fijar resolutores del sistema, configurar políticas de “DNS seguro”,
y hacer pin a tu resolutor. Si no puedes administrar endpoints, DoH se convierte en “una función del navegador que ahora es un problema de red.”

Características de rendimiento

DoH puede aprovechar conexiones HTTPS existentes, reutilizar TCP/TLS y comportarse bien sobre HTTP/2. En algunos entornos eso es más rápido,
especialmente en redes con pérdidas. En otros, añade sobrecarga y complejidad de proxy. DoT es más simple: una sesión TLS a un resolutor,
muchas consultas.

Middleboxes y proxies

Los proxies corporativos a menudo entienden HTTP; no entienden “semántica DNS dentro de HTTPS.” Un proxy puede reenviar DoH
alegremente mientras tu equipo de seguridad pierde visibilidad DNS, lo que es como dejar la puerta principal cerrada pero quitar las paredes.

Chiste #1: El DNS es el único sistema donde puedes estar caído, arriba y “funcionando según el diseño” al mismo tiempo, dependiendo de quién pregunte.

Cómo falla el DNS corporativo: split-horizon, proxies y middleboxes “útiles”

Split-horizon DNS y por qué DoH/DoT puede evadirlo

Split-horizon significa que los clientes internos obtienen respuestas internas para nombres internos, y los clientes externos obtienen respuestas externas.
Se usa para:

• Nombres solo internos (p. ej., git.corp)
• Respuestas diferentes según la ubicación (dentro vs fuera)
• Seguridad: no filtrar la topología interna

Si un portátil usa DoH público (por ejemplo hacia un resolutor en Internet) mientras está en VPN—o peor, mientras está dentro de tu oficina—puede:

• No resolver nombres internos (incidente de disponibilidad)
• Resolver a direcciones públicas (riesgo de exfiltración de datos, enrutamiento incorrecto)
• Filtrar patrones de consultas internas a un tercero externo (problema de privacidad y confidencialidad)

Controles de seguridad basados en DNS y lo que hace el DNS cifrado con ellos

Si bloqueas dominios maliciosos en el resolutor, y los clientes evitan ese resolutor, simplemente cambias “prevenir” por “detectar más tarde”
(si siquiera puedes). Y muchas organizaciones no pueden. Ejecutan reglas SIEM que asumen que existen registros DNS.

El cifrado no es el enemigo. El cifrado no gestionado sí lo es.

Middleboxes que manejan mal características modernas del DNS

Incluso con DNS plano, los middleboxes pueden romper cosas:
EDNS0, DNSSEC, UDP fragmentado, fallback a TCP. Con DoT/DoH, los modos de fallo cambian:
cajas de inspección TLS que bloquean SNI desconocido, proxies HTTP que caducan conexiones de larga duración,
y NATs de salida que rotan puertos tan rápido que hacen que los resolutores parezcan inestables.

Arquitectura recomendada para empresas: resolutores privados + políticas + cifrado controlado

La estrella del norte

Provee un servicio de resolutor empresarial que soporte:

• Zonas internas (autoritativas o reenviadas)
• Recursión validada (validación DNSSEC activada)
• Política de amenazas (RPZ o equivalente), con control de cambios
• Endpoints de escucha cifrados (DoT y/o DoH) para clientes
• Registros que respeten la privacidad y con retención acotada
• Alta disponibilidad (anycast o al menos sitios redundantes)

Dónde terminar el cifrado

Termina DoH/DoT en tus resolutores, no en una caja perimetral aleatoria que no tiene contexto DNS.
Mantén el resolutor cerca (en términos de red) de los clientes cuando sea posible; la latencia importa.
Entonces tu resolutor puede comunicarse con resolutores ascendentes o servidores autoritativos usando:

• DNS plano (aceptable en redes controladas, pero menos privado)
• DoT hacia upstream (buen compromiso)
• DNS sobre QUIC (emergente; trátalo como “laboratorio de pruebas” a menos que tengas confianza)

Estrategia de control en el cliente

• Endpoints gestionados: configura DoH/DoT a nivel del SO hacia tus resolutores; bloquea la opción “DNS seguro” del navegador hacia el resolutor del sistema o endpoint empresarial.
• No gestionados / BYOD: puedes necesitar controles de red (filtrado de egress, políticas de portal cautivo, NAC) y un documento “si quieres acceso, usa nuestro DNS.”

No confundas “bloquear DoH público” con “resolver el problema”

Bloquear endpoints DoH conocidos por IP o SNI es un juego del gato y el ratón. Puede reducir el riesgo rápidamente, pero no es sostenible
a medida que Internet avanza hacia ECH y a medida que los proveedores alojan DoH detrás de CDNs. La jugada a largo plazo es la política en endpoints y
ofrecer una ruta mejor: tu propio resolutor seguro con rendimiento comparable.

Chiste #2: La forma más fácil de encontrar una dependencia no documentada es habilitar DoH y observar qué aplicaciones internas empiezan a gritar inmediatamente.

Tres microhistorias corporativas desde el terreno

Microhistoria 1: El incidente causado por una suposición errónea

Una empresa mediana lanzó un memo de “mejora de privacidad”: “Habiliten DNS Seguro en su navegador.” Sonaba inofensivo.
Al equipo de seguridad le gustó la idea. Al helpdesk le gustó porque parecía menos problemas de Wi‑Fi.
Nadie preguntó qué resolutor se usaría.

En una semana, aplicaciones web internas empezaron a fallar para trabajadores remotos en VPN. La falla fue curiosamente selectiva:
algunos usuarios podían alcanzar intranet.corp, otros recibían timeouts, y algunos fueron redirigidos a una página pública.
El equipo de red revisó rutas split-tunnel y la configuración DNS de la VPN. Todo parecía correcto.

La suposición errónea fue simple: “Si estás en VPN, debes estar usando DNS corporativo.” No es cierto.
Los navegadores estaban enviando consultas DoH a resolutores públicos sobre el túnel VPN (o a veces fuera de él, según el enrutamiento del cliente),
evitando las vistas DNS internas. Nombres internos no eran resolubles públicamente, así que fallaban. Algunos nombres que existían externamente
resolvían a servicios públicos, lo cual es una forma más interesante de fallo.

La solución no fue “desactivar DoH.” La solución fue proveer un endpoint DoH corporativo, configurar navegadores gestionados para usarlo,
y aplicar en endpoints que “DNS seguro” debe usar resolutores empresariales. Entonces las zonas internas volvieron a ser consistentes,
y el equipo de seguridad recuperó su telemetría DNS—en el resolutor, no en la red.

Microhistoria 2: La optimización que salió mal

Una gran empresa decidió reducir latencia DNS desplegando una capa de caché local en routers de sucursales.
La idea: cachear agresivamente, reducir tráfico upstream, acelerar cargas de páginas. Alguien convirtió el honor de TTL en una sugerencia.
De repente, dominios comunes de SaaS quedaron cacheados “lo bastante para siempre.”

Después, un proveedor SaaS mayor cambió algunos endpoints durante un incidente en su lado. La empresa seguía respondiendo con registros A/AAAA obsoletos.
Los usuarios vieron fallos intermitentes según la sucursal. Los registros del resolutor parecían limpios.
Las capturas de paquetes parecían limpias. Todo era “correcto” excepto la realidad.

El problema empeoró con DoH: los navegadores con pin a un resolutor DoH público obtenían respuestas frescas, mientras los dispositivos gestionados
que usaban la caché de sucursal tenían respuestas obsoletas. Dos realidades, una compañía. Cada hilo de depuración empezaba con, “A mí me funciona.”
Esa frase debería considerarse una sustancia peligrosa.

La solución fue aburrida: respetar TTLs, mantener tamaños de caché sensatos y dejar de intentar ser más listo que los operadores autoritativos.
Añadir monitorización en el resolutor para ratios de hits anormalmente altos en dominios que cambian rápido. El rendimiento importa, pero la corrección es una característica.

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

Una organización financiera tenía una regla: cada cambio DNS debía pasar por un par de resolutores de prueba, con un grupo canario de clientes,
y con un plan de rollback aprobado de antemano. Nadie lo amaba. Parecía papeleo para paquetes.

Introdujeron DoT para endpoints gestionados, terminando en sus resolutores internos, y mantuvieron DNS plano como fallback para dispositivos legados.
Durante el despliegue, un problema de conectividad upstream causó fallos esporádicos de handshake TLS desde un centro de datos hacia los listeners DoT.
El grupo canario lo vio primero—radio de blast pequeño, alarmas sonoras.

Como tenían instrumentación sobre latencia del resolutor, tasas de error de handshake TLS y distribución de clientes por sitio, aislaron rápidamente
el problema a una actualización de política de firewall que afectó sesiones TLS de larga duración. Revertieron esa política específica,
no todo el despliegue DoT. Los usuarios apenas lo notaron.

No pasó nada heroico. Por eso funcionó. Cuando haces cambios DNS aburridos, puedes dormir.

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

La forma más rápida de dejar de discutir sobre DoH/DoT es recopilar evidencia. A continuación hay tareas probadas en campo que puedes ejecutar en hosts Linux
(o en contenedores de troubleshooting) y qué hacer con los resultados. Ajusta nombres de host e IPs a tu entorno.

Task 1: Confirmar qué resolutor está usando realmente el host

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 10.20.0.54
        DNS Domain: corp.example

Significado: El resolutor del sistema apunta a 10.20.0.53/10.20.0.54. Si los usuarios dicen “DoH rompió el DNS”, pero el SO apunta a resolutores corporativos, el bypass probablemente está en una app (navegador) o en un cliente VPN.

Decisión: Si los servidores DNS son públicos o inesperados, arregla primero la asignación DNS por DHCP/VPN. Si son correctos, investiga DoH a nivel de aplicación.

Task 2: Observar tráfico DNS en vivo para ver si UDP/53 se está usando

cr0x@server:~$ sudo tcpdump -ni any '(udp port 53 or tcp port 53 or tcp port 853)' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
12:01:11.120345 eth0  Out IP 10.20.10.15.38422 > 10.20.0.53.53: 1234+ A? intranet.corp.example. (38)
12:01:11.121004 eth0  In  IP 10.20.0.53.53 > 10.20.10.15.38422: 1234* 1/0/0 A 10.50.1.20 (54)
10 packets captured

Significado: Está ocurriendo DNS plano. Si no ves nada en 53/853 mientras las búsquedas funcionan, DoH (443) probablemente esté en juego.

Decisión: Si debes hacer cumplir DNS corporativo, pasa a política en endpoints/navegador o implementa detección de patrones DoH en la red.

Task 3: Probar resolución contra el resolutor corporativo explícitamente

cr0x@server:~$ dig @10.20.0.53 intranet.corp.example A +noall +answer
intranet.corp.example. 60 IN A 10.50.1.20

Significado: El resolutor corporativo puede resolver el nombre interno. Si los usuarios no pueden, el problema es la ruta del cliente, no los datos del servidor.

Decisión: Si esto funciona pero las apps de usuario fallan, persigue configuraciones split-DNS, bypass de DoH o diferencias en el dominio de búsqueda.

Task 4: Comparar con un resolutor público para detectar fuga de split-horizon

cr0x@server:~$ dig @1.1.1.1 intranet.corp.example A +noall +comments +answer
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22110

Significado: El resolutor público no conoce el nombre interno. Si los endpoints usan DoH público, los nombres internos fallarán.

Decisión: Provee DoH/DoT corporativo para clientes gestionados; bloquea o restringe DNS cifrado público donde la política lo requiera.

Task 5: Verificar si systemd-resolved está configurado para DoT

cr0x@server:~$ grep -R 'DNSOverTLS\|DNSSEC\|DNS=' /etc/systemd/resolved.conf /etc/systemd/resolved.conf.d 2>/dev/null
/etc/systemd/resolved.conf:DNS=10.20.0.53 10.20.0.54
/etc/systemd/resolved.conf:DNSOverTLS=opportunistic
/etc/systemd/resolved.conf:DNSSEC=allow-downgrade

Significado: DoT oportunista significa que intentará DoT cuando esté soportado, pero hará fallback. Eso es más seguro para compatibilidad, más débil para “debe cifrar”.

Decisión: Para redes gestionadas corporativas, prefiere “strict” solo cuando tus resolutores sean consistentemente accesibles y monitoreados.

Task 6: Verificar conectividad DoT al endpoint de tu resolutor

cr0x@server:~$ openssl s_client -connect dns.corp.example:853 -servername dns.corp.example -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = dns.corp.example
Verification: OK

Significado: El handshake TLS tiene éxito, el certificado verifica. Si falla, los clientes DoT harán fallback (opportunistic) o fallarán (strict).

Decisión: Si la verificación falla, arregla certificados/SANs/chain. Si la conexión falla, corrige firewall/NAT/MTU.

Task 7: Confirmar que tu resolutor escucha en 853 y/o 443

cr0x@server:~$ sudo ss -lntp | egrep '(:53|:853|:443)\s'
LISTEN 0      4096      0.0.0.0:53        0.0.0.0:*    users:(("unbound",pid=1442,fd=6))
LISTEN 0      4096      0.0.0.0:853       0.0.0.0:*    users:(("unbound",pid=1442,fd=8))
LISTEN 0      4096      0.0.0.0:443       0.0.0.0:*    users:(("caddy",pid=1310,fd=5))

Significado: Unbound en 53/853, y un servidor web en 443 (a menudo usado como frontend DoH). Si 853 no está escuchando, DoT no funcionará.

Decisión: Asegúrate de que los listeners coincidan con tu plan de despliegue; no publiques “DoT disponible” si no lo está.

Task 8: Medir latencia del resolutor y detectar síntomas de pérdida de paquetes

cr0x@server:~$ dig @10.20.0.53 www.example.com A +stats +tries=1 +timeout=1
;; Query time: 8 msec
;; SERVER: 10.20.0.53#53(10.20.0.53) (UDP)
;; WHEN: Tue Dec 31 12:05:22 UTC 2025
;; MSG SIZE  rcvd: 56

Significado: 8ms es saludable para un resolutor cercano. Si ves timeouts o picos de 800ms+, tienes problemas de ruta de red, sobrecarga o lentitud upstream.

Decisión: Si los picos de latencia se correlacionan con despliegues DoT/DoH, revisa overhead de handshake TLS, reutilización de conexiones y capacidad de la tabla de estado del firewall.

Task 9: Inspeccionar si los clientes usan endpoints DoH públicos (perspectiva host Linux)

cr0x@server:~$ sudo ss -tnp | awk '$4 ~ /:443$/ {print $5}' | head
34.120.54.55:443
104.16.249.249:443
1.1.1.1:443

Significado: Aparecen conexiones a rangos de CDN comunes y IPs de resolutores conocidos. Esto no es prueba de DoH (443 es todo), pero es una pista.

Decisión: Si ves conexiones largas repetidas a proveedores DoH conocidos durante fallos DNS, prueba configuraciones de DNS seguro del navegador y políticas empresariales.

Task 10: Comprobar comportamiento del stub resolver local y caché

cr0x@server:~$ resolvectl statistics
Transactions: 18234
Cache Hits:  12011
Cache Misses: 6223
DNSSEC Verdicts: secure=0 insecure=0 bogus=0 indeterminate=0

Significado: Altos hits de caché son normales. Los veredictos DNSSEC en cero sugieren que el stub no está validando, o la validación está desactivada upstream.

Decisión: Decide dónde reside la validación DNSSEC (usualmente en resolutores recursivos empresariales). Verifícala ahí, no necesariamente en cada endpoint.

Task 11: Validar DNSSEC en el resolutor corporativo (desde un cliente)

cr0x@server:~$ dig @10.20.0.53 dnssec-failed.org A +dnssec +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1512

Significado: Un resolutor que valida debería devolver SERVFAIL para zonas DNSSEC deliberadamente rotas.

Decisión: Si obtienes un registro A normal, tu resolutor no está validando DNSSEC. Decide si eso es aceptable; para muchas empresas, no debería serlo.

Task 12: Identificar si un proxy está interfiriendo con DoH (común en redes corporativas)

cr0x@server:~$ curl -I --connect-timeout 3 https://dns.corp.example/dns-query
HTTP/2 405
server: caddy
date: Tue, 31 Dec 2025 12:07:11 GMT

Significado: Alcanzaste el endpoint DoH. Un 405 está bien para un desajuste GET/HEAD según implementación; lo importante es que TLS+HTTP funciona end-to-end.

Decisión: Si esto agota el tiempo o devuelve una página de bloqueo de proxy, arregla allowlists de proxy o reglas de bypass para el endpoint DoH corporativo.

Task 13: Verificar política de egress del firewall para DoT

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain output {
    type filter hook output priority 0; policy accept;
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
    tcp dport { 53, 853, 443 } accept
  }
}

Significado: La cadena forward permite 853. Si 853 no está permitido desde VLANs de cliente hacia VIPs de resolutor, DoT fallará.

Decisión: Permite 853 solo hacia tus resolutores, no hacia todo Internet, a menos que disfrutes bypasses sorpresa.

Task 14: En el resolutor, comprobar saturación (CPU, sockets, archivos abiertos)

cr0x@server:~$ sudo pidstat -p $(pgrep -x unbound) 1 3
Linux 6.8.0 (dns01) 	12/31/2025 	_x86_64_	(8 CPU)

12:08:01 PM   UID       PID    %usr %system  %CPU  Command
12:08:02 PM  unbound   1442    38.00   6.00 44.00  unbound
12:08:03 PM  unbound   1442    41.00   7.00 48.00  unbound

Significado: Si tu resolutor consume 50% de CPU sostenido, estás bien hasta que no lo estés. Picos repentinos durante el despliegue DoH pueden indicar overhead de terminación TLS o inundación de consultas.

Decisión: Escala horizontalmente (más instancias de resolutor), habilita reutilización de conexiones en frontends DoH, y rate-limit a clientes abusivos en lugar de castigar a todos.

Task 15: Confirmar que los registros muestran la subred/origen del cliente que esperas (NAT oculta pecados)

cr0x@server:~$ sudo tail -n 5 /var/log/unbound/unbound.log
[1735646910] unbound[1442:0] info: 10.20.10.15 www.example.com. A IN
[1735646911] unbound[1442:0] info: 10.20.10.15 intranet.corp.example. A IN
[1735646912] unbound[1442:0] info: 10.20.10.15 api.vendor.example. AAAA IN

Significado: Puedes atribuir consultas a IPs de clientes. Si todo viene de un gateway NAT, tu valor forense baja.

Decisión: Evita NAT entre clientes y resolutores cuando sea posible. Si es inevitable, incluye identificadores de cliente en la capa DoH (con cuidado) o usa resolutores por sitio.

Guía de diagnóstico rápido

Cuando DoH/DoT está involucrado, la memoria muscular habitual de depuración DNS falla porque ya no puedes ver consultas en UDP/53.
Esta guía está diseñada para la realidad on-call: encontrar el cuello de botella en minutos, no escribiendo una novela en el canal de incidentes.

Primero: determina si el cliente está evadiendo el DNS corporativo

• Revisa la configuración del resolutor del SO (resolvectl status o equivalente del SO).
• Revisa la política de DNS seguro del navegador (gestionado vs activado por el usuario).
• Busca ausencia de consultas UDP/53 mientras la navegación “resuelve” (indicio de DoH).

Por qué: Si el cliente no está usando tu resolutor, nada de lo demás importa.

Segundo: confirma accesibilidad y salud TLS al endpoint cifrado corporativo

• Para DoT: openssl s_client -connect ...:853 (verificar cert, tiempo de handshake).
• Para DoH: curl -I https://... (respuesta HTTP, interferencia de proxy).

Por qué: La mayoría de fallos enterprise de DoT no son “bugs DNS.” Son problemas de TLS/cert/política de egress.

Tercero: valida corrección del resolutor y comportamiento upstream

• dig @resolver internal.name y dig @resolver external.name
• Revisa picos de SERVFAIL; prueba DNSSEC en un dominio intencionalmente roto
• Mira CPU del resolutor y límites de descriptores de archivos

Por qué: Si el resolutor está sobrecargado o mal configurado, el cifrado solo hace que el fallo sea más difícil de ver.

Cuarto: aislar problemas de ruta de red (MTU, tablas de estado, proxies)

• Los problemas de MTU aparecen como fallos de handshake TLS o bloqueos intermitentes.
• El agotamiento de tablas de estado del firewall aparece como fallos aleatorios en muchos clientes.
• Los timeouts de proxy aparecen como solicitudes DoH que fallan solo en la red interna.

Errores comunes (y cómo fallan en producción)

1) Síntoma: Nombres internos fallan solo en navegadores; herramientas del SO funcionan

Causa raíz: DoH del navegador habilitado hacia un resolutor público; el SO sigue usando DNS corporativo.

Solución: Aplicar política de navegador: “usar resolutor del sistema” o “usar endpoint DoH corporativo.” Provee un servicio DoH corporativo que funcione fuera y dentro de la VPN.

2) Síntoma: Fallos DNS aleatorios tras habilitar DoT “strict”

Causa raíz: Desajuste de certificados (SAN incorrecto), cadena intermedia faltante, o firewall bloqueando 853 de forma intermitente.

Solución: Arregla PKI primero. Luego permite 853 solo a tus resolutores. Añade monitorización en tasa de éxito de handshakes TLS.

3) Síntoma: Algunos sitios cargan lento; latencia del resolutor parece bien

Causa raíz: DoH vía proxy añade bloqueo head-of-line o churn de conexiones; reutilización HTTP/2 no funciona; el proxy inspecciona y retrasa.

Solución: Evita el proxy para el endpoint DoH corporativo. Asegura keepalive y HTTP/2 habilitados. Considera DoT si los proxies son inevitables.

4) Síntoma: El equipo de seguridad pierde visibilidad DNS de la noche a la mañana

Causa raíz: Clientes cambiaron silenciosamente a DoH público (actualización del navegador, función del SO), evitando resolutores y registros corporativos.

Solución: Gestión de endpoints: deshabilitar DoH público, configurar DoH/DoT empresarial. Red: restringir egress a endpoints DoH conocidos si es necesario, pero trátalo como temporal.

5) Síntoma: Respuestas split-horizon inconsistentes entre subredes

Causa raíz: Múltiples stacks de resolutor (caches de sucursal, resolutores centrales, DoH público) con reglas de reenvío y caches diferentes.

Solución: Consolidar políticas: un servicio de resolutor con vistas consistentes; mantener resolutores de sucursal pero gestionados centralmente; dejar de lado la “caché creativa”.

6) Síntoma: Alta tasa de SERVFAIL solo a dominios externos

Causa raíz: Fallos de validación DNSSEC por dominios upstream rotos, hora incorrecta o UDP fragmentado/TCP fallback bloqueado.

Solución: Asegura que TCP/53 esté permitido saliente desde resolutores. Revisa NTP en resolutores. Usa parámetros DNSSEC sensatos; no desactives validación globalmente por un dominio roto.

7) Síntoma: DoH funciona fuera de la red, falla en LAN corporativa

Causa raíz: Inspección SSL o proxy bloquea el endpoint DoH, o un portal cautivo intercepta 443 en algunos segmentos.

Solución: Allowlist/bypass para el endpoint DoH corporativo frente a la inspección. Si debes inspeccionar, termina cuidadosamente y preserva semántica—o acepta que estás rompiendo privacidad.

8) Síntoma: CPU del resolutor se dispara tras habilitar DoH

Causa raíz: Overhead de terminación TLS movido al resolutor sin planificación de capacidad; o el endpoint DoH no reutiliza conexiones y abre demasiadas sesiones.

Solución: Desplaza TLS a un frontend dedicado con keepalive; escala el pool de resolutores; implementa límites y cuotas por cliente.

Listas de verificación / plan paso a paso

Paso 1: Decide la postura de la empresa (ponla por escrito)

• ¿Vas a proporcionar un servicio DNS cifrado corporativo? (Deberías.)
• ¿Requieres cifrado fuera de la red? ¿Dentro de la red?
• ¿Qué registros retienes y por qué? ¿Quién puede acceder a ellos?
• ¿Qué zonas internas nunca deben filtrarse?

Paso 2: Construye el servicio de resolutor como una dependencia de nivel 0

• Resolutores redundantes por sitio o región.
• Reglas de reenvío y split-horizon consistentes.
• Validación DNSSEC activada en resolutores recursivos.
• RPZ/feeds de amenazas con control de cambios y rollback.
• Pruebas de capacidad: QPS, handshakes TLS, conteos de conexiones.

Paso 3: Añade endpoints DoT y/o DoH—intencionalmente

• DoT en 853 para clientes gestionados, más fácil de razonar.
• DoH en 443 para redes hostiles y entornos con proxies, pero conviértelo en un servicio de primera clase (monitórealo).
• Certificados de una CA interna/pública según corresponda; incluye SANs correctos.
• Haz que los endpoints sean accesibles desde la VPN y desde Internet público si tu fuerza laboral remota lo necesita (consideraciones DDoS).

Paso 4: Aplicar política en endpoints

• DNS a nivel de SO: establece resolutores empresariales.
• Nivel de navegador: fuerza “DNS seguro” al endpoint corporativo o al resolutor del sistema.
• Evita la anulación por parte del usuario donde tu modelo de riesgo lo demande (entornos regulados).

Paso 5: Controles de red (úsalos con moderación, pero estar listos)

• Permite DoT (853) solo hacia resolutores corporativos; bloquea hacia Internet si la política lo exige.
• Para DoH, prefiere controles en endpoints; usa detección en red como respaldo.
• Documenta excepciones (Wi‑Fi de invitados, BYOD, laboratorios).

Paso 6: Monitorización que detecte los fallos reales

• Resolutor: QPS, latencia, tasas SERVFAIL/NXDOMAIN, ratio de hits de caché, RTT upstream.
• DoT: tasa de error de handshake TLS, conteo de sesiones, alarmas de expiración de certificados.
• DoH: distribución de estados HTTP, latencia p95, códigos de error de proxy, métricas de reutilización de conexiones.
• Experiencia cliente: consultas sintéticas para nombres internos y externos desde cada sitio.

Paso 7: Plan de despliegue que respete el radio de blast

• Grupo canario (TI + algunos usuarios avanzados).
• Expansión gradual por sitio/región.
• Rollback: pasos claros para revertir políticas de endpoint y enrutamiento.
• Runbook de incidentes: incluir “¿el cliente está evadiendo el resolutor?” como primera comprobación.

Preguntas frecuentes

1) ¿Deben las empresas permitir DoH?

Sí, pero no como “cada uno usa el resolutor que prefiera su navegador.” Provee un endpoint DoH corporativo y gestiona clientes para que lo usen.
Si no puedes gestionar clientes, puede que necesites restringir DoH público para preservar split-horizon y controles de seguridad.

2) ¿Es DoT más fácil que DoH para redes corporativas?

Por lo general. El puerto 853 es explícito, más fácil de filtrar y evita rarezas de proxy. DoH es mejor cuando debes atravesar redes
que bloquean 853, pero es más difícil de controlar a nivel de red.

3) ¿El DNS cifrado detendrá el malware?

No. Evita que observadores pasivos lean el tráfico DNS. El malware aún puede resolver nombres—posiblemente de forma más fiable.
Tu mitigación es la política en el resolutor (cuando los clientes lo usan), seguridad en endpoints y controles de egress.

4) Si usamos DNSSEC, ¿aún necesitamos DoH/DoT?

DNSSEC y DoH/DoT resuelven problemas diferentes. DNSSEC autentica respuestas; DoH/DoT oculta preguntas y respuestas de observadores.
Quieres validación DNSSEC en tus resolutores tanto si despliegas cifrado como si no.

5) ¿Podemos bloquear DoH público por SNI?

A veces, hoy. Menos fiable mañana debido a ECH y patrones de fronting en CDNs. Trata el bloqueo por SNI como una medida de contención a corto plazo,
no como una estrategia para mantener años.

6) ¿DoH no romperá nuestros registros DNS?

Rompe el registro on-path, en el que no deberías confiar de todos modos. No rompe el registro del resolutor si los clientes usan tu resolutor.
Mueve la visibilidad a la capa del resolutor y limita la retención a necesidades legítimas de seguridad/ops.

7) ¿Y la Wi‑Fi de invitados y BYOD?

Decide qué optimizas. Si a los invitados no se les permite acceder a recursos internos, puedes dejar que usen DNS/DoH públicos.
Si necesitan acceso interno, trátalos como gestionados o haz que pasen por un método de acceso controlado (NAC/VDI/VPN).

8) ¿Cómo prevenimos la fuga de dominios internos a resolutores públicos?

La respuesta fiable es la configuración en endpoints: asegúrate de que los sufijos internos se resuelvan vía resolutores corporativos, y configura DoH/DoT hacia tus endpoints.
El bloqueo en red ayuda pero nunca será perfecto si los clientes pueden tunelar sobre 443.

9) ¿Es arriesgado ejecutar nuestro propio endpoint DoH?

Es un servicio de producción, así que sí. Pero también es un punto de control en el que ya confías (DNS). Si no lo gestionas,
alguien más lo hará—en nombre de tus endpoints—sin tus necesidades de split-horizon o requisitos de respuesta a incidentes.

10) ¿Cuál es el “menos malo” por defecto para un entorno mixto?

Resolutores recursivos corporativos con validación DNSSEC, reenvío de zonas internas y DoT “opportunistic” para endpoints gestionados,
más un endpoint DoH corporativo para navegadores y redes hostiles. Luego ajusta a “strict” donde la monitorización demuestre que es seguro.

Conclusión: siguientes pasos que no te avergonzarán después

DoH y DoT no son solo interruptores de privacidad. Mueven tu plano de control DNS desde la red hacia el endpoint y el resolutor.
Si no provees un servicio DNS cifrado de nivel empresarial, tus usuarios adoptarán uno accidentalmente—mediante una actualización del navegador,
un toggle del SO o una entrada entusiasta en un blog—y entonces lo depurarás a las 2 a.m. con la mitad de la telemetría faltante.

Pasos prácticos:

1. Inventario: identifica dónde se resuelve el DNS hoy (SO, navegadores, clientes VPN, caches de sucursal).
2. Construir: despliega resolutores recursivos corporativos redundantes con validación DNSSEC y reglas split-horizon consistentes.
3. Cifrar: añade endpoints DoT y/o DoH con monitorización real (tasas de handshake, latencia, códigos de error).
4. Controlar: aplica políticas en endpoints y navegadores para usar DNS cifrado corporativo, no endpoints públicos.
5. Confinar: usa bloques de red con moderación para DoT público y endpoints DoH específicos cuando la política lo demande, pero no finjas que es permanente.
6. Ensayar: realiza simulacros de fallos—certificado expirado, sobrecarga de resolutor, fallo upstream—para que la primera vez no sea en producción.

Si haces esto bien, los usuarios obtendrán privacidad en redes hostiles, los equipos de seguridad conservarán visibilidad DNS útil y las aplicaciones internas no se caerán.
El objetivo no es “ganar” contra el cifrado. El objetivo es operar una red donde el cifrado sea normal y tus controles sigan funcionando.