Présentation d'Odin

Cela fait quelques jours que je n’ai plus écris d’article sur ingnu. Peut-être même attendiez-vous fébrilement devant votre flux RSS une manifestation quelconque d’activité sur ingnu. En tout cas, ça me plait bien d’y croire :) Bref.

J’ai consacré ces derniers jours au développement d’ODDNS, nom de code Odin. C’est un projet dont j’ai vaguement lancé l’idée il y a quelques temps mais Grovi, habitué du serveur IRC de ingnu, m’a pourtant fait part d’une certaine attente, abordée notamment sur la radio Ici et Maintenant (si vous me lisez et que vous possédez un enregistrement de l’émission dans laquelle on a parlé d’ingnu ou de ODDNS, n’hésitez pas à me l’envoyer !). Une alternative Libre, totalement décentralisée et neutre au système DNS actuel, dans ces temps de censure et de blocage par DNS, représente à mon sens une réponse vitale et urgente. C’est pourquoi je vous ai lâchement abandonné ces derniers jours.

Je reviens aujourd’hui avec la création d’une nouvelle catégorie du blog, ODDNS, dans laquelle je vais régulièrement publier des informations relatives au projet, cet article en étant le premier représentant.

Présentation

ODDNS se présente comme une sorte de surcouche à DNS. Quand vous voulez vous connecter à ingnu.fr, votre navigateur demande d’abord à un serveur DNS quelle est l’adresse IP associée à ce domaine, un peu comme si vous cherchiez un nom dans votre répertoire avant de l’appeler : votre téléphone affiche le nom de votre correspondant, mais n’appelle pas son nom : le téléphone compose son numéro. DNS, c’est le même principe.

Or, les gouvernements (voire des entreprises privées qui en font la demande) ont la possibilité d’empêcher les internautes d’accéder à certains noms de domaine, de manière plus ou moins arbitraire. Les sites hébergés sur ces noms de domaines ne sont plus accessibles via le nom de domaine. Ils restent toutefois accessibles via leur adresse IP.

ingnu.fr n’est pas le seul domaine que j’héberge. Pour répondre à plusieurs domaines différents en utilisant un seul serveur HTTP(S), je fais appel aux hôtes virtuels : le serveur envoi au client les pages qui correspondent au domaine qu’il a demandé. Par conséquent, si mon domaine est inaccessible et que le client cherche à contacter mon serveur web directement via son adresse IP, il ne tombera pas sur le site voulu, puisque mon serveur web ne saura pas quelle page lui envoyer.

Enfin, autre problème posé par le système DNS actuel, s’assurer l’utilisation pour soi de son propre nom de domaine implique de mettre la main au portefeuille. Nous ne sommes que locataires de nos noms de domaines.

Voilà les problématiques auxquelles répond ODDNS. Puisque les internautes se partagent les informations relatives à un domaine, il n’est pas possible de le bloquer. La censure au niveau DNS est donc rendue parfaitement inutile. D’autre part, le chiffrement des informations transitant entre un client et un serveur assure la confidentialité des requêtes. Enfin, on redevient propriétaire de ses noms de domaine : les registrars deviennent inutiles, tout comme l’ICANN. Internet retrouvera un peu de sa neutralité.

Mes choix de développement

Il y avait beaucoup de façons différentes de créer ODDNS. J’aurai pu m’appuyer sur torrent, XMPP, ou écrire un module pour chaque serveur DNS existant. J’ai fais un choix qui peut paraître surprenant, voire laisser penser à un manque de sérieux, ou je ne sais quelle autre mauvaise intention qu’on me prêterait. J’ai décidé de développer ODDNS en PHP, et ce pour un certain nombre de raisons.

Pour commencer, PHP est disponible pour toutes les plateformes. L’application sera parfaitement portable. Ensuite, les bibliothèques disponibles pour PHP (notamment PEAR que j’utilise autant que faire se peut) correspondent bien à l’usage de ODDNS. Je n’ai encore trouvé aucune fonctionnalité à ODDNS qui requiert une bibliothèque qui n’existe pas déjà.

