DNS cifrado:

DoH, DoT y DNSCrypt, qué resuelven y qué no

Redes y privacidad  |  unfantasmaenelsistema.com

Cada vez que abres una web, tu dispositivo hace primero una pregunta silenciosa: «¿qué dirección IP tiene este nombre?». Esa consulta DNS viaja, en la inmensa mayoría de las conexiones domésticas, en texto claro por el puerto 53. Cualquiera que esté en el camino —tu operador, el administrador de la wifi del hotel, alguien con acceso al router del vecino— puede leer, uno por uno, todos los dominios que visitas, aunque la web en sí vaya por HTTPS.

DNS over HTTPS (DoH), DNS over TLS (DoT) y DNSCrypt son tres formas de cerrar esa fuga. Las tres cifran la conversación entre tu equipo y el resolutor. Ninguna de las tres, sin embargo, te vuelve invisible: el destino final de tu tráfico se sigue delatando por otras vías. Este artículo separa lo que cada protocolo realmente consigue de lo que se le atribuye por marketing.

1. El problema: el DNS nació sin cifrado

El DNS se diseñó en 1983, cuando la preocupación era que el sistema funcionara y escalara, no que alguien espiara las consultas. El formato por defecto es UDP en el puerto 53, sin autenticación ni confidencialidad. La consulta sale de tu equipo diciendo, en claro, «quiero la IP de ejemplo-sensible.org», y la respuesta vuelve igual de expuesta.

1.1 Quién ve tus consultas DNS

• Tu operador de internet (ISP): normalmente eres tú quien usa su resolutor por defecto, así que tiene el registro completo de cada dominio que resuelves, con fecha y hora
• Cualquiera en tu red local: en una wifi compartida, un atacante puede capturar el tráfico del puerto 53 o, peor, responder antes que el servidor legítimo (spoofing) y mandarte a una IP falsa
• Los saltos intermedios: routers y equipos de red por los que pasa el paquete hasta el resolutor
• El propio resolutor: quien resuelve siempre sabe qué le preguntas; cifrar el transporte no cambia eso, solo cambia quién es ese «quien»

1.2 Qué revela una consulta DNS

Más de lo que parece. El historial de dominios reconstruye con bastante precisión qué bancos usas, qué problemas de salud consultas, qué aplicaciones tienes instaladas (muchas «llaman a casa» a dominios identificables), tu operadora de móvil, tu equipo de fútbol y a qué hora te levantas. Es un perfil de comportamiento de gran valor comercial, y en algunos países también una herramienta de censura: bloquear un dominio a nivel de DNS es la forma más barata de «tirar» una web.

2. Las tres soluciones, uno a uno

2.1 DNS over TLS (DoT)

DoT envuelve la consulta DNS de siempre dentro de una conexión TLS, exactamente el mismo cifrado que protege HTTPS, y la manda por un puerto propio y reservado, el 853. El mensaje interno sigue siendo un paquete DNS binario estándar; lo único que cambia es que ahora va dentro de un túnel cifrado y autenticado.

• Ventaja: al tener puerto propio, es limpio de operar y de auditar. Un administrador de red ve claramente qué tráfico es DoT y puede permitirlo o forzar el suyo
• Desventaja: esa misma claridad lo hace trivial de bloquear. Basta con cerrar el puerto 853 y DoT deja de funcionar, normalmente con una caída limpia al DNS en claro
• Es el mecanismo que usan por defecto Android («DNS privado») y muchos resolutores de red

2.2 DNS over HTTPS (DoH)

DoH mete la consulta DNS dentro de una petición HTTPS normal y corriente, por el puerto 443, el mismo que usa todo el tráfico web. Para un observador de red, una consulta DoH es indistinguible de cargar cualquier página: mismo puerto, mismo aspecto de handshake TLS, mismo patrón.

• Ventaja: muy resistente al bloqueo. Cerrar el 443 es cerrar internet entero, así que un censor no puede filtrar DoH sin efectos colaterales enormes (salvo bloqueando dominios de resolutores concretos uno a uno)
• Desventaja: esa opacidad también molesta a quien tiene motivos legítimos para ver el DNS —un firewall corporativo, un filtro parental, un IDS doméstico— porque el DNS deja de ser visible en la red
• Es el mecanismo que integran los navegadores (Firefox, Chrome, Edge) directamente, saltándose el resolutor del sistema operativo

2.3 DNSCrypt

DNSCrypt es anterior a DoH y DoT y sigue vivo gracias al proyecto dnscrypt-proxy. No usa TLS: define su propio protocolo de cifrado autenticado sobre UDP o TCP, con la clave pública del resolutor distribuida en un «sello» (stamp). Añade Anonymized DNS, que enruta la consulta a través de un relé para que el resolutor final no vea tu IP —una idea parecida a un salto de Tor, aplicada solo al DNS.

• Ventaja: madurez, gran lista de resolutores públicos con sus políticas declaradas, y el modo anónimo que separa «quién pregunta» de «qué se pregunta»
• Desventaja: adopción menor, no viene integrado en sistemas ni navegadores (necesitas instalar dnscrypt-proxy), y usa puertos no estándar que también se pueden bloquear

3. Lo que el DNS cifrado NO resuelve

Aquí está el malentendido más común: «si cifro el DNS, nadie sabe qué webs visito». Falso. Cifrar el DNS tapa una vía de fuga, no todas. Después de resolver el nombre, tu equipo abre una conexión a esa IP, y ese tráfico sigue delatando el destino de varias formas.

Conclusión práctica: el DNS cifrado te protege bien frente a un observador pasivo casual (el vecino en la wifi, un ISP que perfila por DNS) y frente al manipulado de respuestas (spoofing, censura por DNS). No te da anonimato frente a un adversario que puede observar tu tráfico IP. Para eso hace falta una VPN de confianza o Tor —lo cubrimos en nuestro artículo VPN, Tor y Proxy: qué te protege realmente y de qué.

