On désigne des informations à partir d’une base, centrale ou répartie (de même que sous le terme générique annuaire tout service permettant d’obtenir l’annuaire téléphonique permet d’obtenir le numéro de téléphone à partir du nom de quelqu’un).
Les annuaires sont rarement indispensables mais ils apportent un confort non négligeable soit aux utilisateurs (c’est le cas du DNS) soit à l’administrateur réseau (c’est le cas de DHCP).
Les annuaires peuvent généralement être gérés soit par plusieurs serveurs simultanément soit par un serveur principal et par un ou plusieurs serveurs secondaires qui en prennent le relais en cas de défaillance. Étant donné l’importance que prennent les annuaires dès qu’on commence à les utiliser, il est indispensable de profiter de ces capacités de redondance.

1. Domain Name System (DNS)

Le DNS est l’annuaire le plus ancien et certainement le plus utilisé. En effet, dans un réseau IP, chaque machine est repérée par une adresse, qui est un nombre sur 32 bits pour IPv4 et sur 128 bits pour IPv6. Autant les ordinateurs sont plutôt doués pour gérer des nombres, autant nous autres humains nous le sommes bien moins et il est plus facile pour nous de mémoriser des noms (faites donc l’essai avec vos amis, vous souvenez-vous plus facilement de leurs noms ou de leurs numéros de téléphone ?). Le DNS est un moyen d’associer un nom à chaque adresse IP et vice versa (ceci est une vision réductrice mais elle correspond à l’utilisation principale du
DNS).
Le DNS est décrit dans les RFC 1033 à 1035 (datant de novembre 1987). De nombreux autres RFC décrivent des extensions au DNS.
Le DNS utilise les ports UDP et TCP.

1.1 Un peu d’histoire

Dans les temps anciens, à l’époque où l’Internet n’était composé que d’une poignée de machines sur des sites qui se comptaient sur les doigts des deux mains, on disposait déjà d’un système permettant d’associer des noms aux adresses IP. Il était basé sur un fichier, très semblable à l’/etc/hosts des systèmes UNIX d’aujourd’hui, qui devait être présent à l’identique sur toutes les machines de l’Internet. Pour illustrer ce retour aux sources, considérons le fichier suivant, dont nous utiliserons les informations par la suite :

Évidemment, l’ajout d’une nouvelle machine impliquait la recopie du nouveau fichier sur toutes les autres et ce système a très vite montré ses limites, d’où l’invention du DNS.

1.2. Principes de fonctionnement

Le DNS est une base de données répartie. Par rapport au système précédent, on ne dispose plus d’un fichier unique de correspondances entre adresses IP et noms mais de plusieurs et chaque site maintient les informations correspondant à ses machines et les met à la disposition du reste de l’Internet par un protocole approprié.
Pour savoir quel serveur interroger, le système de nommage a été hiérarchisé. À cet effet, l’Internet a été découpé en domaines. Un domaine correspond à un ensemble de machines dépendant administrativement de la même entité.

1.2.1 Le système de nommage

Toute hiérarchie commençant quelque part, la racine du DNS s’appelle « . ». Sous cette racine ont été créés des top-level domains (TLD) permettant d’effectuer un premier rangement des niveau inférieurs. Parmi les TLD, on retrouve :
Des domaines fonctionnels créés à l’origine par et pour les américains, ce qui explique leur vision un peu réduite des choses :

• com pour les entreprises,
•  edu pour les universités,
• gov pour les institutions gouvernementales,
• int pour les organismes internationaux,
• mil pour les organismes militaires (l’Internet ayant été inventé par les militaires américains),
• net pour les fournisseurs d’accès à l’Internet,
• org pour les autres organisations ;

Des domaines nationaux créés par la suite selon la norme ISO 3166-1 :

• cm pour le cameroun
• au pour l’Australie,
• de pour l’Allemagne,
•  fr pour la France,
• etc.

