Politique de dns.shaftinc.fr

(et configuration client)

Cette page décrit la politique du résolveur dns.shaftinc.fr et documente (partiellement) comment l'utiliser.

Politique

dns.shaftinc.fr fourni un service DNS sur TLS (DoT) et DNS sur HTTPS (DoH). Ces 2 techniques permettent d'avoir un canal sécurisé avec le résolveur DNS, les requêtes sont donc protégées de l'écoute d'un tiers, mais pas contre la personne gérant le service (moi en l'occurence). L'utiliser revient donc à me faire confiance, à l'aune de cette politique ainsi qu'à l'évaluation de cette dernière.

Le résolveur dns.shaftinc.fr :

Configuration client

Note : Pour les administrateur·trice·s qui souhaiteraient lancer un service similaire, une documentation technique est disponible.

Cette documentation est en partie reprise d'un précédent billet sur le sujet, mais adaptée à l'utisation de dns.shaftinc.fr. Pour DoT, je ne documente essentiellement qu'un type d'utilisation (qui me semble le plus adapté), libre à vous d'utiliser d'autres outils si vous le souhaitez. Pour DoH, je documente pour l'instant la configuration dans les navigateurs, à défaut d'autres solutions. Dans l'idéal, je considère qu'il faut privilégier l'utilisation de DoT et se rabattre sur DoH si cela est impossible (port 853 bloqué par exemple).

Accès rapide

DoT

Linux (et Windows, Mac…)

Le meilleur client disponible est de loin Stubby. Simple à configurer, à jour… Il a ceci dit un principal défaut : en tant que résolveur minimum, il ne dispose pas de cache. Pour pallier à cela, on va lui adjoindre Unbound, qui lui possède un cache (historiquement, la partie TLS et TCP d'Unbound est très faible quand il est utilisé comme forwarder, cela s'est normalement amélioré depuis la version 1.13 avec la possibilité de réutiliser des connections TCP. Stubby garde néanmoins l'avantage avec la gestion de TCP Fast Open — disponible sous Unbound mais il doit être compilé avec l'option, ce qui n'est pas le cas sous Debian notamment, la possibilité d'utiliser plusiuers résolveurs...). Unbound possède plein de chouettes options outre son cache (gérer un domaine local, bloquer les pubs et trackers…). Le fonctionnement est le suivant : sur la machine locale, Unbound est le résolveur utilisé par le système mais il transmet toutes les requêtes à Stubby qui va gérer la partie TLS et discuter avec le serveur DoT, ce qui donne le schéma suivant :

Il faut donc installer donc les 2 logiciels :

		# apt-get install unbound stubby

Configurons Stubby. Il faut éditer /etc/stubby/stubby.yml. Dès l'installation, toute la configuration TLS est pré-réglée correctement et quelques serveurs DoT sont déjà configurés dans la section DEFAULT UPSTREAMS. Commenter l'ensemble des entrées (à moins que vous ne souhaitez utiliser un des résolveurs proposés) et mettre les informations relatives au résolveur pour une authentication stricte. Attention ceci dit, Stubby utilise la syntaxe YAML, il faut donc respecter l'indentation particulière (2 espaces ici) :

upstream_recursive_servers:
		  - address_data: 2001:bc8:2c86:853::853
		    tls_auth_name: "dns.shaftinc.fr"
		    tls_pubkey_pinset:
		      - digest: "sha256"
		      value: ilee9nHBVT0DVWER1VDA+0NCaYd25zVvP0C1Jb4gCIc=

À noter que l'option tls_auth_name, qui permet d'authentifier le résolveur via le nom présenté dans le certificat (méthode par ADN ou Authentication Domain Name pour reprendre les termes du RFC 8310), est optionnelle dans la mesure où l'on fourni également le SPKI via tls_pubkey_pinset. Ceci dit, cela apporte une deuxième authentication, ce qui est appréciable en terme de sécurité. Stubby n'est malhereusement pas capable à l'heure actuelle d'utiliser DANE.

