Source: https://ayudaleyprotecciondatos.es/2019/12/04/privacidad-protocolos-dns/
Timestamp: 2020-01-19 10:29:13+00:00

Document:
AEPDCesión de datosCiberseguridadCiudadanosComunicados
By Ana González – On 04/12/2019
Funcionamiento del DNS
¿Por qué el DNS necesita privacidad?
¿Cómo mejorar la privacidad de DNS?
Protocolos para la privacidad de DNS a través del cifrado
Mejora de la privacidad de DNS al limitar la fuga de datos
Incluso cuando el contenido de Internet está protegido por encriptación con los protocolos HTTPS o TLS, la actividad en línea de los usuarios puede estar expuesta a espías que monitorizan las transacciones de DNS.
La comprensión de cómo mitigar la amenaza a la privacidad que plantea el DNS comienza con la comprensión de cómo el DNS puede exponer información sobre los sitios web a los que acceden los usuarios.
La AEPD ha publicado un documento donde se recogen los principales riesgos que los protocolos DNS pueden tener para la privacidad.
Vamos a analizar aquí esos riesgos.
Prácticamente, cada vez que usamos una aplicación de red, comienza con una consulta DNS para asignar dinámicamente el nombre de algún servidor al que necesitamos acceder a un conjunto de direcciones IP que puede utilizar el Protocolo de Internet.
Por ejemplo, en el caso más trivial en el que un usuario desea visitar un sitio web, por ejemplo, www.example.com, el primer paso que realiza el navegador web es obtener una dirección IP correspondiente al nombre de dominio.
Por lo tanto, el conjunto de consultas DNS que realizamos puede filtrar información sobre los sitios web que visitamos, las aplicaciones que usamos y, a veces, incluso las personas con las que nos comunicamos.
Ten en cuenta cómo los diferentes tipos de servidores DNS interoperan para resolver un nombre de dominio en una dirección IP. Un solucionador recursivo primero consulta a un servidor raíz autorizado para confirmar el nivel superior del nombre de dominio; luego el servidor autorizado para todos los dominios con el dominio de nivel superior .com y luego el servidor autorizado para el dominio example.com.
Un análisis simple de este escenario de resolución de DNS arroja algo de luz sobre las implicaciones de privacidad de DNS.
Primero, dado que DNS no implementa ningún mecanismo para proporcionar confidencialidad a las transacciones de DNS, todas las consultas y respuestas de DNS se envían de forma clara y, por lo tanto, todos los nodos que procesan las consultas, podrán registrar la consulta original.
En segundo lugar, cualquier nodo que procese los paquetes de consulta, es decir, cualquier enrutador que intervenga, también puede acceder a la consulta original.
Finalmente, dado que el solucionador recursivo reenvía la consulta original a cada servidor autorizado que contacta, la consulta original también se filtra a ellos innecesariamente.
Originalmente, Internet surgió de una pequeña comunidad de redes de investigación y educación, construida sobre una red que era experimental y financiada por el gobierno. Esas redes originales eran lo suficientemente pequeñas y pocas como para que fuera razonable confiar en la red y en aquellos que la operaban y la usaban.
Si bien se han agregado mejoras en la seguridad a las aplicaciones y protocolos que se usan en Internet, todavía existía una expectativa fundamental de que solo los operadores de red tenían acceso a la infraestructura de Internet.
En 2013, Edward Snowden reveló la existencia de una variedad de sistemas integrales de vigilancia global.
En respuesta, la Junta de Arquitectura de Internet del IETF lanzó RFC7258. Aquí se establece que «El monitoreo generalizado es un ataque técnico que debe mitigarse en el diseño de protocolos IETF, cuando sea posible.»
Esto llevó al requisito de proteger las consultas DNS de la vigilancia en la porción de «última milla» de Internet. Específicamente entre el sistema local (cliente) y el solucionador, como se detalla en RFC7626 .
El primer par de protocolos que implementaron esto fueron DNS sobre TLS («DoT») y DNS sobre DTLS, publicados en RFC7858 y RFC8094 respectivamente.
Por separado, y posteriormente, se produjo un DNS sobre HTTPS («DoH») y se publicó como RFC8484. La «S» en HTTPS se refiere a la seguridad del transporte, específicamente al uso de TLS (anteriormente llamado SSL) para cifrar el tráfico HTTP.
Los dos cambios en el proceso de resolución de DNS que pueden mejorar la protección de la privacidad del usuario final son los siguientes:
Proporcionar confidencialidad a las transacciones de DNS a través del cifrado
Minimizar la información filtrada a los servidores de nombres autorizados de DNS.
Hacer que las transacciones de DNS sean confidenciales implica cifrar las transacciones realizadas entre los resolutores de código auxiliar y los solucionadores recursivos y las transacciones entre los solucionadores recursivos y los servidores de nombres autorizados.
Debido a que es más fácil asegurar las transacciones entre una resolución de código auxiliar y una resolución recursiva, este ha sido el único conjunto de transacciones para el que se han estandarizado e implementado mecanismos de confidencialidad.
DNSCrypt fue el primer protocolo ampliamente utilizado para cifrar y autenticar transacciones DNS entre resolutores de código auxiliar y resolutivos recursivos. El protocolo DNSCrypt nunca se ha enviado al proceso de estándares del Internet Engineering Task Force (IETF). Pero está públicamente documentado y hay implementaciones de código abierto disponibles.
En los últimos años, el IETF ha producido tres protocolos de encriptación y autenticación para mejorar la privacidad del DNS:
DoT: DNS sobre TLS es un protocolo de seguimiento de estándares definido en RFC 7858 que especifica el uso de DoT para proporcionar privacidad a través del cifrado.
DoD: un protocolo experimental definido en RFC 8094, DNS sobre Datagram Transport Layer Security se basa en el protocolo DTLS para proteger el tráfico del Protocolo de Datagrama de Usuario, similar a la forma en que TLS protege el tráfico TCP.
DoH: otro protocolo de seguimiento de estándares definido en RFC 8484, DNS sobre HTTPS proporciona un mecanismo para enviar consultas y respuestas DNS a través del protocolo HTTP Secure, que define el protocolo para enviar tráfico HTTP a través de TLS.
Los tres enfoques encriptan las transacciones DNS entre los resolutores de código auxiliar y los resolutivos recursivos. Cada una de estas técnicas tiene diferentes niveles de implementación y despliegue. Todas las técnicas requieren soporte tanto en la resolución de código auxiliar como en la resolución recursiva, junto con la configuración adecuada en ambos.
Evitar que la consulta DNS original se filtre a servidores de nombres autorizados es una tarea mucho más fácil que implementar protocolos de cifrado.
Se reduce a reenviar la consulta original solo cuando es estrictamente necesario. En el procedimiento tradicional de resolución de DNS, la consulta DNS original se reenvía a cada uno de los servidores de nombres autorizados que se contactan.
Sin embargo, una técnica estandarizada recientemente llamada minimización de nombre de consulta (QNAME) modifica el procedimiento de resolución de DNS en el solucionador recursivo. Así, la consulta original se expone a servidores autorizados solo cuando es estrictamente necesario.
Con la minimización de QNAME en su lugar, el ejemplo de resolución DNS anterior del nombre de dominio www.example.com en una dirección IP sería de la siguiente forma.
En lugar de reenviar la consulta original a cada servidor de nombres autorizado, el solucionador recursivo solicita la autoridad de cada una de las zonas involucradas, comenzando desde la zona raíz, solicitando así registros del servidor de nombres solo para un sufijo del nombre de dominio original. Y reenviando la consulta original solo al servidor de nombres autorizado de la zona correspondiente.
Esto mitiga efectivamente la fuga de información a los servidores de nombres autorizados. La minimización de QNAME solo requiere el soporte adecuado en resolvers recursivos, y muchos resolvers populares ya vienen con soporte de minimización de QNAME habilitado por defecto.
Si eres un usuario final, con tu propio ordenador (no propiedad del empleador), tus principales preocupaciones deben ser si cualquier solucionador DNS alternativo está habilitado / configurado.
El problema principal sería cuando estás utilizando la red de otra persona y si estás violando sus políticas o expectativas. Cuando viajas a otros países este pequeño cambio puede violar las leyes locales. Esto también puede ser cierto en un entorno BYOD (traiga su propio dispositivo), donde esto podría violar la política de tu empleador, con posibles consecuencias relacionadas con el empleo.
Si utilizas los servicios de filtrado basados ​​en políticas de DNS (comunes en las redes domésticas, y no son infrecuentes en las redes empresariales), la habilitación de resoluciones de DNS alternativas probablemente evitará que estos servicios funcionen.
Si te encuentras en un entorno donde hay una combinación de DNS privado y público (generalmente un escenario empresarial), existen dos consecuencias de habilitar soluciones de DNS alternativas:
El DNS privado dejará de funcionar
Los datos sobre las zonas DNS privadas se filtrarán al solucionador DNS alternativo
Si se usa la supervisión de DNS para la detección de malware, habilitar los servidores de resolución de DNS alternativos probablemente hará que esta supervisión falle. Los monitores ya no verán el tráfico de DNS, de una manera que no activará ninguna alarma.
No hay muchas buenas opciones para abordar ninguno de estos problemas.
Puede ser aconsejable comenzar a inspeccionar las configuraciones del navegador: Particularmente cada vez que hay una actualización del software del navegador es posible que desees deshabilitar las actualizaciones automáticas. Las actualizaciones automáticas son preferibles ya que evitan dejar vulnerabilidades conocidas sin parchear.
Puede ser aconsejable hacer una «lista negra» de navegadores particulares (o versiones de navegador), si necesitas tener una postura de seguridad más estricta. Si usas navegadores que exponen la configuración de DNS a usuarios sin privilegios:
Puedes ser más vulnerable al malware que cambia la configuración de DNS.
El malware con frecuencia usa DNS para contactar con los hosts de Comando y Control
La detección de malware a menudo se basa en la detección de estas consultas DNS C2
El malware incluso utiliza DNS como transporte para descargar cargas maliciosas, para evadir el filtrado y la inspección de paquetes
Puede permitir que los malos actores extraigan datos a través de DNS.
Incluso puede ser necesario implementar soluciones avanzadas de «Amenaza en el medio» para descifrar e inspeccionar todo el tráfico HTTPS que sale de tu red.
Esta es generalmente una mala idea, debido a los riesgos asociados con tener tráfico sin cifrar. También tiene el potencial de ser utilizado por actores maliciosos, en caso de que se vea comprometida la infraestructura.
Dado el interés general en la privacidad de DNS, también puede ser aconsejable poner de pie tus propios servidores DoT o DoH o actualizar de DNS normal a DoT o DoH en tus dispositivos de resolución. Esto proporciona una privacidad mejorada a los usuarios finales y puede desalentar el uso de solucionadores DNS de terceros que operan en DoH.
acceso a datosAEPDciberseguridadCifradoconfidencialidadDNSDocumentosmalwaremedidas de seguridadprivacidad

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución