Licence d'Informatique - Projet tutoré

DNSQL : un backend SQL pour BIND9

Résumé :

On se propose de programmer une interface entre le serveur DNS BIND9 de l'Internet Software Consortium et une base de données SQL comme mysql ou postgresql. Le principal intérêt est de permettre une maintenance simplifiée des zones DNS, qui pourront être manipulées à travers des tables SQL et non plus des fichiers à plat. Pour simplifier l'implémentation, le squelette sdb (simple database) de BIND9 pourra être utilisé (ce squelette résume à quelques fonctions l'interface entre le serveur DNS et le backend). Une partie non négligeable du projet consistera en la rédaction d'une HOWTO (document expliquant comment utiliser "pour de vrai" le projet), et la réalisation d'un package Debian afin de faciliter l'installation.

Mots clefs :

DNS - SERVEUR - DEBIAN - DPKG - LINUX - BIND - SQL - MYSQL - POSTGRESQL - C - API - C++ - SDB - RBTDB - DEMON - DAEMON - NAMESERVER - ISC - BACKEND

Connaissances requises :

Intérêt

Ce projet implique l'écriture non pas d'un programme, mais d'une petite bibliothèque standardisée, utilisée par un serveur existant. C'est une approche originale (du moins, du point de vue de la Licence), mais très courante en informatique. D'autre part, la manipulation de données à travers une base SQL est un exercice assez courant en informatique. Enfin, la réalisation d'un package permet de faire la différence entre un projet universitaire classique qui tombe dans l'oubli 24 heures après le rendu de la note, et un projet open source qui pourra être utilisé en production un peu partout dans le monde et faire l'objet d'un réel suivi. En d'autres termes : ce projet peut servir à quelque chose.

Description détaillée :

Le système DNS est le mécanisme qui permet la traduction de noms comme www.univ-mlv.fr en adresses IP comme 193.55.61.191 ; il constitue une arborescence de nommage hiérarchique : un serveur qui gère la zone youpi.org peut déléguer des sous-zones (tralala.youpi.org par exemple) à d'autres serveurs, qui peuvent à leur tour déléguer. Ainsi, pour résoudre n'importe lequel des millions de noms DNS existants, il suffit de connaître un serveur "racine", qui possède les informations sur les TLD (Top Level Domains, c'est-à-dire .com, .net, .org, .edu, .fr, .uk, .es, ...) puis d'effectuer une requête récursive, de serveur en serveur, jusqu'à obtenir le résultat (s'il existe).

Traditionnellement, les informations DNS sont regroupées en zones, par exemple univ-mlv.fr ou enix.org ; et chaque zone contient des enregistrements (Resource Records), pouvant être de plusieurs types (le type le plus simple est le type A, pour Address, qui dénote une correspondance entre un nom et une adresse IP ; on trouve aussi par exemple le type MX, Mail eXchanger, utilisé pour transmettre du mail). La taille d'une zone est variable : beaucoup de zones ne contiennent que quelques enregistrements, mais elles peuvent atteindre des tailles considérables (plusieurs milliers à l'Université par exemple). De plus, ces zones peuvent être amenées à être modifiées de façon fréquente (jusqu'à plusieurs fois par jour pour une zone "normale", et jusqu'à plusieurs fois par seconde pour des cas très particuliers de DNS dynamique, par exemple le service dyndns).

BIND (Berkeley Internet Name Daemon ; consulter le site de l'ISC) est un des serveurs DNS les plus utilisés dans le monde UNIX (ce n'est pas le seul : voir djbdns, maradns... il paraît même qu'une entreprise basée à Redmond a écrit un serveur DNS pour un système d'exploitation propriétaire, mais à ce jour il n'est pas possible de dire s'il marche ou pas). Les fichiers de zone utilisés par BIND sont des fichiers texte très simples, ce qui facilite l'administration de petites zones gérées par une personne ou un petit groupe de personnes, mais n'est pas pratique pour de grandes zones dont on veut, par exemple, déléguer la gestion (prenons encore comme exemple les services de DNS dynamique).

Aussi, pouvoir gérer une zone DNS dans des tables SQL permettrait de lever les problèmes de passage à l'échelle (scalability) et de délégation de droits d'accès, par exemple. Cependant, il faut pouvoir alimenter le serveur DNS avec la base de données ; pour cela, on peut imaginer des solutions de synchronisation (regénération d'un fichier de zone à partir des tables SQL de façon périodique), ou bien écrire un backend pour un serveur DNS déjà existant (on renonce à réécrire from scratch un serveur DNS).

Les versions récentes de BIND (à partir de la version 9) permettent d'écrire facilement son propre backend, à partir de l'interface sdb (simple database), qui ne nécessite l'écriture que de quelques fonctions pour interfacer BIND sur n'importe quel système.

Travail à effectuer :

Il est évident que certaines de ses tâches sont ordonnées, mais globalement, on peut facilement isoler la partie BIND, la partie SQL, et la partie packaging.

Quelques informations sont disponibles (en anglais) sur dig, nslookup, et les DNS en général, ici ; une introduction plus complète est disponible ici.