Ne reste plus qu'à lui donner le port d'écoute d'où viendront les requêtes d'Unbound :

listen_addresses:
		  - 127.0.0.1@8053
		  - 0::1@8053

Le port est choisi au hasard, et un autre peut être pris. L'important est de donner le même à Unbound.

Comme le montre la configuration par défaut, Stubby est capable d'avoir plusieurs serveurs DoT configurés en même temps, et il est donc possible d'utiliser dns.shaftinc.fr avec d'autres serveurs. Dans ce cas là, il envoie les requêtes à chaque serveur et prend la première réponse qui arrive (technique de round robin). Le comportement de Stubby se configure alors avec le paramètre round_robin_upstreams.

Configurons ensuite Unbound. Sous Debian & dérivés, créer un fichier .conf dans /etc/unbound/unbound.conf.d/ (Sous Arch & cie, éditer directement /etc/unbound/unbound.conf ou créer un autre fichier et dire à Unbound de le charger via la directive include dans son fichier de configuration principal — Attention, dans ces terres Unbound est probablement chrooté. Ce n'est pas le cas sous Debian). Peu de paramètres à passer : on l'autorise d'abord à interroger le localhost (ce qu'il n'est pas capable de faire par défaut, étant censé être à l'écoute sur 127.0.0.1 et ::1), puis on lui indique les adresses et ports où écoute Stubby afin de lui transmettre les requêtes. Ce qui donne :

server:
			do-not-query-localhost: no
		forward-zone:
			name: "."
			forward-addr: 127.0.0.1@8053
			forward-addr: ::1@8053

En l'état, cette configuration ne sera utile que sur la machine où elle est installée. Pour en faire profiter le réseau local, il faut ajouter quelques paramètres à Unbound. La section server: devient :

server:
			do-not-query-localhost: no
			interface: 0.0.0.0@53
			interface: ::0@53
			access-control: 192.168.0.0/24 allow
			access-control: 2001:db8:cafe:cafe::/64 allow

Les IPs sont bien évidemment à ajuster en fonction de la configuration locale. Pensez aussi à ouvrir le port 53 (TCP et UDP) dans votre pare-feu pour accepter les requêtes venant des machines du réseau. Il est également possible de ne pas écouter sur toutes les adresses disponibles, auquel cas il faut bien penser à ajouter le localhost dans la liste des interfaces :

server:
			...
			interface: 127.0.0.1@53
			interface: ::1@53
			interface: 192.168.0.1@53 # L'adresse IPv4 locale souhaitée
			interface: 2001:db8:cafe:cafe::1@53 # L'adresse IPv6 souhaitée
			...

Une fois ces 2 logiciels configurés, ne reste plus qu'à :

Android et dérivés

Android embarque un client DoT depuis la version 9 (Pie) sortie mi-2018. Pour l'utiliser, se rendre dans les paramètres réseaux avancés (ou chercher DNS dans le champ de recherche des paramètres. La configuration ressemble à ceci :

Malheureusement, vu le taux de déploiement minable d'IPv6 chez les FAIs mobile, il serait étonnant que dns.shaftinc.fr soit disponible. Il reste d'autre résolveurs DoT disponible (dns.hostux.net, dot.bortzmeyer.fr, et plein d'autres encore).

personalDNSfilter

Terminons cette section DoT en mentionnant une application Android plus sympathique que les paramères systèmes. personalDNSfilter est un bloqueur de publicité disponible pour Android et qui, comme son nom l'indique judicieusement, utilise le DNS pour parvenir à ses fins. Pour ce faire, il crée un VPN local par lequel vont transiter les requêtes en les filtrant via des listes prédéfinis (il est bien évidemment possible de gérer ces listes et d'en ajouter ou en enlever). Ce logiciel présente 2 avantages :

