El Protocolo DNS-over-TLS en Linux (systemd) Thumbnail
Deploy360 28 diciembre 2018

El Protocolo DNS-over-TLS en Linux (systemd)

Por Kevin MeynellFormer Senior Manager, Technical and Operational Engagement
Fernando GontGuest Author

Mientras estábamos elaborando contenidos acerca de la privacidad de DNS recientemente, supimos que las nuevas distribuciones de Linux incorporan el protocolo de encriptación DNS over TLS. Por lo tanto, decidimos probar Ubuntu 18.10 en un portátil.

Las versiones más recientes de Ubuntu emplean un servicio especial para la resolución de nombres llamado «system-solve.service(8)». El archivo de configuración «resolved.conf(5)» especifica la mayoría de los detalles para la resolución de nombres, incluyendo qué protocolos y resolvedores se deben emplear, mientras que los archivos de configuración «/etc/systemd/network/* .network» (para más información, consulte «systemd.network(5)») del »systemd-networkd.service (8)» especifican cualquier configuración determinada por vínculo.

La configuración predeterminada de «systemd-solve» se selecciona en el tiempo de compilación, y «/etc/systemd/resolved.conf» contiene normalmente líneas comentadas que describen estos valores predeterminados. Por ejemplo, el contenido del archivo mencionado en una nueva instalación de Ubuntu 18.10 es:

Como puede deducirse del archivo, el protocolo DNS-over-TLS (DoT) es compatible, pero está deshabilitado por defecto. En el momento de escribir este artículo, solo se admite el DoT oportunista según el manual, lo que significa que el resolvedor primero intentará resolver el problema utilizando el DoT antes de volver a la DNS tradicional en caso de fallo, permitiendo así ataques de descenso de categoría cuando un atacante provoque intencionadamente un fallo del DoT con el fin de hacer que la resolución de nombres se reduzca a la DNS tradicional.

Decidimos probar con el DoT cambiando tres variables de configuración en «/etc/systemd/solve.conf’:»

  • Pusimos «DNS» en la dirección IP del servidor DoT
  • Establecimos «DNSOverTLS» como «oportunista»
  • Configuramos «Domains» como «~».

La variable «DNS» contiene la lista de direcciones IP que corresponden al resolvedor recurrente del DoT (aquí puede encontrar una lista de resolvedores recurrentes públicos).

El ajuste de «DNSOverTLS» como «oportunista» activa el DoT en modo oportunista – esto significa que el DoT se empleará si es posible, pero el resolvedor simple volverá a la DNS tradicional si falla.

Por último, establecer «Domains» como «~.» programa a «systemd-resolved» para que prefiera el servidor de nombres especificado antes que cualquier servidor DNS por vínculo que esté disponible. Esta es una configuración importante, ya que de lo contrario un resolvedor DNS no DoT por vínculo podría tener prioridad sobre el resolvedor DoT.

Nuestra configuración resultante es por lo tanto la siguiente:

Una vez aplicados estos cambios, es necesario hacerlos efectivos ejecutando el comando:

sudo systemctl restart systemd-resolved

Hecho esto, decidimos entonces comprobar si DoT se estaba empleando en lugar del DNS tradicional. Así que simplemente ejecutamos un analizador de protocolos (sniffer) en el ordenador portátil con Ubuntu, y realizamos una consulta DNS para «fgont.go6lab.si» que reveló lo siguiente:

Nuestra consulta generó tráfico DNS tradicional y DoT en paralelo. De hecho, cuando más tarde ejecutamos un analizador de protocolos en el propio servidor de nombres autorizado, confirmó que tanto el resolvedor local de nuestra red (192.168.3.1) como el resolvedor de Cloud-flare estaban generando consultas para el dominio anterior.

En respuesta a este resultado, tratamos de averiguar por qué veíamos el tráfico DNS tradicional en paralelo, en lugar de solo el tráfico DoT, o al menos el tráfico DoT seguido por el tráfico DNS tradicional partiendo del supuesto de que DoT hubiera fallado. Además, ¿por qué se empleó el resolvedor local para la resolución DNS incluso cuando la variable «Domains» ordena a «systemd-resolved» que emplee el resolvedor DoT especificado antes que cualquier otro resolvedor?

Parece que la ejecuión de «systemd-resolved» para el DoT oportunista no emplea DNS tradicionales solo como resultado de fallos del DoT, sino más bien en paralelo a las consultas del DoT. Por otro lado, un análisis sobre el repositorio GitHub para «systemd» señala que la documentación para la variable «Domains» es en realidad incorrecta y simplemente especifica que el resolvedor DoT debe emplearse para dominios que coincidan con el sufijo especificado («.», en nuestro caso), el cual no significa que este resolvedor deba ser el único empleado para solucionar dominios coincidentes.

Conclusión

Basándonos en las pruebas que llevamos a cabo, solo podemos concluir que existe un defecto en la ejecución del DoT de «systemd-resolved». Claramente, el uso de un resolvedor DoT solo tiene sentido si las consultas DNS se envían exclusivamente a través de un canal cifrado, o si, al menos, el DNS tradicional solo se emplea en respuesta a fallos de DoT (y posiblemente después de que el usuario admita que se debe emplear el DNS tradicional).

Por lo tanto, actualmente recomendamos que si se necesita utilizar DoT, se deben usar aplicaciones alternativas como Stubby hasta que este problema se resuelva con «systemd».

Agradecimientos

Nos gustaría darle las gracias a Sara Dickinson por su ayuda en la depuración de estos problemas.

Más información

Descargo de responsabilidad: Los puntos de vista expresados en esta publicación pertenecen al autor y pueden o no reflejar las posiciones oficiales de Internet Society.

Artículos relacionados

Deploy360 21 agosto 2018

Privacidad DNS en el nuevo Android 9

Recientemente me inscribí en el programa de vista previa para desarrolladores de Android y obtuve la imagen OTA de...

Deploy360 5 julio 2018

Seguimiento de DNSSEC: Ver mapas de implementación

¿Sabía que el programa Deploy360 de Internet Society (Internet Society Deploy360 Programme) proporciona una vista semanal de la implementación...

Deploy360 11 mayo 2018

RIPE 76 en el sur de Francia

La reunión de RIPE 76 comienza la próxima semana en Marsella, que sorprendentemente constituye la segunda reunión de RIPE que...