Debian 13: DNS sobre TLS/HTTPS — habilítalo sin romper redes empresariales (caso nº 51)

El DNS cifrado es el tipo de mejora que parece aburrida hasta que eres la persona de guardia leyendo una captura de paquetes a las 02:00 y te das cuenta de que la mitad de la flota está filtrando nombres internos al Wi‑Fi al que se conectó. Quieres DNS sobre TLS (DoT) o DNS sobre HTTPS (DoH) por privacidad, integridad y, a veces, por pura fiabilidad.

Las redes empresariales, sin embargo, tienen opiniones: zonas split‑horizon, resolutores internos con políticas, proxies que interceptan, clientes VPN que “ayudan” y el equipo de cumplimiento que quiere saber adónde fueron tus consultas. Debian 13 puede manejar DNS cifrado de forma limpia, pero debes respetar el entorno o acabarás provocando una caída en cámara lenta.

Lo que realmente estás cambiando (y lo que no)

En Debian 13, la forma práctica de “activar DNS cifrado” es poner a systemd-resolved a cargo de la resolución de nombres y decirle que use, según el caso:
a) tus resolutores corporativos por DoT si lo soportan, o
b) un reenviador DoH/DoT controlado por vosotros (recomendado), o
c) un resolutor público (solo si la política lo permite y aceptas las consecuencias).

La distinción clave: habilitar DoT/DoH en un cliente no arregla mágicamente el DNS. Cambia la seguridad de transporte entre el cliente y su resolutor configurado. Si tu resolutor sigue haciendo DNS en claro hacia upstream, la consulta abandona la red sin cifrar en ese punto. Eso puede estar bien; también puede ser exactamente el problema de cumplimiento que intentabas resolver.

Además: cifrar DNS no detiene SNI, ECH, el seguimiento por IP ni el hecho de que alguien aún pueda ver a qué te conectas. Solo reduce la fuga pasiva de consultas DNS y hace más difícil cierto manipulado.

Orientación con criterio: en empresas, no apuntes endpoints directamente a DoH públicos aleatorios. Ejecuta un reenviador (o actualiza tus resolutores internos) para que políticas, split‑horizon, registros y respuesta a incidentes sigan funcionando.

Hechos y contexto que puedes repetir en una reunión

• El DNS asumía originalmente una red amigable. El protocolo base es UDP/53 de pensamiento de la era 1983: rápido, propenso a pérdidas y fácil de observar o falsificar.
• DNSSEC añade integridad, no privacidad. Puede validar respuestas, pero tus preguntas siguen viajando en claro a menos que uses DoT/DoH.
• DoT se estandarizó como RFC 7858 (2016). Es DNS en TLS, típicamente TCP/853, claro y reconocible como tráfico “tipo DNS”.
• DoH se estandarizó como RFC 8484 (2018). Es DNS sobre HTTPS, normalmente TCP/443, que puede mezclarse con tráfico web y molestar a los equipos de firewall.
• Los navegadores provocaron la reacción en empresas. Despliegues “automáticos de DoH” en navegadores rompieron zonas internas en muchas organizaciones, haciendo que los equipos de red sean alérgicos a DoH por defecto.
• El split‑horizon DNS es una característica, no un apaño. Nombres internos como corp.example deben resolverse de forma distinta dentro y fuera; el DNS cifrado no elimina ese requisito y amplifica los errores.
• Los portales cautivos odian el DNS cifrado. Si no puedes resolver el nombre del portal sin aceptar primero los términos, el DNS “inteligente” puede mantenerte sin conexión.
• Muchos resolutores corporativos ya soportan cifrado. BIND moderno, Unbound y algunos appliances DNS soportan DoT/DoH—pero certificados y políticas deben manejarse deliberadamente.
• El registro centralizado suele ser innegociable. Los equipos de seguridad dependen de los registros DNS para investigaciones; evitar los resolutores internos puede considerarse una violación de política, no una innovación.

DoT vs DoH: elige la herramienta correcta para tu red

DoT: predecible, amigable con firewalls (en sentido empresarial)

DoT usa un puerto distinto (853). Eso es una bendición: puedes permitirlo donde corresponda, bloquearlo donde la política lo diga e identificarlo en logs de flujo sin pretender que cada sesión TLS es “solo tráfico web”.

