DNS cifrado: DoH y DoT

La lección anterior describió una búsqueda DNS normal como una postal: legible por cualquiera que la maneje en el camino. Existen dos estándares del IETF para meter esa postal en un sobre: DNS sobre TLS (DoT, RFC 7858) y DNS sobre HTTPS (DoH, RFC 8484). Los dos cifran la misma búsqueda; se diferencian sobre todo en cómo la transportan.

DNS sobre TLS

El RFC 7858 declara su objetivo directamente: “el cifrado que da TLS elimina las oportunidades de espiar y manipular en el camino las consultas DNS”, atendiendo el hecho de que “casi todas las consultas DNS se mandan sin cifrar, lo que las hace vulnerables a que un atacante las espíe.” DoT usa su propio puerto dedicado, el 853, en vez del puerto habitual 53. El RFC explica por qué: “esta recomendación de no usar el puerto 53 para DNS sobre TLS busca evitar complicaciones al elegir usar o no TLS y reducir el riesgo de ataques de downgrade.”

DNS sobre HTTPS

El RFC 8484 toma un camino distinto: “cada par de consulta-respuesta DNS se convierte en un intercambio HTTP”, transportado por el mismo puerto 443 que usa el tráfico HTTPS normal. El RFC señala que esto tiene un beneficio extra: “el puerto 443 predeterminado de HTTPS y la posibilidad de mezclar el tráfico DoH con otro tráfico HTTPS en la misma conexión pueden disuadir a dispositivos sin privilegios en el camino de interferir con las operaciones de DNS”, porque una búsqueda es más difícil de aislar y bloquear cuando parece cualquier otra solicitud web.

Qué oculta el cifrado, y qué sigue sin ocultar

Los dos estándares evitan que un operador de red o alguien que espíe el Wi-Fi lea tus búsquedas en tránsito. Ninguno las oculta del resolvedor al que se las mandaste. El RFC 8484 es explícito en que DoH no cambia lo que el propio servidor puede ver: señala que “diversos transportes de consultas y respuestas DNS sí dan datos que se pueden usar para correlacionar solicitudes”, y que mecanismos web ordinarios como las direcciones IP del cliente, las cookies y la información de sesión TLS hacen que “no se sepa que DoH introduzca preocupaciones nuevas más allá de las asociadas con HTTPS” en el extremo del servidor. El RFC 7858 señala de forma parecida que DoT “no atiende otros problemas de seguridad del DNS” y que “incluso con mensajes cifrados, una parte bien posicionada puede llegar a deducir ciertos detalles a partir de un análisis de los tiempos y tamaños de los mensajes.” En resumen: el DNS cifrado traslada quién ve tus búsquedas de vuelta al operador del resolvedor que elegiste, no quita la visibilidad por completo.

Hay una segunda brecha que vale la pena conocer. Cifrar la búsqueda DNS no oculta por sí solo a qué sitio te conectas después: el saludo TLS que sigue normalmente incluye el nombre de host a la vista. Como lo dice la explicación de Cloudflare sobre la Indicación de Nombre de Servidor (SNI), “el SNI incluye el nombre de host en el mensaje Client Hello, o el primerísimo paso de un saludo TLS” — mandado antes de que se establezca el cifrado. Una extensión llamada SNI Cifrado (ESNI), explica la misma fuente, “se suma a la extensión SNI cifrando la parte SNI del Client Hello”, lo que “evita que cualquiera que esté espiando entre el cliente y el servidor pueda ver qué certificado está pidiendo el cliente.” El soporte para ocultar el SNI todavía depende de que tanto el navegador como el sitio estén de acuerdo en usarlo, y todavía no es así como funciona cada conexión.

Cómo lo soporta macOS

Apple documenta una configuración de Ajustes de DNS para Mac, iPhone y iPad que hace justo esto: le permite a un dispositivo “dirigir las consultas DNS de un dispositivo a través de un servidor DNS cifrado usando DNS sobre HTTPS o DNS sobre TLS.” Se entrega como un perfil de configuración, que puede restringir el resolvedor cifrado a dominios específicos mediante “dominios de coincidencia complementarios”, o aplicarse solo en ciertas redes usando “reglas a demanda” que pueden coincidir con cosas como el SSID de la red.