Aller au contenu

Pourquoi et comment chiffrer ses requêtes DNS sur Linux

Publié le par Maxime Louet
Table des matières

Introduction

Vous pouvez passer directement à la pratique si vous le souhaitez.

Le DNS (Domain Name System, système de noms de domaine) est un gros morceau d’Internet. C’est le protocole qui sert notamment à convertir des noms de domaine en adresses IP.

Traditionnellement, le DNS est non chiffré ; c’est-à-dire que toutes les requêtes que votre ordinateur effectue sont visibles par un certain nombre d’entités, comme votre Fournisseur d’Accès à Internet (FAI), ou n’importe qui sur le même réseau que vous. Comme votre ordinateur effectue une requête DNS pour chaque site que vous visitez, il est très facile de dresser un profil de qui vous êtes, en se basant sur vos habitudes de navigation.

De plus, comme il n’y a aucune vérification d’authenticité des requêtes (qu’apporterait le chiffrement), les requêtes peuvent être altérées. Par exemple, votre FAI peut décider de renvoyer un mauvais résultat pour mechantgouvernement.fr, ce qui vous empêcherait d’y accéder. C’est une pratique très courante : le gouvernement français ordonne aux FAI de bloquer certains sites “illégaux” pour empêcher les visiteurs d’y accéder. Cela porte une atteinte directe au principe de neutralité du net.

Heureusement, il y a des solutions à tout cela !

DoH, DoT, késako ?

Plusieurs mécanismes ont été développés afin de pallier à l’absence de chiffrement du DNS. Je vais vous en présenter deux. Ils n’inventent rien en eux-mêmes, mais se basent sur d’autres protocoles reconnus et utilisés massivement.

DNS-over-HTTPS

Le nom est assez explicite : c’est tout simplement du DNS dans du HTTPS. Pour chaque requête DNS, votre ordinateur va envoyer une requête HTTPS contenant la demande. Le serveur va ensuite répondre via HTTPS également.

HTTPS est très utilisé de nos jours, et se base sur TLS, un protocole de chiffrement reconnu. L’avantage est donc qu’il n’y a presque rien à modifier, puisque tout le monde fait déjà des requêtes HTTPS.

L’autre avantage de cette méthode est qu’elle passe par le port réseau du HTTPS, 443 — logique puisque c’est du HTTPS ! C’est un avantage car dans certains pays la majorité des ports sont bloqués, sauf ceux du trafic Web, 80 (HTTP) et 443 (HTTPS).

DNS-over-TLS

Cette fois-ci, pas de HTTPS, mais le chiffrement est géré par TLS (qui est inclus dans HTTPS).

On a donc le même protocole de chiffrement, mais avec la couche HTTP en moins. Cela permet donc d’avoir des requêtes un peu plus petites que celles avec HTTPS.

L’inconvénient est donc le port dédié : DNS-over-TLS utilise le port 853, que les gouvernements souhaitant contrôler les requêtes DNS de leurs citoyens peuvent demander aux FAI de bloquer.

Cependant, au niveau de la sécurité des requêtes, les deux protocoles sont globalement équivalents.

Configurer DNS-over-TLS sur Linux

Nous allons utiliser DNS-over-TLS, car le logiciel de référence qui implémente le chiffrement DNS sur Linux ne permet pas encore d’utiliser DNS-over-HTTPS, et qu’il n’y a pas de restrictions de port dans mon pays. Afin d’accélérer les requêtes DNS, nous allons également installer un cache DNS qui va permettre de mémoriser les requêtes pour les fournir plus rapidement les fois suivantes.

Vue d’ensemble

Stubby est un résolveur DNS qui implémente DNS-over-TLS. Il va agir d’intermédiaire entre les requêtes DNS de votre ordinateur et la réponse du serveur distant.

Nous allons également configurer dnsmasq pour l’utiliser en tant que cache DNS. Il va mémoriser temporairement les réponses DNS, ce qui lui permettra de répondre plus rapidement la prochaine fois qu’on lui demandera, plutôt que de devoir interroger un serveur distant.

Nous devrons donc configurer notre ordinateur pour qu’il interroge dnsmasq, puis dnsmasq pour qu’il interroge Stubby, et enfin Stubby pour qu’il interroge un serveur distant. De cette manière, dnsmasq pourra mettre en cache les requêtes de Stubby.

Installer Stubby

Installez le paquet stubby avec le gestionnaire de paquets de votre distribution.

Exemple pour Debian/Ubuntu :

# apt install stubby

Nous allons ensuite configurer Stubby. Son fichier de configuration se trouve dans /etc/stubby/stubby.yml. Le fichier par défaut est assez long (500 lignes) mais ce sont principalement des commentaires qui expliquent toutes les options possibles.

Dans un premier temps, modifions le port sur lequel Stubby écoute. Nous allons le faire écouter sur un autre port que celui par défaut (53) car c’est dnsmasq qui se chargera de répondre aux requêtes, c’est donc dnsmasq qui écoutera sur le port 53.

Par défaut, Stubby écoute en local sur le port 53 :