Si tu empresa tiene un perímetro de seguridad con egress muy controlado, DoT suele ser más fácil de negociar. Puedes demostrar qué es. También puedes enrutarlo a un clúster de resolutores interno y mantener el split‑horizon intacto.

DoH: conveniente, a veces políticamente tóxico

DoH viaja sobre HTTPS. Eso es excelente para clientes en roaming porque 443 casi siempre está abierto. También es la razón por la que algunas redes lo tratan como “exfiltración de DNS disfrazada de navegación web”. Si tu proxy hace inspección TLS, DoH puede fallar de formas curiosas a menos que controles ambos extremos.

Usa DoH cuando tengas un endpoint conocido y gestionado (tu propio front‑end DoH o un proveedor aprobado por la empresa) y entiendas cómo se comporta con proxies, mTLS e interceptación de certificados.

La verdad seca: cuando le dices a un equipo de firewall “queremos DNS sobre HTTPS”, ellos oyen “quiero pasar la política por debajo de la mesa”. No siempre están equivocados.

Modos de fallo en empresas: dónde muere el DNS cifrado

Split‑horizon y dominios de búsqueda

Si los clientes evitan los resolutores internos, las zonas internas fallan. El buzón de tickets se llena con “VPN no funciona” y “el servidor Git no responde” mientras todo está técnicamente “arriba”. La solución no es “desactivar DoH”, es “dejar de evitar el resolutor que conoce las zonas privadas”.

Intercepción de proxy y TLS break‑and‑inspect

Los proxies corporativos que interceptan TLS pueden hacer que DoH falle de dos formas opuestas:
o bien lo bloquean por completo, o bien lo MITM y presentan una CA corporativa que tu cliente DoH no confía. Si el cliente es estricto (como debe ser), obtienes timeouts y comportamientos de retroceso misteriosos.

Configuraciones DNS de VPN sobrescritas

Los clientes VPN a menudo empujan servidores DNS y dominios. Si fijas DoT/DoH en el SO y ignoras DNS por enlace, puedes enrutar consultas de zonas internas fuera del túnel. Felicidades, acabas de crear una fuga de datos y un incidente de fiabilidad en un solo movimiento.

Middleboxes que “ayudan” reescribiendo

Algunas redes reescriben respuestas DNS (portales cautivos, controles parentales, filtros antimalware). Si los evitas, evitas la funcionalidad. A veces eso es el objetivo. Otras veces esa funcionalidad es cómo los invitados llegan a la página de inicio de sesión del Wi‑Fi. Elige tu dolor.

Regresiones de rendimiento por overhead de handshake y caché rota

Los handshakes TLS no son gratis. Con buen reuse de conexiones, la sobrecarga es menor. Con redes malas, conexiones efímeras o resolutores mal ajustados, puedes añadir latencia notable. La gente nota la latencia DNS porque se manifiesta como “internet va lento” y nadie pone un ticket preciso.

Guion de diagnóstico rápido

Cuando el DNS cifrado “no funciona”, no adivines. No gires perillas al azar. Ejecuta las mismas tres comprobaciones cada vez para encontrar el cuello de botella rápidamente.

1. Primero: confirma quién está haciendo DNS y qué servidores se usan.
   Si el sistema sigue usando un /etc/resolv.conf legado desde DHCP, ninguna de tus configuraciones de systemd-resolved importa.
2. Segundo: confirma la alcanzabilidad de transporte (853 para DoT, 443 para el endpoint DoH).
   Un puerto bloqueado parece “timeout DNS” y te hace perder horas si no lo compruebas de inmediato.
3. Tercero: confirma validación de certificado/SNI/nombre (especialmente DoT).
   Si el certificado del resolutor no coincide con lo que espera el cliente, systemd-resolved degradará silenciosamente dependiendo de la configuración. Decide si quieres modo estricto u oportunista y luego aplícalo.

Si esos tres pasan, los sospechosos restantes son: enrutamiento DNS por división, interceptación por proxy, fallos de validación DNSSEC o problemas de rendimiento/capacidad del resolutor.

Tareas prácticas: comandos, salidas y decisiones