Ces TLD ont des sous-domaines, comme par exemple ensta.fr qu’on devrait d’ailleurs écrire ensta.fr. (Notez-le point final) si l’on voulait être exact. On remarque donc que le point sert à la fois à désigner le domaine racine et à séparer les différents composants des noms de domaine (un peu comme le / pour les chemins d’accès sous UNIX à la différence que les chemins d’accès se lisent de gauche à droite alors que les noms de domaine se lisent de droite à gauche).
L’entité qui a obtenu la délégation (c’est-à-dire la gestion) d’un domaine peut alors créer à loisir des noms de machines dans ce domaine et leur associer des adresses IP (puisque c’est tout de même le but du DNS). Lorsqu’on a beaucoup de machines, il peut s’avérer utile de créer des sous-domaines afin de permettre un nommage plus propre en introduisant un ou plusieurs niveaux de hiérarchie supplémentaires. Par exemple, nous travaillerons par la suite avec le domaine tp.ensta.fr.
Le nom qualifié d’une machine (en anglais, fully qualified domain name ou FQDN), c’est-à-dire son nom complet comprenant le domaine, par exemple guinness.tp.ensta.fr, ne peut excéder 255 caractères et chacun des composants (les parties entre deux points successifs) ne peut excéder 63 caractères, ce qui laisse tout de même de la marge. Un nom de machine ou un nom de domaine ne peut contenir que des lettres (majuscules ou minuscules, aucune différence n’est faire à ce niveau), des chiffres ou des tirets. Tout autre caractère est interdit.
Un point de vocabulaire : on distingue la zone ensta.fr du domaine ensta.fr. La zone ensta.fr ne contient que les informations concernant les machines situées directement sous ensta.fr (donc la machine guinness.tp.ensta.fr n’en fait pas partie puisqu’elle appartient à un sous-domaine d’ensta.fr), alors que le domaine ensta.fr contient la zone ensta.fr, les zones correspondantes aux sous-domaines d’ensta.fr et ainsi de suite.

1.2.2 Les serveurs

Chaque zone dispose d’un ou de plusieurs serveurs DNS. S’il y en a plusieurs, l’un d’eux est dit maître et les autres sont ses esclaves (on parlait de primaire et de secondaires dans l’ancienne terminologie du DNS). Le serveur maître est le vrai détenteur des informations de la zone, les esclaves se contentent de les recopier.
À chaque modification des informations d’une zone, le serveur maître avertit ses esclaves pour qu’ils puissent se mettre à jour. Toute modification sur le maître se répercute donc très rapidement sur ses esclaves. L’opération de mise à jour s’appelle un transfert de zone.
Le serveur maître et ses esclaves font autorité sur les zones qu’ils gèrent (c’est-à- dire qu’eux seuls détiennent les tables de correspondance officielles pour ces zones).

1.2.3.La résolution de nom

Si j’ai besoin de savoir l’adresse IP associée à une machine de la zone ensta.fr, je vais m’adresser à l’un des serveurs qui font autorité pour cette zone. Mais quels sont ces serveurs ? Comme la structure du DNS est hiérarchique, il suffit de le demander à l’un des serveurs de la zone fr. Si je ne les connais pas non plus, je vais demander leurs adresses à l’un des serveurs de la racine. Puisqu’il faut bien qu’une arborescence commence quelque part, ces derniers sont connus (il y en a actuellement treize, répartis sur la planète) et permettent donc de toujours pouvoir descendre l’arbre du DNS. L’ensemble de ce processus s’appelle la résolution de nom.
Un processus qui a besoin de convertir un nom de machine en adresse IP n’effectue jamais la résolution de nom lui-même. Pour cela, il s’adresse au serveur DNS de son site, dont l’adresse IP (pas le nom, pour des raisons évidentes) figure dans le fichier /etc/resolv.conf (ce fichier peut contenir plusieurs adresses de serveurs de noms, ils sont alors interrogés dans l’ordre jusqu’à obtenir une réponse).
C’est le serveur DNS local qui va effectuer la résolution de nom et en renvoyer le résultat au processus demandeur. En prime, le serveur DNS va conserver la réponse dans un cache, afin d’éviter de refaire cette gymnastique s’il reçoit la même requête dans le futur.
Si plusieurs adresses IP différentes sont associées au même nom de machine (ce qui peut arriver, par exemple dans le cas de services redondants), un serveur DNS donné renverra successivement la première, puis la deuxième et ainsi de suite jusqu’à la dernière, puis il reprendra du début. Ce mécanisme s’appelle le tourniquet (round-robin en anglais) et permet de faire une répartition de charge naturelle entre des machines différentes mais répondant au même nom (ce qui est donc transparent pour l’utilisateur).

