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 :
-
Notions de base de DNS (savoir faire un transfert de zone avec nslookup
est largement suffisant)
-
Langage SQL de base (création d'une table, recherche, insertion,
suppression dans une table)
-
Anglais lu et écrit couramment (toutes les docs à lire, ainsi
qu'à rédiger, sont en anglais)
-
Langage C (l'API de BIND9 est en C ; il est possible d'utiliser un autre
langage, si celui-ci est interfaçable avec le C et dispose d'une
bibliothèque mysql et/ou postgresql)
-
Système de packaging Linux quelconque (dpkg ou rpm
par exemple)
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 :
-
se familiariser avec BIND9 et le système DNS
-
étudier l'API sdb de BIND9, en faisant une première
implantation triviale pour vérifier qu'on a bien compris son fonctionnement
-
choisir pour commencer un moteur SQL : mysql ou potgresql
-
utiliser l'API du moteur choisi pour effectuer des requêtes SQL
-
écrire l'interface en BIND et la base SQL
-
faire de nombreux tests
-
réaliser un package Debian
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.