Estas son las tareas de campo que realmente ejecuto en hosts Debian cuando activo DoT/DoH o depuro por qué el portátil de alguien no puede resolver git.corp.example mientras está en VPN.

Cada tarea incluye: comando, ejemplo de salida, qué significa y la decisión que tomas.

Task 1 — Identificar el stack de resolutor activo

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Dec 30 09:12 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Significado: /etc/resolv.conf apunta al stub de systemd, por lo que las aplicaciones consultarán a 127.0.0.53 y systemd-resolved hará el trabajo upstream.

Decisión: Si no ves un enlace simbólico al stub/real de systemd, arréglalo primero; de lo contrario estarás cambiando configuraciones que nadie usa.

Task 2 — Confirmar que systemd-resolved está en ejecución y es la autoridad

cr0x@server:~$ systemctl status systemd-resolved --no-pager
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-12-30 09:10:21 UTC; 6min ago
       Docs: man:systemd-resolved.service(8)
   Main PID: 612 (systemd-resolve)
     Status: "Processing requests..."

Significado: El servicio resolutor está en ejecución.

Decisión: Si está inactivo/deshabilitado, habilítalo correctamente o elige otro stack de resolutor (Unbound, dnscrypt-proxy, etc.)—pero no dejes ambos medio habilitados.

Task 3 — Inspeccionar la configuración DNS actual por enlace (comprobación de split DNS)

cr0x@server:~$ resolvectl status
Global
       Protocols: +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (ens192)
    Current Scopes: DNS
         Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.20.30.40
       DNS Servers: 10.20.30.40 10.20.30.41
        DNS Domain: corp.example

Significado: El DNS proviene de servidores corporativos en esta interfaz; DNS-over-TLS está actualmente deshabilitado.

Decisión: Mantén el DNS por enlace. No anules globalmente a menos que estés seguro de no romper dominios provistos por la VPN.

Task 4 — Verificar que la build de systemd-resolved soporte DoT/DoH

cr0x@server:~$ resolvectl --version
systemd 258 (258.2-1)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +BPF_FRAMEWORK
+IDN2 +XZ +ZSTD +BZIP2 +LZ4 +ACL +BLKID +CURL +ELFUTILS +FIDO2 +TPM2 +PWQUALITY +P11KIT
default-hierarchy=unified

Significado: Hay systemd moderno; el soporte DoT es estándar aquí. El soporte DoH depende de características de compilación y versión, así que verifica en tu entorno Debian 13.

Decisión: Si necesitas DoH y tu build no lo tiene (o la política exige un cliente DoH dedicado), planifica un reenviador local como Unbound que use DoT upstream, o un proxy DoH que gestionéis.

Task 5 — Comprobar si el DNS está filtrando a resolutores públicos

cr0x@server:~$ grep -vE '^\s*#|^\s*$' /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search corp.example

Significado: Las aplicaciones usan el stub local; la selección upstream está oculta detrás de resolved.

Decisión: Si ves una IP pública aquí, ya estás evitando el DNS corporativo. Decide si se permite antes de añadir cifrado.

Task 6 — Probar que la resolución básica funciona antes de cifrar nada

cr0x@server:~$ resolvectl query debian.org
debian.org: 151.101.194.132 151.101.2.132 151.101.66.132 151.101.130.132
          -- Information acquired via protocol DNS in 21.5ms.
          -- Data is authenticated: no

Significado: El DNS base funciona. No cambies el transporte cuando la línea base ya esté rota.

Decisión: Si esto falla, arregla enrutamiento/DHCP/DNS de VPN primero. El DNS cifrado no te salvará de un “servidor DNS equivocado”.

Task 7 — Habilitar DoT en systemd-resolved (oportunista vs estricto)

Edita /etc/systemd/resolved.conf. Para empresa, comienza con DoT oportunista si no estás seguro de los certificados, y luego pasa a estricto.

cr0x@server:~$ sudoedit /etc/systemd/resolved.conf

cr0x@server:~$ grep -nE '^(DNS=|DNSOverTLS=|Domains=|FallbackDNS=)' /etc/systemd/resolved.conf
9:DNS=10.20.30.40#dns.corp.example 10.20.30.41#dns.corp.example
12:FallbackDNS=
15:Domains=~corp.example ~.
20:DNSOverTLS=opportunistic

