Donar
El Protocolo DNS-over-TLS en Linux (systemd) Thumbnail
‹ Atrás
Deploy360 10 enero 2019

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

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

‹ Atrás

Artículos relacionados

Cloudflare lanza el servicio de DNS 1.1.1.1 con privacidad, TLS y más
Cloudflare lanza el servicio de DNS 1.1.1.1 con privacidad, TLS y más
Deploy36012 abril 2018

Cloudflare lanza el servicio de DNS 1.1.1.1 con privacidad, TLS y más

El lanzamiento del nuevo servicio de resolución de DNS 1.1.1.1 de Cloudflare represente el avance significativo en el area del DNS por...

IETF 100 Hackathon: Brinda innovación con código operativo al IETF
IETF 100 Hackathon: Brinda innovación con código operativo al IETF
Deploy36017 octubre 2017

IETF 100 Hackathon: Brinda innovación con código operativo al IETF

¿Está interesado en contribuir con el código de ejecución al Grupo de Trabajo de Ingeniería de Internet (IETF)? ¿ Observó...

El KRACK demuestra que necesitamos un cifrado más fuerte para Internet
El KRACK demuestra que necesitamos un cifrado más fuerte para Internet
Confianza16 octubre 2017

El KRACK demuestra que necesitamos un cifrado más fuerte para Internet

Una gran debilidad en la seguridad de Wi-Fi acaba de hacerse pública. El Key Reinstallation Attack (KRACK) puede romper el...

Únase a la conversación con miembros de Internet Society alrededor del mundo