Résolveur public de DNS-sur-TLS Yeti

Il existe un nouveau résolveur DNS public DNS-sur-TLS, et il utilise la racine Yeti. Des explications supplémentaires seraient bienvenues ? Les voici.

Le service

Il existe un nouveau résolveur DNS public DNS-sur-TLS, et il utilise la racine Yeti. Des explications supplémentaires seraient bienvenues ? Les voici.

Tout d’abord, expliquons le terme de « DNS-sur-TLS ». Le protocole DNS (Domain Name System – système de noms de domaine) est une composante essentielle de l’infrastructure d’Internet. On y a recours pour la quasi-totalité des transactions sur Internet. Par défaut, elle ne fournit aucune confidentialité (voir RFC 7626 pour une discussion complète des problèmes de confidentialité DNS). Parmi ses faiblesses, il y a le fait qu’actuellement, les requêtes et les réponses DNS sont envoyées en clair, de sorte que n’importe quel mouchard peut découvrir que vous avez un intérêt pour www.aa.org ou pour jane-smith-server.accounting.company.example. Afin de résoudre ce problème spécifique, une norme de chiffrement des requêtes et des réponses DNS a été élaborée, utilisant le célèbre protocole TLS (Transport Layer Security). La norme se trouve dans RFC 7858.

À ce jour, il n’existe qu’un nombre très limité de résolveurs DNS qui acceptent le système « DNS-sur-TLS ». Le résolveur FAI classique ou les grands résolveurs publics ne l’utilisent pas. De manière regrettable, cela est également le cas de résolveurs affirmant fournir un service pour les personnes qui ne font pas confiance aux autres résolveurs. (Voir une liste mise à jour des résolveurs publics existants).

Et Yeti, dans cette histoire, de quoi s’agit-il ? Yeti est une racine DNS alternative qui se focalise non pas sur la création de TLD factices et sur le fait de les vendre, mais sur des expérimentations techniques sur le service racine DNS, expérimentation qui ne peut être effectuée sur la racine « réelle », qui est bien trop sensible. Notez qu’il n’existait aucun résolveur Yeti public. Afin d’utiliser la racine Yeti, la seule manière de procéder était de configurer votre résolveur pour  interroger la racine Yeti.

Néanmoins, tout d’abord, un avertissement : Yeti est une expérimentation technique, pas de nature politique. Soyez conscients que les requêtes DNS aux serveurs racine Yeti sont enregistrées et étudiées par des chercheurs. (Il en va de même pour la racine « réelle » par ailleurs, sans parler des utilisations officieuses telles que MoreCowBell).

Étant donné qu’il existe peu de résolveurs DNS-sur-TLS, et afin de collecter plus d’informations sur l’expérience, nous avons installé un résolveur DNS-sur-TLS public utilisant la racine Yeti. Il répond sur le port DNS-sur-TLS classique, 853, sur dns-resolver.yeti.eu.org. Il s’agit d’IPv6, ce qui est normal pour Yeti, dont les serveurs de nom utilisent exclusivement IPv6 .

Deux avertissements néanmoins : il s’agit d’un service expérimental, géré exclusivement sur le principe du « au mieux », et étant donné qu’il envoie des requêtes à la racine Yeti, les données de l’utilisateur sont stockées et analysées. Ainsi, il s’agit de tester des techniques visant à améliorer la confidentialité, non pas de fournir une confidentialité réelle. (Nous serions ravis de trouver un résolveur DNS public garant de la confidentialité, avec des fonctionnalités DNS-sur-TLS, etc.)

Utilisation

Actuellement, la plupart des clients DNS ne sont pas compatibles avec le système DNS-sur-TLS. Si vous souhaitez l’utiliser et ne connaissez pas de clients DNS-sur-TLS, vous pouvez en trouver certains listés sur le portail DNS privacy.

Une manière d’utiliser ce service en tant que transitaire pour un résolveur local. Le serveur Unbound peut le faire avec une installation telle que :

server: 
 ... 
 auto-trust-anchor-file: "autokey/yeti-key.key" 
 ssl-upstream: yes

forward-zone:
name: « . »
#forward-host: « dns-resolver.yeti.eu.org » # Or the IP address:
forward-addr: 2001:4b98:dc2:43:216:3eff:fea9:41a@853
forward-first: no

Si vous avez installé les utilitaires getdns (par exemple via le paquetage Debian getdns-utils), vous pouvez tester le résolveur avec la commande getdns_query :

% getdns_query @2001:4b98:dc2:43:216:3eff:fea9:41a -s -l L www.eff.org AAAA 
... 
"just_address_answers": 
 [ { "address_data": , 
 "address_type": ...

Si vous utilisez le proxy Stubby, vous pouvez le lancer avec :

% stubby @2001:4b98:dc2:43:216:3eff:fea9:41a -L

(ou arguments similaires du fichier de configuration Stubby.)

Nous vous souhaitons bonne chance avec ce service et, s’il y a le moindre problème, n’hésitez pas à demander plus de détails ou de l’aide sur les listes de diffusion Yeti.

Installation

Le résolveur public en tant que tel est installé avec Unbound. Voici sa configuration

server: 
 use-syslog: yes 
 root-hints: "yeti-hints" 
 auto-trust-anchor-file: autokey/yeti-key.key 
 interface: 2001:4b98:dc2:43:216:3eff:fea9:41a@853 
 qname-minimisation: yes 
 harden-below-nxdomain: yes 
 harden-referral-path: yes 
 harden-glue: yes 
 ssl-service-key: "/etc/unbound/tls-server.key" 
 ssl-service-pem: "/etc/unbound/tls-server.pem" 
 ssl-port: 853 
 access-control: ::0/0 allow 
 log-queries: yes

Comme vous pouvez le constater, les requêtes (nom de requête et adresse IP source) sont enregistrées localement (voir ci-dessus l’avertissement relatif à la confidentialité) mais ne sont pas transmises. Le nom de requête est envoyé aux coordinateurs Yeti.