Significado: Fijas resolutores internos y proporcionas el hostname TLS esperado (#dns.corp.example) para que la validación de certificados funcione cuando pases a estricto. La línea Domains= indica enrutamiento split DNS: ~corp.example se enruta a estos servidores; ~. indica la ruta por defecto.

Decisión: Usa opportunistic para el primer despliegue. Pasa a yes (estricto) una vez verifiques certificados y middleboxes.

Task 8 — Reiniciar resolved y validar que la configuración está activa

cr0x@server:~$ sudo systemctl restart systemd-resolved
cr0x@server:~$ resolvectl status | sed -n '1,25p'
Global
       Protocols: +LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Significado: +DNSOverTLS indica que DoT está habilitado globalmente. Esto no garantiza que todos los upstreams lo soporten; significa que el cliente lo intentará.

Decisión: Si aún muestra -DNSOverTLS, tu config no se está leyendo o fue sobrescrita por un drop‑in. Investiga antes de continuar.

Task 9 — Confirmar que las consultas van al resolutor previsto, no a “cualquiera”

cr0x@server:~$ resolvectl query git.corp.example
git.corp.example: 10.55.8.19
               -- Information acquired via protocol DNS in 6.3ms.
               -- Data is authenticated: no

Significado: El nombre interno se resuelve; el split‑horizon está intacto.

Decisión: Si los nombres internos fallan después de habilitar DoT, probablemente los enrutas al upstream equivocado (los resolutores públicos globales son el culpable habitual).

Task 10 — Detectar si el puerto 853 está bloqueado (el clásico “se agota el tiempo”)

cr0x@server:~$ nc -vz 10.20.30.40 853
nc: connect to 10.20.30.40 port 853 (tcp) timed out: Operation now in progress

Significado: TCP/853 no es alcanzable (firewall, ACL, resolutor no escuchando). DoT oportunista caerá a DNS en claro; DoT estricto romperá la resolución.

Decisión: Si la política permite DoT, abre 853 al VIP del resolutor. Si la política lo prohíbe, no habilites DoT estricto en clientes; ejecuta cifrado dentro de la red en su lugar (cliente→resolutor interno en claro, resolutor interno→upstream cifrado).

Task 11 — Validar certificado del resolutor y SNI con OpenSSL

cr0x@server:~$ openssl s_client -connect 10.20.30.40: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 resolutor presenta un certificado que coincide con dns.corp.example, y el host confía en la CA emisora.

Decisión: Si la verificación falla, no cambies a DoT estricto hasta arreglar la distribución de CA o corregir el nombre del servidor en DNS=.

Task 12 — Revisar logs para la toma de decisiones de resolved (te lo dirá, si se lo pides)

cr0x@server:~$ journalctl -u systemd-resolved --since "10 min ago" --no-pager | tail -n 12
Dec 30 09:15:33 server systemd-resolved[612]: Using DNS server 10.20.30.40 for interface ens192.
Dec 30 09:15:33 server systemd-resolved[612]: Switching to DNS server 10.20.30.41 for interface ens192.
Dec 30 09:16:02 server systemd-resolved[612]: Server returned error NXDOMAIN, ignoring.
Dec 30 09:16:44 server systemd-resolved[612]: DNS-over-TLS negotiation failed with 10.20.30.40:853: Connection timed out

Significado: Obtienes evidencia explícita: negociación fallida, cambió de servidor o recibió NXDOMAIN. Ese es tu rastro de migas.

Decisión: Timeout de conexión → problema de red/puerto. Falla de verificación → problema de PKI. NXDOMAIN → enrutamiento split DNS o contenido incorrecto en el resolutor.

Task 13 — Medir latencia y comportamiento de caché (porque “cifrado” puede volverse “lento”)

cr0x@server:~$ resolvectl statistics
Transactions: 224
  Cache Hits: 141
  Cache Misses: 83
DNSSEC Verdicts: 0
DNSSEC Supported: no
DNSSEC NTA: 0

Significado: La proporción de aciertos de caché te da una idea rápida. Si está cerca de cero en un sistema muy ocupado, algo está mal (aplicaciones evitando el stub, o caché deshabilitada en otra parte).

Decisión: Baja proporción de aciertos + quejas de latencia: asegúrate de que todos usen 127.0.0.53 y de que no estés reiniciando resolved constantemente (sí, eso pasa).

Task 14 — Probar qué proceso está enviando DNS si sospechas bypass

cr0x@server:~$ sudo ss -ntup | awk '$5 ~ /:53$|:853$|:443$/ {print}'
tcp   ESTAB 0 0 10.9.1.12:45652 10.20.30.40:853 users:(("systemd-resolve",pid=612,fd=25))

Significado: La conexión DoT proviene de systemd-resolve, como se pretende.

Decisión: Si ves aplicaciones conectando directamente a IPs públicas en 53/853/443, tienes bypass. Abórdalo con política (y a veces reglas de firewall de egress).

Task 15 — Verificar que DHCP/VPN no estén sobrescribiendo DNS inesperadamente

cr0x@server:~$ nmcli dev show ens192 | sed -n '1,80p'
GENERAL.DEVICE:                         ens192
GENERAL.STATE:                          100 (connected)
IP4.DNS[1]:                             10.20.30.40
IP4.DNS[2]:                             10.20.30.41
IP4.DOMAIN[1]:                          corp.example

Significado: NetworkManager está suministrando los servidores DNS corporativos y el dominio. Bien. Esa es la base para el split DNS.

Decisión: Si ves servidores DNS inesperados aquí (Wi‑Fi de hotel, VPN, etc.), decide cuál debe ganar y configura enrutamiento por enlace en lugar de un martillo global.

Task 16 — Comprobar la política del firewall local (no asumas que la red es el único firewall)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain output {
    type filter hook output priority 0; policy accept;
  }
}