Une autre raison majeure de l’utilisation de PHP est la future présence dans le paquet logiciel d’une interface web codée en PHP, qui exploitera massivement les bibliothèques ODDNS que j’ai conçu. Cette interface web permettra de gérer tous les aspects de l’installation d’ODDNS : démarrage, arrêt et redémarrage du serveur, mise à jour client et serveur, statistiques, infrastructure de clés publiques, absolument tout. Cette interface web viendra compléter les scripts exécutables en console.

Ensuite, là où certains auraient opté pour TLS/SSL, j’ai décidé d’implémenter le chiffrement via GNUPG. Pour commencer, parce que c’est 100% Libre. Ensuite, par ce que je peux chiffrer des chaînes de n’importe quelle taille (si un message entre un client et un serveur dépasse la taille d’un certificat TLS, le message doit être scindé, ce qui complique inutilement le développement). D’autre part, GNUPG me permet de chiffrer et signer les messages, ce qui me permet d’implémenter une notion d’hôtes de confiance. Je sais que TLS le permet aussi, mais puisque GNUPG l’intègre, autant s’en servir.

État des lieux

J’ai développé un certain nombre de classes. Certaines d’entre elles sont préfixées “ODDNS”. Les autres sont conçues pour être réutilisables à volonté. C’est notamment le cas des classes serveur, client et client d’un serveur (ce n’est pas tout à fait la même notion, le client d’un serveur est le client du point de vue du serveur, alors que le client est celui qui se connecte au serveur). Certaines classes ODDNS héritent de ces classes génériques pour implémenter notamment le chiffrement.

Cela signifie également qu’il est tout à fait possible d’écrire rapidement des bibliothèques pour supporter d’autres types de chiffrement (notamment TLS). Le stockage des données peut aussi faire l’objet de code spécifique (par exemple, pour stocker certains objets dans une base de données ou un serveur LDAP).

Tout le code est conçu pour gérer le paradigme évènementiel, ce qui simplifie et donc clarifie le code.

Le protocole en lui-même (utilisé donc pour la communication entre client et serveur) est totalement arbitraire, et ne dépend pas de fonctions PHP. Il est donc possible de lire le protocole, et d’en créer un serveur et un client dans n’importe quel langage de programmation.

Là encore, c’est peut être un choix qui semblera étrange à certains, mais qui rejoint l’idée d’ouverture d’ODDNS. Créer un protocole propre à ODDNS permet plus de fantaisie que si je m’étais basé sur un protocole existant. Cela permettra notamment de l’étendre facilement (une simple classe séparée du reste du code gère tous les messages du protocole), et pourquoi pas, remplacer le protocole DNS actuel en faisant répondre le serveur ODDNS aux requêtes DNS classiques.

En ce qui concerne la configuration, elle est scindée en trois partie. La partie globale, la partie cliente qui définit les serveurs à contacter pour récupérer les informations d’un domaine particulier, et la partie serveur qui détient ces informations. Un serveur ODDNS est donc un serveur qui transmet au client ODDNS les informations relatives à un nom de domaine, que le client ODDNS transformera pour être exploitables par le serveur DNS installé sur la même machine que lui. Par conséquent, le serveur DNS répondra aux requêtes concernant le domaine en question pour toutes les machines qui seront sur le même réseau.

Par exemple, vous avez un réseau local, dont les machines sont configurée pour utiliser le serveur DNS à l’adresse 192.168.0.1. Si vous effectuez une requête DNS auprès de ce serveur, il vous renverra les informations demandées après avoir transmis la requête à un autre serveur DNS plus approprié.

Si “par dessus” votre serveur DNS vous installez un client ODDNS, configuré pour récupérer les informations d’un domaine particulier, votre serveur DNS ne contactera plus d’autres serveurs. C’est votre propre serveur DNS qui répondra directement à vos requêtes relatives à ce domaine en particulier.

