Journal Et toi, tu résous comment tes requêtes DNS ?

Sommaire

• Introduction
• Le DNS, quelques rappels sur son fonctionnement
  • Rôle du DNS
  • La hiérarchie dans les noms de domaines
  • C'est l'heure du TP !
  • DNSSEC / DoT-DoH
  • Mensonge
  • Conclusion
• Résolveur et cache DNS
  • Utilités
  • Les différentes possibilités techniques
    • Le résolveur DNS de son FAI
    • Résolveur externe : services commerciaux
    • Résolveurs externes : services associatifs
    • Résolveur interne
    • Résolveur interne + résolveur externe
• Conclusion

Salut les moule·e·s,

Introduction

Ce journal est plus ou moins une réponse à chaque discussion où il est question de contournement de la "censure" du gouvernement demandant aux FAI principaux de ne plus résoudre certains noms. Il est notamment amplement inspiré d'une discussion que j'ai eu avec Stéphane Bortzmeyer lors d'un précédant Capitole du Libre ou on a passé en revue les différentes manières de résoudre ses requêtes DNS. Je le remercie chaleureusement pour cet entretien ainsi que pour sa relecture du présent journal.

Le DNS, quelques rappels sur son fonctionnement

Rôle du DNS

Internet est architecturé autour du protocole TCP/IP, dans lequel les machines communiquent par l'intermédiaire de leur adresse IP (ce qu'on peut comparer à des humains qui ne communiqueraient que par leur numéro de téléphone). Le DNS (Domain Name System) permet d'associer un nom à ces adresses IP, ce qui a plusieurs avantages :