Significado: El firewall local no está bloqueando 853/443 salientes. Si lo estuviera, verías drops explícitos.

Decisión: Si la política local bloquea 853, arréglalo localmente o acepta que DoT no puede funcionar en ese host.

Listas de comprobación / plan paso a paso (despliegue seguro)

Step 0 — Decide qué significa “seguro para la empresa” en tu organización

• ¿Deben resolverse zonas internas? Si sí, los clientes deben usar resolutores internos para esas zonas.
• ¿Deben centralizarse los registros DNS? Si sí, no evites los resolutores internos. Cifra de endpoint→resolutor si puedes; si no, cifra resolutor→upstream.
• ¿Hay proxies en juego? Si sí, trata DoH como “requiere diseño”, no como “apaga y enciende”.
• ¿Se requiere validación estricta de certificados? Normalmente sí. Pero haz un despliegue controlado para evitar fallos masivos.

Step 1 — Inventario del comportamiento DNS actual

• Recopila resolvectl status de hosts representativos: en LAN, en VPN, en Wi‑Fi, en un segmento del CPD.
• Identifica dónde existe split DNS: dominios, reenviadores condicionales, comportamiento similar a NRPT.
• Confirma si los resolutores internos soportan DoT/DoH hoy (y si tienen certificados correctos).

Step 2 — Prefiere “cifrar hacia tu resolutor”, no “evitar tu resolutor”

Si tus resolutores internos pueden hablar DoT con un certificado válido: hazlo. Es el modelo más limpio para empresas.
Si no pueden: ejecuta una pequeña capa de reenvío gestionada (Unbound/BIND) que acepte DNS en claro de clientes y haga upstream cifrado dentro de tu perímetro de confianza.

Step 3 — Despliega DoT oportunista primero, con monitorización

• Habilita DNSOverTLS=opportunistic en un grupo piloto.
• Monitoriza: latencia DNS, tasa de errores, CPU del resolutor, conteo de conexiones TCP/853 y reportes de usuarios sobre “internet lento”.
• Observa logs por fallos de negociación. Arregla alcanzabilidad y certificados antes de activar modo estricto.

Step 4 — Pasa a DoT estricto donde sea posible

Una vez puedas validar certificados de forma fiable (openssl s_client en la tarea anterior), cambia a estricto:
evita degradar silenciosamente a texto plano cuando un middlebox bloquee 853.