Enfin, j’ai conçu les scripts d’administration qui permettent la gestion du serveur, et la mise à jour du client.

J’ai également créé un salon #oddns sur mon serveur IRC (irc.ingnu.fr).

Fonctionnement

Il n’est pas nécessaire de faire tourner le serveur ODDNS, mais c’est vivement recommandé, puisque cela permettra de partager vos informations relatives aux noms de domaine que vous visitez régulièrement avec le reste de la communauté.

Le client va lire un fichier de configuration dans lequel il trouvera un protocole, une cible et une ou plusieurs adresses IP. Le protocole permet au client de savoir s’il doit chiffrer ses communications, la cible peut être directement un nom de domaine, un canal ou une cible générique (tous les domaines du serveur à contacter), et si plusieurs adresses sont spécifiées, elles seront successivement contactée si la cible précédente n’a pas pu répondre à la requête du client.

Lorsqu’il a récupéré les données relatives à un serveur, il les stocke, conjointement à une somme md5 pour savoir si les données qu’il gère sont à jour. Enfin, il créé ou modifie les fichiers de configuration du serveur DNS pour qu’il réponde directement aux requêtes formulées pour les domaines récupérés.

Le serveur lit également un fichier de configuration, à peu de chose près semblable à la configuration DNS classique, mais simplifié. Cela va lui permettre de constituer le même fichier que lorsque le client demande les informations d’un domaine. Logique, puisque c’est ce fichier qui sera transféré au client.

Lorsqu’un client demande des informations relatives à un domaine spécifique à un serveur, celui-ci peut lui renvoyer directement les informations demandées, mais il peut également lui renvoyer le serveur “maître” du domaine. Par exemple, vous pouvez demander à un annuaire les informations relatives à ingnu, et celui-ci renverra à votre client ODDNS l’adresse IP de mon propre serveur plutôt que les informations elles-mêmes. Votre client contactera alors mon serveur pour obtenir les informations demandées.

[Mise à jour du 09 mars 2012]

On m’a rapporté qu’un schéma serait le bienvenu, en voici deux (tout moches, je suis pas doué pour ça). Le premier représente le système de résolution DNS actuel : le serveur DNS du FAI est un maillon faible parce que c’est là que se fait la censure au niveau DNS. Le second représente le système de communication de ODDNS.

[/Mise à jour]

Ce qu’il reste à faire

Migrer le wiki actuel. Il est bombardé de SPAM et je commence à saturer. Je voudrai opter pour quelque chose de plus approprié, c’est pourquoi je ne me suis pas “amusé” à installer des extensions pour aider à combattre les messages non sollicités.

Une fois que ce sera fait, je créerai un dépôt git pour ouvrir le code aux contributions. Les deux pourraient être faits en même temps si je créais un dépôt sur mon redmine, mais j’aimerais avoir l’avis de mes visiteurs avant de faire quoique ce soit.

Il restera alors à écrire les wrappers pour les différents serveurs DNS existants, notamment ceux qui ne sont pas bind (dont je m’occuperai dans les prochains jours).

Ensuite, la première version stable d’ODDNS pourra être publiée une fois l’interface web écrite.

Je suis également à la recherche d’un logo pour le projet. Je suis une bille en création graphique, alors si une âme charitable voulait bien me faire un petit logo, j’en serai ravi !

Enfin, pour aider le projet, vous aurez la possibilité de faire un don : d’argent, de matériel informatique, d’hébergement. Je ne sais pas encore trop comment m’y prendre pour vous le proposer compte tenu du fait que PayPal est tout simplement hors de question. Mais si vous estimez que le projet mérite d’être soutenu, faites-moi vos propositions ! Vous avez également la possibilité d’aider le projet tout simplement en en parlant autour de vous. Ça c’est gratuit, alors ne vous en privez pas !