1.3 Interrogation du DNS avec dig

Le DNS est généralement interrogé de manière transparente par divers programmes mais il est également possible de l’interroger explicitement, pour tester un serveur ou par simple curiosité. Les principaux programmes permettant ceci sont dig, nslookup et host. Plus spartiate, dig est néanmoins plus précis et les puristes le préfèrent aux autres, principalement parce qu’il renvoie des résultats dans un format directement exploitable par un serveur de noms.
Lancé sans argument, dig affiche la liste des serveurs de noms de la racine :

On peut remarquer plusieurs choses :

• La réponse est au format des fichiers de configuration des serveurs de nom (qui sera étudié dans le paragraphe 5.1.4), ce qui permet éventuellement de réinjecter ces données sans autre traitement ;
• En conséquence, les lignes commençant par un point-virgule sont des commentaires (mais elles contiennent néanmoins des informations intéressantes pour le lecteur humain) ;
• Les noms qualifiés sont tous terminés par le point de la racine.

Demandons maintenant au DNS l’adresse IP correspondant à la machine ensta.ensta.fr :

La réponse se trouve dans la partie ANSWER SECTION.

Si maintenant, nous cherchons le nom qualifié correspondant à l’adresse 147.250.1.1 :

1. 4 BIND

Le logiciel utilisé sur quasiment tous les serveurs de noms du monde est Berkeley
Internet Name Domain (BIND), développé par l’Internet Software Consortium
(ISC).
BIND est livré en standard avec tous les systèmes UNIX mais il s’agit rarement de la dernière version. Or il est important de toujours utiliser la dernière version de BIND pour éviter l’exploitation de failles de sécurité connues et pour profiter des dernières fonctionnalités (BIND ayant énormément évolué ces dernières années).

1.4.1 Récupération des sources

Pour installer BIND, l’idéal est de s’en procurer les sources directement chez l’Internet Software Consortium. Elles sont disponibles à l’URL : ftp://ftp.isc.org/isc/bind9/

​1.4.2 Compilation

Une fois l’archive décomprimée, la compilation s’effectue de manière classique :

1.4.3. Installation
Après avoir pris l’identité du super-utilisateur :

Ceci installe :

• Des exécutables dans /usr/local/bin (dont dig) et /usr/local/sbin (dont named, qui est le serveur de noms).
• Des fichiers d’en-tête dans /usr/local/include ;
• Des bibliothèques dans /usr/local/lib ;

1.4.4 Configuration

BIND se configure au moyen d’un fichier principal et de plusieurs fichiers auxiliaires. Le fichier principal s’appelle par convention named.conf (bien qu’on puisse utiliser un autre nom, je vous recommande de garder celui-ci) et se trouve par défaut dans le répertoire /etc (on peut utiliser un autre répertoire et nous allons d’ailleurs le faire par la suite).
Par défaut, BIND est conçu pour fonctionner sous l’identité du super-utilisateur. Un logiciel de cette complexité n’est pas à l’abri d’erreurs de conception et d’anciennes versions comportaient des failles permettant de prendre le contrôle de la machine hébergeant le serveur de noms. Comme BIND peut tout aussi bien fonctionner sous l’identité d’un utilisateur non privilégié (bien que trop peu d’administrateurs prennent la peine de le faire), nous allons donc utiliser cette possibilité.
De même, BIND peut fonctionner dans un système de fichiers restreint par l’appel système chroot(). Nous utiliserons également cette option de sécurité.
Il faut maintenant choisir un répertoire où placer les différents fichiers de configuration. C’est également dans ce répertoire que sera confiné le démon named. Prenons par exemple /opt/dns.