cr0x@server:~$ sudo perl -0777 -i -pe 's/DNSOverTLS=opportunistic/DNSOverTLS=yes/g' /etc/systemd/resolved.conf
cr0x@server:~$ sudo systemctl restart systemd-resolved
cr0x@server:~$ resolvectl status | sed -n '1,12p'
Global
       Protocols: +LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported

Step 5 — Mantén el split DNS explícito

Cuando necesites resolución interna y externa, sé explícito sobre el enrutamiento. Deja que las zonas corporativas vayan a resolutores corporativos y que el resto siga la ruta por defecto.
El peor plan es “un resolutor público global para todo”. Eso no es un plan; es cómo aprendes qué equipos pueden gritar más fuerte.

Step 6 — Documenta los casos de excepción (ocurrirán)

• Redes con portal cautivo
• Segmentos DC restringidos que bloquean egress 853/443
• Sistemas con agentes de proveedor que fijan DNS
• Aplicaciones legacy que incluyen sus propias librerías de resolución

Tres mini‑historias corporativas (por qué esto es más difícil de lo que parece)

Mini‑historia 1 — El incidente causado por una suposición equivocada

Una empresa mediana decidió “modernizar el DNS”. Un ingeniero con buenas intenciones supuso que el DNS cifrado era puramente una mejora de privacidad, funcionalmente equivalente al DNS en claro. Habilitaron DoH en un subconjunto de portátiles Debian, apuntando a un proveedor público porque era “fiable”.

El lunes por la mañana fue un goteo lento. Nada explotó de inmediato. Pero los desarrolladores en VPN empezaron a reportar que servicios internos fallaban intermitentemente al resolverse. La mesa de ayuda vio un patrón: usuarios que reiniciaron recientemente tenían más problemas. Los usuarios que no reiniciaron en todo el fin de semana estaban bien. Ese tipo de patrón te hace sospechar de cachés, no de infraestructura.

La suposición equivocada fue simple: “DNS es DNS”. En realidad, sus resolutores internos hacían split‑horizon para corp.example, devolviendo VIP internos solo cuando la consulta venía desde la red interna o la pool de direcciones de la VPN. Los resolutores públicos hicieran lo típico: o no devolvían nada o devolvían direcciones externas destinadas a partners. Algunos servicios eran accesibles externamente, pero con rutas de autenticación distintas. Caos, pero del tipo silencioso.

La solución no fue dramática. Dejaron de evitar el DNS corporativo. Volvieron los portátiles a usar resolutores internos y luego actualizaron la capa de resolutor interno para proporcionar transporte cifrado a usuarios en roaming vía un endpoint gestionado. La lección quedó: las mejoras de privacidad siguen siendo cambios de red. Trátalas como tales.

Mini‑historia 2 — La optimización que salió mal

Otra organización quería reducir la latencia DNS entre sedes globales. Alguien propuso: “Forcemos un único endpoint DoH global en 443. Cruzará cualquier firewall y HTTP/2 multiplexará consultas. ¿Más rápido, no?” Sonaba moderno. Era moderno. También era ingenuo respecto a geografía y proxies.

El despliegue empezó en una región donde el HTTPS saliente se forzaba a través de un proxy explícito con inspección TLS. El cliente DoH no confiaba en el certificado MITM del proxy para ese endpoint. Las búsquedas DNS empezaron a bloquearse porque el sistema intentaba DoH primero, esperaba y después retrocedía. El retroceso también estaba bloqueado, porque UDP/53 de salida estaba denegado por política (como debe).

Los usuarios lo percibieron como “cada web tarda diez segundos en empezar a cargarse”. No eran los sitios: era el resolutor que hacía timeout en cada nombre nuevo hasta que las cachés se calentaban o las apps reintentaban de otra forma. Algunas apps lo gestionaron; otras thrashearon.

El informe post‑incidente fue francamente directo: la optimización asumía un camino limpio a internet. Las empresas raramente lo tienen. Reconstruyeron el diseño alrededor de resolutores internos por región y usaron DoT en puntos de egress controlados. El DNS se volvió más rápido y seguridad dejó de mirar el proyecto con recelo.