L'interface n'est pas la plus belle au monde, mais la configuration est relativement simple. En fonction de votre version d'Android (c'était le cas sous Android 10, ça ne l'est plus sous Android 12), la première étape va consister à vérifier que le système est configuré pour utiliser le résolveur fourni par le réseau, ce qui doit être la configuration par défaut d'Android :

Dans l'application, cliquer sur le bouton d'édition à côté de l'adresse IP :

De là, activer l'option Désactiver la découverte... et supprimer le bloc d'adresse de résolveur DoT configurés par défaut :

Il n'y a plus qu'à renseiger les infos de dns.shaftinc.fr :

[2001:bc8:2c86:853::853]::853::DOT::dns.shaftinc.fr

Il est possible d'utiliser DoH à la place :

[2001:bc8:2c86:853::853]::443::DOH::https://dns.shaftinc.fr/

Une fois configuré, ne reste qu'à appuyer sur le bouton Redémarrer dans l'application. Afin de vérifier que tout fonctionne, il doit y avoir une petite clé dans la zone de notification du système et une notification (sous Android 9 tout du moins) :

À noter que je n'ai testé personalDNSfilter que sous Android 9 et 10 (enfin /e/, mais sous ces bases). Je suis preneur de retours sur des versions inférieures de l'OS (il est compatible Android 4.0+). Les captures ont été faites sous Android 9, le thème sombre s'améliore un peu sous Android 10 en terme de lisibilité.

DoH

Pour les machines de bureaux, les principaux clients DoH sont pour l'instant les navigateurs Web. Il est prévu que Stubby soit compatible dans une future version et que Windows le soit également (fin 2021 normalement). En attendant, cette documentation traitera le cas de Firefox et de Chrome (et ses rejetons).

Firefox (& Thunderbird)

Sous Firefox, au moins depuis la version 68 et peut-être avant — les notes de versions de Firefox ne sont pas un modèle d'exhaustivité — le paramétrage de DoH se fait dans la section Paramètres réseaux des Préférences :

Il n'y a plus qu'à activer DNS sur HTTPS, choisir un fournisseur personnalisé et entrer l'URL : https://dns.shaftinc.fr/ :

Par défaut, Firefox est configuré pour se replier sur le résolveur du système si la résolution DoH échoue. Pour passer en mode strict — sans repli donc — il faut se rendre dans about:config et passer le paramètre network.trr.mode à 3. Il faut également indiquer l'adresse du résolveur (pour rappel : 2001:bc8:2c86:853::853) dans le paramètre network.trr.bootstrapAddress. Ce dernier est facultatif depuis Firefox 74, mais je le conseille vivement. Au final, on a :

À noter que le client mail Thunderbird, partageant une bonne partie de son code source avec Firefox, est également capable d'utiliser DoH depuis une version indéterminée (peut-être quelque part dans la branche 78.x, peut-être avant, je n'ai rien trouvé en regardant les principales notes de versions). Le paramétrage et les options disponibles sont strictement identiques à Firefox

Chrome & ses dérivés

Chrome est compatible DoH depuis la version 83 (sortie en mai 2020) sous Windows et macOS. Sous Android aussi depuis fin 2020 normalement. Après une longue attente, le support de DoH est disponible sous Linux, et en particulier sous Debian. Lors de la 1ère rédaction de cette page, en août 2021, DoH n'était pas disponible dans Chromium v92. Bref, sous Chromium/Chrome, rendez-vous dans les Paramètres, choisir Confidentialité et sécurité, choisir Sécurité (ou bien rendez-vous en chrome://settings/security). De là, c'est dans les paramètres avancés, activez Utiliser un DNS sécurisé, cochez Avec, choisir Personnalisé et entrez l'URL du service. On obtient :

Capture d'écran de l'interface de Chromium

Dans Edge, navigateur désormais Chromé, c'est sensiblement la même chose :