• ça permet de s'en souvenir plus facilement (www.linuxfr.org est plus facile à retenir que 213.36.253.103)
• ça offre une indirection (le jour où LinuxFR.org change d'hébergeur et donc d'adresse IP les utilisateurs n'auront pas à changer leurs marque-page)
• ça permet à un détenteur de nom de domaine de donner différentes informations selon les services offerts (signature, IP du serveur officiel en charge des emails… )

La hiérarchie dans les noms de domaines

Rappelons également le principe de la lecture de droite à gauche des noms de domaine : www.linuxfr.org est un nom complet de domaine (on dit "pleinement qualifié", FQDN en Anglais) dont le premier niveau (TLD en Anglais) est .org, le nom de domaine principal est linuxfr (qui techniquement est un sous-domaine de .org), et www un sous-domaine de linuxfr. En fin de comptes tout le monde est un sous-domaine du parent, puisque même .org est un sous-domaine de root. On a bien à faire à une organisation en arbre.

Pour connaître son adresse IP il faut donc s'adresser respectivement :

• aux serveurs racine du DNS pour leur demander qui est en charge (on dit plutôt "a autorité") du .org
• aux serveurs du .org on va leur demander a leur tour qui a autorité sur linuxfr.org
• en enfin au serveur qui a autorité sur linuxfr.org on lui demandera quelle est l'adresse de la machine servant le sous-domaine www.

C'est l'heure du TP !

Une des commandes dédiées à l'exploration des DNS est dig. Vous pouvez taper dig www.linuxfr.org par exemple pour voir son IP:

;; ANSWER SECTION:
www.linuxfr.org.        900     IN      CNAME   prod.linuxfr.org.
prod.linuxfr.org.       900     IN      CNAME   oups.linuxfr.org.
oups.linuxfr.org.       900     IN      A       213.36.253.103

www est un alias sur prod qui est un alias sur oups, mais au final on a bien notre adresse IP : 213.36.253.103
Tapez cette adresse dans votre butineur préféré, vous retomberez sur … oups !. Bon c'est normal, pour diverses raisons (certificats HTTPS, reverse-proxy…) on ne peut quasiment plus browser le web directement en IP. Mais c'est pas grave, vous avez compris le concept.

Super mais d'où sort cette adresse ? Qui nous l'a donnée ?

Demandons alors à dig d'enquêter pour nous : dig +trace +additional www.linuxfr.org. Là dig va remonter à la sources des serveurs DNS racine, et nous montrer la redescente :

• serveur DNS racine
• serveur .org
• serveur linuxfr.org

La sortie est verbeuse mais on peut trouver tout le cheminement via ces extraits.

On va donc attaquer les root servers, et pour ça il nous faut leur adresse IP. C'est facile, elles sont fixes, connues et présentes en dur dans le code dans tous les logiciels de résolution DNS.

.                       86396   IN      NS      l.root-servers.net.
.                       86396   IN      NS      m.root-servers.net.
.                       86396   IN      NS      a.root-servers.net.
.                       86396   IN      NS      b.root-servers.net.
.                       86396   IN      NS      c.root-servers.net.
.                       86396   IN      NS      d.root-servers.net.
.                       86396   IN      NS      e.root-servers.net.
.                       86396   IN      NS      f.root-servers.net.
.                       86396   IN      NS      g.root-servers.net.
.                       86396   IN      NS      h.root-servers.net.
.                       86396   IN      NS      i.root-servers.net.
.                       86396   IN      NS      j.root-servers.net.
.                       86396   IN      NS      k.root-servers.net.

Ensuite on va demander à ces serveurs qui est en charge du .org

org.                    172800  IN      NS      a0.org.afilias-nst.info.
org.                    172800  IN      NS      b0.org.afilias-nst.org.
org.                    172800  IN      NS      c0.org.afilias-nst.info.
org.                    172800  IN      NS      b2.org.afilias-nst.org.
org.                    172800  IN      NS      a2.org.afilias-nst.info.
org.                    172800  IN      NS      d0.org.afilias-nst.org.
;; Received 809 bytes from 192.112.36.4#53(g.root-servers.net) in 32 ms

On voit au passage le nom et l'IP du root serveur utilisé (g dans mon cas, mais si vous refaîtes la manip par vous même il y a des chances que ce soit un autre qui soit utilisé dans votre cas). On peut leur demander qui a autorité sur linuxfr.org:

linuxfr.org.            3600    IN      NS      x.ns.joker.com.
linuxfr.org.            3600    IN      NS      y.ns.joker.com.
linuxfr.org.            3600    IN      NS      z.ns.joker.com.
;; Received 605 bytes from 199.249.112.1#53(a2.org.afilias-nst.info) in 27 ms

Et maintenant on peut demander le www:

www.linuxfr.org.        900     IN      CNAME   prod.linuxfr.org.
prod.linuxfr.org.       900     IN      CNAME   oups.linuxfr.org.
oups.linuxfr.org.       900     IN      A       213.36.253.103
;; Received 98 bytes from 194.245.103.13#53(x.ns.joker.com) in 27 ms

Ça y est, on a bien l'IP qu'on cherche : 213.36.253.103. Le résultat est le même, sauf que là on a bien vu les étapes nécessaires à la résolution du DNS www.linuxfr.org

DNSSEC / DoT-DoH

La résolution DNS est un sujet technique assez complexe avec notamment, comme à peu près tout ce qui touche aux échanges sur Internet, des soucis d' authenticité et de fiabilité. Les technologie DNSSEC utilise la cryptographie à clé publiques et privées pour assurer l'authenticité de la réponse. De leur côté DoT et DoH sont deux technologies (respectivement basées sur TLS et HTTPS) qui assurent la confidentialité en chiffrant les échanges.

Mensonge

On parle souvent de DNS "menteur" et afin de reprendre cette expression dans ce journal, on va le définir simplement : un résolveur DNS est dit "menteur" quand il ne donne pas l'IP réelle associé au domaine suite à l'application d'une politique des mainteneurs. On peut citer par exemple l'envie de bloquer les publicités, de bloquer certaines catégories de sites. Dans ces cas, le resolveur donnera une réponse autre qu'un autre resolveur aurait donné simplement en suivant l'algorithme de résolution vu précédemment.

Conclusion

Pour résoudre une adresse DNS il nous faut utiliser ce qui s'appelle un résolveur récursif, c'est à dire un programme qui est capable de faire ce cheminement, tout en respectant la politique mise en place localement.

Résolveur et cache DNS

Utilités

La manipulation faite avec le TP pourrait très bien être embarquée dans n'importe quel outil ayant besoin du DNS (comme le browser web par exemple), mais il y aurait plusieurs inconvénients à ça :

• ce serait lent (on a vu qu'une seule requête prend plusieurs centaines de milli secondes)
• ce serait redondant (on passerait notre temps à re-résoudre encore et toujours les mêmes DNS)
• ce ne serait pas centralisé (par exemple il serait compliqué d'ajouter notre propre DNS "maison", ni d'appliquer une politique globale)
• on ne profiterait pas de la mise en cache commune à tous les utilisateurs. En effet le protocole DNS intègre la notion de TTL (Time To Live) qui explicite le temps qu'on peut retenir l'information sans avoir à la redemander. Avec un service centralisé, le premier utilisateur qui fait la reqête "offre" aux autres le temps de réponse, ainsi que quelquepart une charge moindre sur le réseau global.

Pour cela on centralise en général la résolution DNS d'un réseau via un logiciel spécialisé. Dans le monde du logiciel libre, on peut citer bind9 et unbound, knot resolver ou Power DNS Toute la question réside ensuite sur "Qui fait tourner ce logiciel ? Qui a la main dessus ?".

Les différentes possibilités techniques

Pour cela il existe différentes solutions qu'on utilise tous sans forcément en être au courant.

Le résolveur DNS de son FAI

C'est le cas le plus banal. À la connexion, votre FAI vous fourni l'adresse de son propre résolveur, il n'y a plus qu'à l'utiliser. Bien évidemment toutes les box font ça par défaut.

• Avantages : c'est fiable, performant, sans aucune maintenance à faire de notre côté
• Inconvénients : il n'y a pas ou peu de confidentialité, et surtout aucune maîtrise sur les politiques appliquées. Selon le FAI, il sera même sommé par l'État de mentir sur certains sites ("piratage", pédopornographie, harcèlement, terrorisme…)

Résolveur externe : services commerciaux

Une autre solution est d'utiliser un résolveur externe, payant ou pas. Les fameux 8.8.8.8 de Google ou 1.1.1.1 de CloudFlare en sont les exemples les plus connus.

• Avantages : toujours aucun entretien à faire, on utilise l'IP donnée et c'est tout. Ces serveurs sont en général très rapides et tout aussi fiables que ceux du FAI.
• Inconvénients : de la même manière que ceux du FAI, on n'a pas vraiment accès à la politique interne de ces résolveurs. Depuis peu ils obéissent aux injonctions du gouvernement français, en plus d'autre gouvernements (états-unien pour la plupart d'entre eux). De même la confidentialité n'est assurée en rien.

Résolveurs externes : services associatifs

Il existe des résolveurs externes maintenus par des associations tels que 80.67.169.12 et 80.67.169.40 qui sont les résolveur publics de la FDN.
Il existe également une liste de résolveurs sur les chatons.org.

• Avantages : toujours aussi facile à utiliser, ils assurent généralement une bien meilleure transparence sur la politique utilisée. Les personnes en charge sont joignables, on peut imaginer que les politiques appliquées sont votées etc. Idem pour la confidentialité, il est en général aisé de poser des questions, de savoir exactement ce qui est gardé etc. Par exemple les résolveurs de la FDN affichant qu'ils utilise DNSSEC et DoT-DoH, on sait que la confidentialité est maximale.
• Inconvénient : la performance et la fiabilité seront peut-être un peu en deça des services commerciaux, notamment à cause de moyens limités. De même, le fait qu'il y ait moins d'utilisateurs fera le cache sera moins fourni.

Résolveur interne

Dernière solution… se démerder tout seul ! Oui, c'est tout à fait possible, parfaitement autorisé. C'est le comportement par défaut de pfSense par exemple. Pi-Hole ne le fait pas par défaut mais propose une documentation pour ajouter unbound et donc profiter de la résolution récursive en interne.
De manière générale ça consistera à mettre unbound ou bind9 sur son réseau local et d'y faire pointer l'ensemble des clients.

• Avantage : on a enfin la main sur la politique. On peut "mentir" ou pas selon ses propres critères (contrôle parental, politique interne entreprise…). Il peut également avoir un certain plaisir à résoudre soi-même ses requêts en dépendant le moins possible de services externes. Ce n'est pas non plus la panacée, le chaînage DNSSEC entre les différents serveur DNS n'étant jamais garanti, ou le FAI voyant de toutes façons passer les échanges non chiffrés (absence de DoT-DoH), mais aussi de toutes façons l'accès à l'IP finale.
• Inconvénients : niveau performances et fiabilité on est sûrement dans les pires dispositions. Cela dit je le fais personnellement depuis des années via l'utilisation de pfSense et je n'ai pas souvenir de soucis particuliers. À l'échelle domestique le temps de résolution n'est pas vraiment un soucis, et la fiabilité n'est ni plus ni moins que celle de votre fournisseur d'électricité ou de votre FAI.

Résolveur interne + résolveur externe

Enfin il existe une solution intermédiaire entre les deux dernières propositions : un résolveur local (dont on contrôle la politique) mais qui fait suivre les questions dont il n'a pas la réponse à un résolveur public (sympa de préférence). On profite alors de sa mémoire et de ses performances, tout en gardant le contrôle local. Tous les logiciels libres de résolveurs DNS savent faire cela.

Conclusion

La résolution DNS est un sujet technique autant que politique. Les différents façons de résoudre une requête DNS offrent toute la palette de saveurs entre fiabilité, performance, confidentialités et maîtrise de la politique appliquée.

Pour l'hygiène de sa vie numérique (ainsi que celle des siens, la moule LinuxFR.org étant souvent en charge du maintient du réseau local domestique) il est important de connaître, et éventuellement de choisir sa propre politique de résolution des noms, et donc de choisir la technique adaptée.

Et toi ? Tu résous comment tes requêtes DNS ?