Mini‑historia 3 — La práctica aburrida pero correcta que salvó el día

Una compañía fuertemente regulada tenía una regla: no cambiar la política DNS en clientes sin un grupo canario, y no hay canario sin rollback automático. Todos se quejaban porque ralentizaba “mejoras simples”. Luego intentaron habilitar DoT en modo estricto para resolutores corporativos en endpoints Debian.

El canario alertó en minutos. No porque DoT estuviera roto en todas partes, sino porque un sitio aún tenía una regla antigua de firewall que permitía UDP/53 al VIP del resolutor pero bloqueaba TCP/853. El modo oportunista lo hubiera enmascarado; el modo estricto falló correctamente. Los usuarios en ese sitio no pudieron resolver nada.

La automatización los revirtió a oportunista de inmediato, y el incidente se quedó contenido. El equipo de red arregló la política de firewall, luego el canario tuvo éxito y el despliegue continuó. Nadie recibió un page a medianoche. El proceso aburrido no solo “redujo el riesgo”; transformó un filo cortante en un moretón pequeño.

La fiabilidad a menudo es simplemente negarse a cometer el mismo error en todas partes a la vez.

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

1) “Los dominios internos no se resuelven después de habilitar DoH/DoT”

Síntomas: git.corp.example NXDOMAIN o resuelve a IPs externas; usuarios VPN acceden a endpoints equivocados.

Causa raíz: Evitar los resolutores internos que sirven zonas split‑horizon; la anulación DNS global ignora el enrutamiento por enlace.

Solución: Usa resolutores internos para ~corp.example con split DNS. No apuntes clientes directamente a resolutores públicos. Valida con resolvectl status y resolvectl query.

2) “Todo está lento, pero no caído”

Síntomas: Páginas e instalaciones de paquetes se pausan antes de conectar; stalls intermitentes; reintentos “lo arreglan”.

Causa raíz: Timeouts de DoH/DoT seguidos de retroceso, a menudo por 853 bloqueado, interceptación por proxy o desajuste de certificado.

Solución: Comprueba alcanzabilidad (nc -vz ... 853), validación de certificados (openssl s_client) y logs de resolved. Prefiere modo estricto solo cuando el camino esté limpio; si no, crearás latencia por timeouts.

3) “DoT en modo estricto falla en un solo sitio”

Síntomas: Funciona en HQ, falla en una sucursal; misma imagen, red distinta.

Causa raíz: Firewall/ACL específico del sitio permite UDP/53 pero bloquea TCP/853, o enruta 853 de forma diferente.

Solución: Alinea la política de red entre sitios. Si no puedes, mantén modo oportunista para ese sitio o termina DoT en un resolutor local dentro de la sucursal.

4) “Funciona por cable pero falla en Wi‑Fi/portal cautivo”

Síntomas: En Wi‑Fi público no alcanzas nada hasta desactivar DNS cifrado; el portal no aparece.

Causa raíz: Los portales cautivos dependen de interceptar DNS/HTTP; el DNS cifrado impide el flujo de interceptación.

Solución: Proporciona un toggle basado en políticas para perfiles de roaming, o permite retroceder a texto plano en redes “no confiables” si tu modelo de riesgo lo admite. Mejor: usa una VPN gestionada que lleve el DNS dentro del túnel después del inicio de sesión en el portal.

5) “Aparecen fallos DNSSEC después de activar cifrado”

Síntomas: Ciertos dominios fallan con SERVFAIL; los logs mencionan DNSSEC o problemas de validación.

Causa raíz: No es causado directamente por el cifrado; expone cambios en el comportamiento del resolutor, manejo de EDNS0 o middleboxes rotos.

Solución: Confirma si tu resolutor valida DNSSEC y si los middleboxes pudren las respuestas. Si tu entorno no puede manejarlo, no habilites validación DNSSEC en el borde a la ligera.

6) “Algunas apps siguen usando DNS en claro después de ‘habilitar DoT’”

Síntomas: Captura de paquetes muestra UDP/53 a servidores aleatorios; o la app resuelve incluso con resolved parado.

Causa raíz: Apps que usan sus propios resolutores (contenedores, runtimes de lenguaje, agentes VPN) o que evitan la ruta de resolución de glibc.