Le fichier named.conf, situé dans le précédent répertoire, contiendra :

Les commentaires sont introduits par un # initial (comme en Perl), un // initial ou entourés par /* et */ (comme en C++).
Le groupe options spécifie les options générales pour le serveur. Ici, on indique le répertoire dans lequel les fichiers que l’on indiquera par la suite seront placés. Puisqu’on va mettre les fichiers dans /opt/dns et se restreindre à ce répertoire, c’est / qu’on indique dans la directive directory.
À son lancement, tout serveur DNS a besoin de connaître les serveurs de la racine. Il faut donc les lui fournir dans le fichier named.root (disponible à l’URL ftp: //ftp.internic.net/domain/named.root). Ces données lui serviront uniquement à contacter l’un des serveurs de la racine pour y charger une zone à jour (d’où le type hint lié à cette zone).
Chaque zone pour laquelle le serveur est maître est du type master et est contenue dans un fichier placé dans le répertoire master (on aurait pu appeler ce répertoire tout autrement, voire ne pas mettre les fichiers dans un répertoire particulier, mais ceci permet de ranger les fichiers proprement et d’être cohérent avec la dénomination utilisée dans named.conf). Par souci de clarté, chaque fichier aura le même nom que la zone qu’il contient (là encore, ce n’est qu’une convention).
De même, chaque zone pour laquelle le serveur est esclave est du type slave et est contenue dans un fichier de même nom que la zone et placé dans le répertoire slave. On indique de plus l’adresse IP du serveur maître pour cette zone afin de l’y télécharger.
Les fichiers des zones pour lesquelles le serveur est esclave étant automatiquement remplis par transfert de zone, nous nous intéresserons par la suite aux fichiers des zones pour lesquelles le serveur est maître.

Étudions la zone maître tp.ensta.fr :

Les commentaires sont introduits par un ; et s’étendent jusqu’à la fin de la ligne.
Chaque fichier de zone commence par une directive $TTL qui indique la durée de vie (time to live) des informations de cette zone lorsqu’elles seront dans le cache d’un autre serveur DNS. Pour notre zone, les informations resteront dans le cache des autres serveurs pendant une journée (1d). Par la suite, toute demande de résolution de nom sera honorée à partir du cache, jusqu’à ce qu’une journée se soit écoulée, auquel cas l’information en sera supprimée.
Le reste du fichier de zone contient des définitions de resource records (RR).
Chaque RR tient habituellement sur une ligne de la forme :

Ici, IN indique que le RR est de la classe Internet. Il existe d’autres classes mais, en pratique, elles ne sont pas utilisées.
Le premier RR du fichier est le SOA (start of authority), qui indique divers paramètres de la zone.
La première ligne indique :

• Le nom de la zone contenue dans le fichier ou @ pour utiliser le nom de zone tel qu’indiqué dans named.conf ;
• La classe Internet ;
• Le type du RR (ici SOA) ;
• Le nom du serveur maître pour cette zone ;
• L’adresse électronique de la personne responsable de cette zone.

Dans cette adresse, le @ habituel est remplacé par un point (ce qui implique que la partie gauche de l’adresse ne peut pas en contenir). Le RFC 2142 recommande que cette adresse soit hostmaster.
Notez les points terminaux qui indiquent la racine du DNS (à partir de maintenant, faites attention à ne pas les oublier, sauf dans certains cas qui seront détaillés plus loin).
Suivent un ensemble de paramètres numériques, contenus entre parenthèses (ce qui permet de faire tenir le RR sur plusieurs lignes ; cette possibilité n’est d’ailleurs utilisée que pour le SOA):

• Le numéro de série qui est un entier sur 32 bits devant être augmenté à chaque modification de la zone. Par convention (et parce que ça tient dans un entier de 32 bits), on utilise un format AAAAMMJJNN contenant la date de la dernière modification de la zone au format ISO 8601 (AAAA pour l’année, MM pour le mois, JJ pour le jour) suivie d’un numéro d’ordre (NN valant 00 pour la première modification du jour, 01 pour la deuxième, etc.). Une erreur classique consiste à modifier les données de la zone sans augmenter le numéro de série.
• La durée de rafraîchissement qui était utilisée par les esclaves pour savoir à quel intervalle ils devaient interroger le maître pour savoir si une zone avait été modifiée. Maintenant, le maître avertit immédiatement ses esclaves de toute modification donc ce paramètre n’est plus utilisé.
• La durée de nouvel essai qui est utilisée par les esclaves pour savoir, après une tentative échouée de transfert de zone, au bout de combien de temps ils peuvent la retenter.
• La durée d’expiration qui est utilisée par les esclaves pour savoir, s’ils ne peuvent pas mettre à jour leurs zones auprès du maître, au bout de combien de temps ils doivent effacer leurs données.
• Le TTL négatif qui indique aux caches combien de temps ils doivent conserver les réponses négatives.

Le RFC 1537 explique le choix de ces valeurs (sauf pour la dernière, dont la signification a changé récemment).
On trouve ensuite les RR NS, qui indiquent quels sont les serveurs de nom pour la zone. Aucune différence n’est faite ici entre maître et esclaves mais l’habitude veut qu’on fasse figurer le maître en première position.
Notez que, dans ce RR, la première colonne est laissée vide. Dans ce cas, sa valeur est prise de la première colonne du RR précédent.
Viennent enfin les RR contenant les correspondances entre noms de machines et adresses IP. Ici, il s’agit d’une zone directe donc les RR sont de type A. Notez que l’on n’a pas ajouté le nom de la zone aux noms de machines et que l’on n’a pas mis de points terminaux. Dans ce cas, le nom de la zone est automatiquement rajouté.
Un tel RR :

se verrait donc transformé en :

en raison de l’absence du point terminal. Il convient donc d’y être attentif.

Étudions maintenant la zone maître 14.250.147.in-addr.arpa. Il s’agit d’une zone inverse (c’est-à-dire contenant les correspondances entre adresses IP et noms de machines) :

Tout d’abord, le nom de cette zone est particulièrement étrange. Le domaine in-addr.arpa n’est utilisé que pour les zones inverses. Et comme la hiérarchie des domaines se lit de droite à gauche, les adresses IP dans les zones inverses sont écrites dans ce sens, à l’envers du sens normal de lecture.

Pour le reste, ce fichier de zone est très semblable à un fichier de zone directe, à la différence qu’on utilise des RR de type PTR et qu’on n’écrit en première colonne que le dernier octet de l’adresse IP (la suite étant complétée par 14.250.147.in-addr.arpa en l’absence du point final).

Une délégation se fait tout simplement en indiquant dans la zone mère des RR

NS pour sa zone fille. Il faut également indiquer l’adresse IP des serveurs de noms (problème d’œuf et de poule). Ainsi, pour déléguer une zone b1-4.tp.ensta.fr, on peut rajouter au fichier de la zone tp.ensta.fr :

1.4.5 Lancement

Pour pouvoir utiliser les ports UDP et TCP 53, le serveur de noms à besoin d’être lancé sous l’identité du super-utilisateur.
Il est recommandé d’utiliser les options suivantes :

• -t qui indique le répertoire auquel restreindre le serveur ;
• -c qui indique le nom du fichier de configuration relativement à ce répertoire ;
• -u qui indique le nom de l’utilisateur sous l’identité duquel tournera le serveur de noms après son démarrage.

Ainsi, le serveur de noms peut se lancer par la commande :

2. Lightweight Directory Access Protocol (LDAP)

LDAP est l’annuaire qui monte en ce moment. Il est principalement utilisé pour centraliser les bases d’authentification ou les carnets d’adresses électroniques mais il s’agit d’un annuaire généraliste pouvant être utilisé pour presque n’importe quoi.
LDAP est décrit dans le RFC 2251 et utilise le port TCP 389.

2.1 Principes

LDAP est l’adaptation dans le monde IP de DAP (Directory Access Protocol), qui permet d’accéder à des annuaires X.500 dans le monde ISO. C’est ce qui explique la structure particulière des bases LDAP et leur système de nommage.
À la différence des systèmes de gestion de bases de données (SGBD), les bases LDAP sont optimisées pour la lecture. En conséquence, elles peuvent aisément être répliquées pour assurer une meilleure disponibilité.
Une base LDAP est composée d’entrées. Chaque entrée regroupe un certain nombre d’attributs et a un DN (Distinguished Name) qui doit être unique au sein de l’ensemble de la base. Chacun des attributs a un type et une ou plusieurs valeurs.
Chaque entrée a un attribut spécial indiquant la classe de l’entrée. Celle-ci contrôle quels attributs sont autorisés dans l’entrée. Ainsi il existe une classe « organisation », une classe « personne », etc.
Les entrées sont définies dans un format de fichier spécial appelé LDIF (LDAP Data Interchange Format) et décrit dans le RFC 2849.

Quelques exemples permettront d’y voir plus clair.

On définit ici un objet du type « organization » défini par un DN utilisant le domaine DNS de l’organisation au moyen d’éléments DC (Domain Component).
On indique également le nom de l’organisation et son adresse postale.
La structure d’un annuaire LDAP est hiérarchique. Une fois l’organisation définie, on peut définir différents services en son sein :

En dessous de l’entrée précédente, on définit donc le service « sports », dont on peut maintenant indiquer les membres :

Les trois classes que nous venons de voir sont les plus fréquemment utilisées (surtout la dernière) dans les annuaires LDAP, bien qu’il en existe de nombreuses autres.
Les attributs possibles pour ces classes sont les suivants :

• Organization
• o (obligatoire)
• businessCategory
• description
•  facsimileTelephoneNumber
• location (l)
• postalAddress
• seeAlso
• telephoneNumber
• organizationalUnit
• ou (obligatoire)
• businessCategory
• description
• facsimileTelephoneNumber
• location (l)
• postalAddress
• seeAlso
• telephoneNumber
• inetOrgPerson
• commonName (cn) (obligatoire)
• surname (sn) (obligatoire)
• businessCategory
• carLicense
• departmentNumber
• description
• employeeNumber
• facsimileTelephone
• number
• givenName
• mail
• manager
• mobile
• organizationalUnit (ou)
• pager
• postalAddress
• roomNumber
• secretary
• seeAlso
• telephoneNumber
• title
• labeledURI
• uid

La hiérarchie précédente est basée sur le DNS, simplement parce que ceci assure l’unicité du nommage, mais on peut également définir une hiérarchie géographique :

Dans cet exemple, c indique le code du pays et o le nom de l’organisme. Ici se termine cette courte introduction à LDAP mais vous trouverez ici de quoi approfondir vos connaissances :
http://www-sop.inria.fr/semir/personnel/Laurent.Mirtain/ldap-livre.html

​2.2  OpenLDAP

Le serveur LDAP le plus répandu sous UNIX est OpenLDAP 1, dont la dernière version est la 2.4.47. Pour le télécharger rendez-vous à l’adresse :
ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/

​2.2.1  Compilation

Une fois l’archive décomprimée, la compilation s’effectue de manière classique :

2.2.2. Installation

Après avoir pris l’identité du super-utilisateur :