4. El lío de los dos resolutores

Desde que los navegadores integran DoH, es habitual acabar con dos resolutores distintos activos a la vez y no saberlo. El sistema operativo resuelve por su cuenta (para todo lo que no es el navegador: actualizaciones, clientes de correo, apps), y el navegador resuelve por otro lado con su propio DoH.

• Confusión de diagnóstico: cambias el DNS del router y el navegador sigue usando otro; una web te carga en el móvil pero no en el portátil por resolutores diferentes
• Se rompe el DNS interno de tu red: si el navegador ignora el resolutor local, deja de resolver nombres de tu NAS, tu impresora o el dominio interno de la empresa (split-horizon)
• Filtros que dejan de aplicar: un Pi-hole o AdGuard Home en tu red no bloquea nada si el navegador resuelve por su cuenta con DoH a un tercero

5. DoH y las redes gestionadas

En una red corporativa o educativa, el DNS no es solo resolución: es un punto de control y de telemetría. Se usa para aplicar filtrado de contenido, para bloquear dominios de mando y control de malware, para el split-horizon (que «intranet.empresa.com» resuelva a una IP interna) y para detectar equipos infectados por sus consultas.

El DoH del navegador, al saltarse el resolutor corporativo, desactiva todo eso de golpe. Por eso Firefox implementa el mecanismo de canary domain (`use-application-dns.net`): si el resolutor de la red responde NXDOMAIN a ese nombre, Firefox entiende que la red no quiere DoH y no lo activa. Chrome y Edge, gestionados por directiva de grupo, permiten al administrador fijar o prohibir el DNS seguro. La postura sana en una red gestionada es desplegar DoT/DoH en el resolutor de la organización (cifrado hacia los upstreams) y desactivar el del cliente, no prohibir el cifrado por completo.

6. Montar tu propio resolutor cifrado

Usar el DoH de un gran proveedor traslada el problema: dejas de confiar en tu ISP para confiar en otra empresa que ahora ve todas tus consultas. La alternativa es resolver tú mismo. Tienes tres enfoques según cuánto quieras montar.

6.1 unbound como resolutor recursivo propio

unbound resuelve desde los servidores raíz sin depender de ningún upstream, valida DNSSEC, y puede escuchar en DoT para tus clientes. Nadie —ni un proveedor de DoH— tiene la lista completa de tus consultas, porque las repartes entre los servidores autoritativos de cada dominio.

# /etc/unbound/unbound.conf  (extracto ilustrativo)
server:
    interface: 0.0.0.0@853
    tls-service-key: "/etc/unbound/tls/privkey.pem"
    tls-service-pem: "/etc/unbound/tls/fullchain.pem"
    do-tcp: yes
    hide-identity: yes
    hide-version: yes
    qname-minimisation: yes      # manda a cada servidor solo lo que necesita saber
    harden-dnssec-stripped: yes
    cache-min-ttl: 300
    prefetch: yes

6.2 dnsdist como router de DNS

dnsdist (del proyecto PowerDNS) se pone delante y habla DoH, DoT y DNSCrypt hacia los clientes, mientras reparte, balancea y cachea contra uno o varios backends (tu unbound, o upstreams públicos). Es la pieza que usa la gente que quiere terminar DoH en su propia infraestructura con métricas y reglas.

-- /etc/dnsdist/dnsdist.conf  (extracto ilustrativo)
addDOHLocal("0.0.0.0:443", "/etc/dnsdist/cert.pem", "/etc/dnsdist/key.pem", { "/dns-query" })
addTLSLocal("0.0.0.0:853", "/etc/dnsdist/cert.pem", "/etc/dnsdist/key.pem")
newServer({ address = "127.0.0.1:5353", pool = "recursor" })  -- backend unbound local
addAction(AllRule(), PoolAction("recursor"))
setACL({ "192.168.0.0/16", "10.0.0.0/8" })

6.3 AdGuard Home: la opción con interfaz

Si no quieres editar ficheros de configuración, AdGuard Home ofrece resolutor con DoH/DoT de entrada y de salida, filtrado de anuncios y rastreadores, registro de consultas y una interfaz web. Es el camino habitual para una red doméstica: cifrado hacia fuera, bloqueo y visibilidad dentro, y un solo sitio donde apuntar todos los dispositivos.

# Comprobar desde un cliente que la resolucion cifrada funciona
# (kdig viene con knot-dnsutils; +tls-ca valida el certificado del resolutor)
kdig -d @192.168.1.2 +tls-ca +tls-host=dns.tured.local example.com
 
# DoH con curl contra tu propio endpoint /dns-query
curl -s -H 'accept: application/dns-json' \
  'https://dns.tured.local/dns-query?name=example.com&type=A' | jq .

7. Cómo elegir

Conclusión

DoT, DoH y DNSCrypt hacen bien una cosa concreta y valiosa: impiden que un observador en el camino lea o manipule tus consultas de nombres, y te sacan de la telemetría por DNS de tu operador. La diferencia entre ellos es sobre todo operativa —DoT es limpio pero bloqueable, DoH es resistente pero opaco, DNSCrypt añade un modo que separa tu identidad de tus consultas.

Lo que ninguno hace es ocultar a dónde va tu tráfico: la IP de destino y el SNI del handshake TLS siguen contando la historia hasta que ECH esté desplegado de forma general. Y activarlo sin pensar en el navegador te deja con dos resolutores peleándose y con tus filtros locales fuera de juego. La configuración que casi siempre acierta es un único resolutor —propio o de confianza— cifrado hacia fuera, con el DoH del navegador desactivado para que respete esa decisión.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)