Solución: Audita con ss, configura DNS en runtime de contenedores y controla egress. Impón una única ruta de resolutor para endpoints gestionados o documenta excepciones explícitamente.

Preguntas frecuentes

1) ¿Debo habilitar DoH o DoT en endpoints Debian 13 por defecto?

En empresas: por defecto usa DoT hacia tus resolutores (o tu reenviador gestionado). DoH está bien cuando controlas el endpoint y la historia de proxies. Evita ir directo a públicos salvo que la política lo permita explícitamente.

2) ¿Cuál es el modo inicial de despliegue más seguro?

DoT oportunista. Intenta cifrado pero no tumbará el DNS si un sitio bloquea 853. Usa esa fase para descubrir brechas de política y luego pasa a estricto donde sea posible.

3) Si ya tenemos DNSSEC, ¿seguimos necesitando DoT/DoH?

Sí, si te importa la privacidad de las consultas y resistencia al monitoreo pasivo. DNSSEC protege la integridad de las respuestas (cuando se valida), no la confidencialidad de las preguntas.

4) ¿El DNS cifrado romperá el split‑horizon?

No inherentemente. Evitar el resolutor interno rompe el split‑horizon. Cifrar el transporte hacia el resolutor interno lo preserva.

5) ¿Cómo mantengo los registros de cumplimiento usando DNS cifrado?

Sigue usando resolutores internos donde viven el registro y la política. Cifra desde el endpoint a esos resolutores (DoT) o al menos desde resolutores a upstream. No disperses el DNS de endpoints a proveedores externos aleatorios.

6) ¿Y los proxies e inspección TLS?

DoT suele evitar la intercepción por diseño (no es HTTPS), pero puede bloquearse por reglas de egress. DoH suele colisionar con la inspección a menos que el cliente confíe en la CA interceptora o eximas ese tráfico—ambas son decisiones de política, no “arreglos” técnicos simples.

7) ¿Cómo pruebo que realmente estamos usando DoT?

Busca +DNSOverTLS en resolvectl status, confirma sesiones TCP/853 desde systemd-resolve con ss y valida el certificado del resolutor con openssl s_client.

8) ¿Debería poner resolutores públicos como fallback?

En empresas: generalmente no. Un fallback a resolutores públicos puede evadir silenciosamente zonas internas y registro. Si necesitas resiliencia, ejecuta múltiples resolutores internos y asegura el enrutamiento a ellos en todas partes (LAN, VPN, sucursales).

9) ¿Habilitar DoH/DoT detiene el filtrado basado en DNS?

Puede hacerlo, si el filtrado depende de interceptar DNS en claro en tránsito. Eso puede ser deseable o violar políticas. La respuesta empresarial es hacer el filtrado en el resolutor que controlas y cifrar el transporte hacia él.

Conclusión: próximos pasos que puedes ejecutar esta semana

El DNS cifrado en Debian 13 no es difícil. Hacerlo sin romper redes corporativas consiste principalmente en respetar cómo las empresas usan realmente el DNS: split‑horizon, aplicación de políticas y enrutamiento predecible.

Pasos siguientes que rinden rápido:

1. Elige un modelo: endpoint→resolutor interno cifrado (mejor), o resolutor interno→upstream cifrado (segunda opción), y evita endpoint→resolutor público salvo que la política lo permita.
2. Ejecuta el Guion de diagnóstico rápido en un grupo piloto y arregla los bloqueadores aburridos: alcanzabilidad TCP/853, certificados y comportamiento DNS por enlace.
3. Despliega DoT oportunista con monitorización y luego pasa a estricto donde puedas probar que el camino y la PKI son correctos.
4. Documenta el manejo de excepciones para portales cautivos y clientes VPN extraños. Lo necesitarás.

Una idea parafraseada de W. Edwards Deming aplica bien aquí: Sin datos, eres solo otra persona con una opinión. Mide antes de activar el modo estricto.

Chiste #1: El DNS es el único sistema donde “siempre es la red” es tanto cliché como frecuentemente una afirmación de hecho.

Chiste #2: El DNS cifrado no arreglará tu organigrama, pero revelará quién es el dueño de la política de egress—usualmente por accidente.