################################ LISTEN ADDRESS ################################
# Set the listen addresses for the stubby DAEMON. This specifies localhost IPv4
# and IPv6. It will listen on port 53 by default. Use <IP_address>@<port> to
# specify a different port
listen_addresses:
  - 127.0.0.1
  - 0::1

Nous allons le faire écouter sur le port 53420 (choisi plus ou moins au hasard) :

listen_addresses:
  - 127.0.0.1@53420
  - 0::1@53420

L’autre partie qui nous intéresse est la configuration des serveurs DNS, les “upstreams”. Ce sont les serveurs distants que Stubby va interroger en DNS-over-TLS.

Par défaut, certains serveurs sont activés, d’autres sont commentés. Libre à vous de laisser la configuration par défaut ou de vous renseigner sur les serveurs publics DNS-over-TLS existants.

Pour ma part, j’utilise les serveurs de Cloudflare:

upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 2606:4700:4700::1111
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 2606:4700:4700::1001
    tls_auth_name: "cloudflare-dns.com"

Le tout est de choisir un serveur rapide et qui respecte votre vie privée, c’est-à-dire qui ne conserve pas d’historique de vos requêtes ! Si grâce au DNS-over-TLS votre FAI ne voit plus vos requêtes DNS, le serveur DNS les voit toujours — et heureusement, sinon il ne pourrait pas y répondre.

Il ne nous reste plus qu’à démarrer Stubby et demander au système de le lancer automatiquement au démarrage :

# systemctl start stubby
# systemctl enable stubby

Notons que ces deux commandes peuvent être condensées en :

# systemctl enable --now stubby

Installer dnsmasq

dnsmasq peut servir à beaucoup de choses (serveur DNS, DHCP…), mais nous l’utilisons ici uniquement comme cache DNS. C’est une pratique assez courante.

Installez le paquet dnsmasq avec le gestionnaire de paquets de votre distribution.

Exemple pour Debian/Ubuntu :

# apt install dnsmasq

Nous devons maintenant indiquer à dnsmasq de rediriger tout ce qu’on lui demande à Stubby. Nous avons configuré Stubby pour écouter sur le port 53420. Disons donc à dnsmasq d’envoyer les requêtes sur ce port !

Son fichier de configuration se trouve dans /etc/dnsmasq.conf.

# Do not read /etc/resolv.conf, use servers below instead
no-resolv

# Use local Stubby server on port 53420
server=127.0.0.1#53420
server=::1#53420

Ensuite, nous devons dire à dnsmasq d’écouter en local sur le port 53 (qui est le port par défaut) :

listen-address=::1,127.0.0.1

Nous allons aussi activer une option qui permet d’utiliser DNSSEC. C’est un mécanisme pour authentifier les réponses DNS. Je ne rentrerai pas dans les détails ici mais je vous conseille de rajouter cette option :

proxy-dnssec

Enfin, je vous recommande d’augmenter la taille du cache de dnsmasq. Par défaut, il met en cache jusqu’à 150 réponses. C’est assez peu compte tenu du nombre de sites qu’on peut visiter en quelques minutes ! Pour ma part, j’ai largement augmenté cette valeur :

cache-size=2000

Voilà ! Démarrons dnsmasq et activons-le au démarrage :

# systemctl enable --now dnsmasq

Demander au système d’utiliser dnsmasq

Lorsque votre ordinateur effectue des requêtes DNS, il utilise les serveurs fournis par le réseau dans lequel vous êtes — le plus souvent, les serveurs de votre FAI — sauf si vous avez modifié ce comportement.

Nous souhaitons utiliser dnsmasq comme serveur DNS, puisqu’il va rediriger les requêtes vers Stubby, qui va se charger d’interroger les “upstreams” de manière chiffrée.

Si votre système utilise NetworkManager — ce qui est probablement le cas — nous devons l’informer de ne pas utiliser les serveurs DNS fournis par le réseau, mais notre propre machine.

Créons un fichier /etc/NetworkManager/conf.d/dns.conf avec le contenu suivant :

[main]
dns=none

Dernièrement, modifions le fichier qui liste les serveurs DNS à interroger pour y renseigner notre propre machine.

Ouvrez /etc/resolv.conf et faites en sorte que le seul nameserver soit 127.0.0.1 :

nameserver 127.0.0.1

Tous les logiciels de votre ordinateur lisent ce fichier pour savoir quel serveur DNS interroger. Avec cette configuration, ils interrogeront le serveur qui écoute en local sur le port 53, c’est-à-dire dnsmasq !

Note sur les navigateurs incluant DNS-over-HTTPS

Certains navigateurs, comme Mozilla Firefox, incluent eux-même un mécanisme pour requêter des serveurs DNS en DNS-over-HTTPS, bien qu’il ne soit pas forcément activé par défaut. Grâce à notre configuration, nous pouvons désactiver ce paramètre : Firefox passera par le système, c’est-à-dire dnsmasq et Stubby, nous aurons donc toujours des requêtes chiffrées. Mais en plus elles seront mises en cache, donc plus rapides !

Conclusion

J’espère que cet article vous aura éclairé sur l’intérêt d’utiliser du DNS chiffré et sur la procédure à suivre sur Linux.

N’hésitez pas à me contacter par e-mail pour tout commentaire, suggestion ou correction !