Alors que nous préparions récemment un article sur la confidentialité DNS, nous avons appris que certaines versions récentes de Linux étaient fournies avec la possibilité d’émettre des requêtes DNS-over-TLS. Nous avons donc décidé d’essayer Ubuntu 18.10 sur un ordinateur portable.
Les versions plus récentes d’Ubuntu utilisent un service de résolution de noms spécifique appelé « system-resolved.service(8) ». Le fichier de configuration « resolved.conf(5) » précise la plupart des détails pour la résolution de noms, notamment les protocoles et les résolveurs à utiliser, tandis que les fichiers de configuration « /etc/systemd/network/*.network » (voir « systemd.network(5) » pour plus de détails) de « systemd-networkd.service(8) » spécifient tous les paramètres spécifiques par lien.
La configuration par défaut de « systemd-resolved » est sélectionnée au moment de la compilation et « /etc/systemd/resolved.conf » contient normalement des lignes commentées décrivant ces valeurs par défaut. Le contenu du fichier susmentionné sur une nouvelle installation d’Ubuntu 18.10 est par exemple :
Comme on peut le déduire à partir du fichier, DNS-over-TLS (DoT) est pris en charge, mais désactivé par défaut. Au moment de la rédaction du présent document, seul le DoT opportuniste est pris en charge conformément au manuel, le résolveur essaiera donc d’abord de résoudre le problème en utilisant le DoT avant de revenir au DNS traditionnel en cas de défaillance, permettant ainsi des attaques de déclassement lorsqu’un attaquant cause intentionnellement une défaillance DoT afin que la résolution de nom revienne au DNS traditionnel.
Nous avons décidé de mettre le DoT à l’essai en modifiant trois variables de configuration dans « /etc/systemd/resolved.conf » :
- Définir « DNS » sur l’adresse IP du serveur DoT
- Définir « DNSOverTLS » sur « opportuniste »
- Définir « Domaines » sur « ~. »
La variable « DNS » contient la liste des adresses IP correspondant au résolveur récursif DoT (vous trouverez une liste des résolveurs récursifs publics ici).
Définir « DNSOverTLS » sur « opportuniste » active le DoT en mode opportuniste – cela signifie que le DoT sera utilisé si possible, mais que le résolveur de stub reviendra au DNS traditionnel en cas d’échec.
Enfin, le fait de définir « Domaines » sur « ~. » indique à « systemd-resolved » de préférer le serveur de noms spécifié à tout serveur DNS par lien pouvant être disponible. Il s’agit d’un paramètre important, car sinon un résolveur DNS par lien non-DoT pourrait avoir priorité sur le résolveur DoT.
Notre configuration résultante devient donc :
Une fois ces modifications appliquées, il faut les appliquer en exécutant la commande suivante :
sudo systemctl restart systemd-resolved
Cela fait, nous avons ensuite décidé de revérifier que le DoT était utilisé plutôt que le DNS traditionnel. Nous avons donc simplement exécuté un renifleur sur l’ordinateur portable Ubuntu et fait une requête DNS pour « fgont.go6lab.si » qui a révélé :
Notre requête a généré un trafic DoT et DNS traditionnel en parallèle. En fait, lorsque nous avons par la suite utilisé un renifleur sur le serveur de noms faisant autorité, il a confirmé que le résolveur local de notre réseau (192.168.3.1) et le résolveur de Cloud-flare émettaient des requêtes pour le domaine ci-dessus.
En réponse à cette constatation, nous avons essayé de comprendre pourquoi le trafic DNS traditionnel était visible en parallèle, au lieu du trafic DoT, ou du moins le trafic DoT suivi du trafic DNS traditionnel, en partant du principe que DoT avait échoué. De plus, pourquoi le résolveur local avait-il été utilisé pour la résolution DNS alors même que la variable « Domaines » indiquait à « systemd-resolved » d’utiliser le résolveur DoT spécifié plutôt que tout autre résolveur.
Il semble donc que la mise en œuvre « systemd-resolved » pour le DoT opportuniste n’utilise pas le DNS traditionnel uniquement à la suite d’échecs du DoT, mais plutôt en parallèle aux requêtes DoT. D’autre part, une discussion sur le référentiel GitHub pour « systemd » indique que la documentation de la variable « Domaines » est en réalité incorrecte et spécifie simplement que le résolveur DoT doit être utilisé pour les domaines correspondant au suffixe spécifié (« . » dans notre cas), ce qui ne signifie pas que ce résolveur doit être le seul employé pour résoudre les domaines correspondants.
Conclusion
Sur la base des tests que nous avons effectués, nous ne pouvons que conclure à une faille dans la mise en œuvre DoT de « systemd-resolved ». Manifestement, utiliser un résolveur DoT n’a de sens que si les requêtes DNS sont envoyées exclusivement sur un canal crypté, ou tout au moins, si le DNS traditionnel est utilisé uniquement en réponse aux défaillances DoT (et éventuellement après confirmation par l’utilisateur que le DNS traditionnel doit être utilisé).
Nous recommandons donc actuellement qu’en cas d’utilisation de DoT, d’autres mises en œuvre telles que Stubby soient utilisées jusqu’à ce que ce problème rencontré avec « systemd » soit résolu.
Remerciements
Nous tenons à remercier Sara Dickinson de l’aide qu’elle nous a apportée pour analyser ces problèmes.
Informations supplémentaires
- Introduction à la confidentialité DNS de l’Internet Society
- Résolveurs publics de confidentialité DNS
- Le comportement pour .~ semble invalide