Por César Díaz – Líder de Asuntos de Telecomunicaciones de LACNIC
El sistema de nombres de dominio DNS (Domain Name System), es un sistema de nomenclatura jerárquica que permite a los usuarios de Internet utilizar nombres en lugar de tener que recordar direcciones IP numéricas. Con el aumento de dispositivos conectados a Internet y la necesidad de encontrar una forma más fácil para recordar las IP, se hizo necesario crear un sistema que cumpliera con este requerimiento.
Desde su desarrollo inicial se han incorporado al DNS elementos como las extensiones de seguridad (Domain Name Security Extensions) o DNSSEC. Si bien DNSSEC autentifica las respuestas a las búsquedas de nombres de dominio, no proporciona protecciones de privacidad para esas búsquedas, aunque sí evita que atacantes puedan manipular las respuestas a las solicitudes de DNS.
Las consultas al DNS, transmitidas en texto plano, pueden revelar información sensible sobre qué sitios web visita un usuario y también datos sobre servicios brindados en ciertos dominios. Esto puede facilitar la recopilación de esta información con fines indeseados.
(Acceso libre, no requiere suscripción)
Figura 1: Esquema representativo del funcionamiento de consultas al DNS
En el IETF[1] se vienen dando discusiones sobre el tema en torno al desarrollo de diversos protocolos tales como el DNS Query Name Minimisation (Qname), DNS-sobre-TLS (DoT), DNS sobre Datagram Transport Layer Security (DTLS), DNS-sobre-HTTPS (DoH), y otras ideas en desarrollo como DNS-sobre-Quic (DoQ) que intentan aportar privacidad a las consultas DNS realizadas por los usuarios.
Aunque, en general, los elementos de configuración técnica no están al alcance de todos los usuarios, es necesario simplificar la operación y aplicación de estos protocolos para asegurar la privacidad de nuestras consultas al DNS.
Otro punto relevante a tener en cuenta es que, si bien todos los protocolos desarrollados hasta el momento procuran brindar privacidad a las consultas, ésta no puede asegurarse al 100% ya que las consultas en los extremos siguen siendo en texto plano. De hecho los “resolvers” necesitan esta información en texto plano para poder procesarla.
Figura 1: Esquema representativo del funcionamiento de consultas al DNS
En el IETF[1] se vienen dando discusiones sobre el tema en torno al desarrollo de diversos protocolos tales como el DNS Query Name Minimisation (Qname), DNS-sobre-TLS (DoT), DNS sobre Datagram Transport Layer Security (DTLS), DNS-sobre-HTTPS (DoH), y otras ideas en desarrollo como DNS-sobre-Quic (DoQ) que intentan aportar privacidad a las consultas DNS realizadas por los usuarios.
Aunque, en general, los elementos de configuración técnica no están al alcance de todos los usuarios, es necesario simplificar la operación y aplicación de estos protocolos para asegurar la privacidad de nuestras consultas al DNS.
Otro punto relevante a tener en cuenta es que, si bien todos los protocolos desarrollados hasta el momento procuran brindar privacidad a las consultas, ésta no puede asegurarse al 100% ya que las consultas en los extremos siguen siendo en texto plano. De hecho los “resolvers” necesitan esta información en texto plano para poder procesarla.
Alternativas preferidas
Cuando los usuarios introducen una URL en su navegador, se realiza una consulta al DNS para convertir la parte del dominio de la URL en una dirección IP. A menos que exista un servidor DNS en la red local, la solicitud de resolución de nombres tiene que pasar por la red del proveedor de servicio de Internet y por cualquier router que exista entre el ISP y el servidor DNS.
Si bien existen distintas alternativas de protocolos que buscan brindar privacidad a las consultas al DNS, en un modo práctico el DNS-sobre-TLS (DoT) y DNS-sobre-HTTPS (DoH) son los más divulgados y utilizados en la actualidad por sus características técnicas y de implementación.
En el caso de DoT, creado por el RFC 7858, permite cifrar todas las consultas y respuestas DNS a través del protocolo TLS proporcionando un intercambio de datos seguro entre el cliente y el servidor web, al transferir las consultas a través de un túnel encriptado en donde sólo los dos participantes del intercambio pueden descifrar y procesar los datos. Esto posibilita que los datos se transmitan a través de conexiones TCP simples en la capa 4 y a través del puerto 853.
En cuanto a rendimiento, este protocolo permite mantener la resolución de consultas DNS ofreciendo funcionalidad y compatibilidad en los resolvers tanto del lado del cliente como del servidor. En caso de que la consulta no se pueda realizar, el DNS tiene la posibilidad de responder de todas formas en texto plano dando continuidad al servicio.
Figura 2: Esquema representativo del funcionamiento del DoT
DNS sobre HTTPS (DoH) es otro protocolo de seguridad desarrollado en la IETF mediante el RFC 8484, el cual utiliza el puerto 443 para enviar las consultas a través del tráfico HTTPS, lo que lo hace difícil de identificar en particular porque va mezclado con el tráfico de los navegadores.
Si bien DoH provee privacidad en las consultas, concentra la mayor parte de los datos de DNS en los “resolvers”, dando a éstos información, por ejemplo, del enrutamiento del tráfico de Internet, así como acceso a grandes cantidades de datos de usuarios, lo cual resulta inconveniente.
El DoH puede ser problemático para las empresas o corporaciones que supervisan las consultas al DNS de sus empleados con el objetivo de bloquear el acceso a sitios maliciosos o inapropiados. Esto crea un punto ciego para monitorear debido a que todo el tráfico se envía encriptado a través del puerto 443.
Figura 3: Esquema representativo del funcionamiento del DoH
En cuanto a la performance del protocolo, a pesar que los servidores DNS han sido diseñados para “cachear” eficientemente las consultas que reciben y que el impacto desde la parte del usuario sea menor, el agregar más capas de negociación (capa 7) como lo hace el DoH, agrega procesamiento adicional a los servidores, sumando mayores latencias en las respuestas.
¿Qué protocolo es mejor?
DoH brinda privacidad al ocultar todas las consultas en el tráfico HTTPS regular, pero su “resolución” es realizada entre los navegadores y resolutores concentrando grandes cantidades de información de consultas en pocos resolutores.
Algunos navegadores anunciaron que estarían habilitando el protocolo DoH de manera predeterminada. Sin embargo, esto hubiera sido contraproducente ya que gran cantidad de usuarios sin pericias técnicas exhaustivas utilizan sus equipos con las configuraciones por defecto, y esto los hubiese forzado a adoptar este protocolo sin conocer sus consecuencias.
Cada protocolo está pensado para prevenir un tipo de amenaza en particular. En el caso de DoH, se desarrolló con el objetivo de prevenir posibles espionajes y/o censuras por parte de algunos gobiernos, encapsulando las consultas al DNS dentro de una sesión HTTPS.
DoT ha seguido los mismos pasos de evolución que han logrado otros protocolos tales como HTTP, IMAP, POP, FTP, etc., lo cual es positivo. Además provee mayor seguridad ya que se transmite en la capa de transporte de manera cifrada.
Teniendo en cuenta que la privacidad no es objetiva sino subjetiva, ya que depende de lo que cada usuario quiera priorizar, al momento DoT resulta una mejor alternativa frente a los riesgos que presenta DoH para ser utilizado como protocolo de privacidad.
Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, “Specification for DNS over Transport Layer Security (TLS)”, RFC 7858, DOI 10.17487/RFC7858, May 2016, https://www.rfc-editor.org/info/rfc7858.
Reddy, T., Wing, D., and P. Patil, “DNS over Datagram Transport Layer Security (DTLS)”, RFC 8094, DOI 10.17487/RFC8094, February 2017, https://www.rfc-editor.org/info/rfc8094.
[1] Internet Engineering Task Force (IETF) es una organización internacional abierta de normalización, que tiene como objetivos el contribuir a la ingeniería de Internet, actuando en diversas áreas, como transporte, enrutamiento y seguridad.
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.
