Dans cet article, nous abordons le principe de fonctionnement du système de noms de domaines. Les exemples s'appuient sur la version 8 de BIND, l'implémentation de Berkeley.
Définition
Le DNS ou Domain Name System gère la traduction : noms de machines connectées à l'Internet <--> adresses IP. Il établit par exemple l'association www.linuxmag-france.org <--> 212.198.253.142, facilitant la navigation sur le site web de votre revue.
Bref historique
A l'origine, le NIC (Network Information Center) administrait une simple table de correspondance nommée HOSTS.TXT. Les administrateurs réseaux communiquaient les modifications locales par courrier électronique et récupéraient régulièrement une copie à jour du fichier par FTP. Cette méthode présentait deux inconvénients majeurs. D'une part, la charge imposée au serveur FTP et plus généralement à l'ensemble du réseau augmentait exponentiellement avec le nombre de machines interconnectées. D'autre part, rien ne garantissait la cohérence de données dupliquées en de multiples points du réseau.
Configuration standard
Si votre installation compte un nombre limité de postes, vous déclarez probablement leurs noms dans le fichier /etc/hosts. Sur Robby, notre portable :
# Interface loopback 127.0.0.1 localhost # Réseau local (privé) 192.168.0.1 bellerophon bellerophon.altair.net 192.168.0.2 robby robby.altair.net ...
Le portable appartient au réseau privé altair.net d'adresse 192.168.0.0. L'interface loopback d'adresse 127.0.0.1 simule une liaison en boucle sur chaque hôte. Elle autorise le test et l'exploitation autonome des protocoles de classe IP. Les serveurs de noms d'un fournisseur d'accès Internet relaient les demandes de traduction ne pouvant être résolues à partir des données du fichier hosts. Leurs adresses sont déclarées dans le fichier /etc/resolv.conf :
# Serveurs de noms Wanadoo nameserver 193.252.19.3 nameserver 193.252.19.4
Fonctionnement du DNS
Domaines
Les domaines sont des regroupements logiques de machines. Ils composent un arbre.
Zones
Un domaine X englobe l'arbre dont la racine porte cette étiquette. Un domaine X peut être découpé en zones.
Un système réparti
Les serveurs de noms forment une base de données distribuée. Ils disposent d'enregistrements de ressources (Ressource Records) précisant les correspondances noms <--> adresses des machines rattachées aux zones qu'ils servent et d'autres pointant vers les zones qu'ils n'administrent pas directement.
Recherche de noms
Dans le pire des cas, une requête de recherche de nom (name lookup) est adressée à un serveur situé à la racine puis propagée en cascade vers un serveur de premier niveau, de deuxième niveau ... jusqu'à atteindre un serveur stockant dans ses tables la ou les correspondances recherchées. Ce principe de délégation règle les problèmes exposés en début d'article. La charge est répartie sur de multiples serveurs. Chaque serveur a autorité sur un nombre limité d'informations, ce qui en améliore la cohérence.
Recherche inverse
La recherche inverse (reverse lookup) remonte d'une adresse IP au ou aux noms de la machine associée. Cette procédure est utile pour restreindre l'accès à des services Internet. Par exemple, certains sites FTP interdisent le chargement du logiciel de cryptographie PGP depuis des domaines rattachés à des pays interdisant l'importation de ce type de technologie. La recherche inverse reprend les mécanismes employés lors de recherches directes. On adjoint à une adresse a.b.c.d un suffixe in-addr.arpa sous cette forme : d.c.b.a.in-addr.arpa. Par exemple, 212.198.253.142 devient 142.253.198.212.in-addr.arpa. On procède ensuite à une résolution classique.
Modes itératif, récursif
Il existe deux modes d'interrogation des serveurs. En mode récursif, le serveur interrogé prend en charge les appels (récursifs ou itératifs) à d'autres serveurs nécessaires pour résoudre la recherche. En mode itératif, il fournit l'information la plus détaillée dont il dispose, le programme client prenant en charge l'appel à d'autres serveurs. Un serveur de noms peut refuser d'honorer les requêtes récursives. C'est le cas des serveurs de premier niveau très sollicités.
Cache
Les enregistrements consultés sont stockés dans un cache volatile afin d'améliorer les temps de réponse. Les recherches en profondeur depuis la racine sont généralement évitées.
Resolver
Resolver qualifie une collection de routines d'interrogation de la librairie C faisant l'interface entre programmes clients, tables d'hôtes et serveurs de noms. Le fichier /etc/hosts.conf définit des règles d'arbitrage entre ces sources. Typiquement :
# Ordre des recherches order hosts, bind
Dans ce cas, l'information est d'abord recherchée dans le fichier hosts puis en adressant des requêtes aux serveurs de noms de domaine. Nous reviendrons un peu plus loin sur la signification de l'acronyme BIND.
Utilitaire NSLOOKUP
Nous supposerons que vous disposez d'un accès Internet convenablement configuré. Les exemples ont été testés sous Red Hat 6.0, Mandrake 6.1 et Open Server 2.3.
Installation
L'utilitaire nslookup est un outil d'interrogation des serveurs de noms. Sous Red Hat, il est inclus dans le paquetage standard bind-utils situé dans le répertoire RedHat/RPMS. Installez-le, en adaptant le nom en fonction de votre distribution. Dans notre cas :
su root rpm -ivh bind-utils-8.2-6.i386.rpm
Un exemple d'interrogation
Nous allons rechercher l'adresse IP du serveur web du magazine. Nous obtenons d'un serveur de noms mis à disposition par un fournisseur d'accès Internet la liste des serveurs à la racine puis cheminons de serveur en serveur jusqu'a obtention de la réponse :
nslookup Default Server: ns3.wanadoo.fr Address: 193.252.19.3 > set querytype=NS ... > . Non-authoritative answer: (root) nameserver = A.ROOT-SERVERS.NET. (root) nameserver = D.ROOT-SERVERS.NET. ... Authoritative answers can be found from: A.ROOT-SERVERS.NET internet address = 198.41.0.4 D.ROOT-SERVERS.NET internet address = 128.8.10.90 ... > server a.root-servers.net Default server: A.ROOT-SERVERS.NET Address: 198.41.0.4 > org Server: A.ROOT-SERVERS.NET Address: 198.41.0.4 org nameserver = A.ROOT-SERVERS.NET org nameserver = A.ROOT-SERVERS.NET ... > linuxmag-france.org Server: A.ROOT-SERVERS.NET Address: 198.41.0.4 Non-authoritative answer: linuxmag-france.org nameserver = NS1.GRANITECANYON.COM linuxmag-france.org nameserver = NS2.GRANITECANYON.COM Authoritative answers can be found from: NS1.GRANITECANYON.COM internet address = 205.166.226.38 NS2.GRANITECANYON.COM internet address = 216.17.165.20 > server ns1.granitecanyon.com Default server: NS1.GRANITECANYON.COM Address: 205.166.226.38 > set querytype=A > www.linuxmag-france.org Server: NS1.GRANITECANYON.COM Address: 205.166.226.38 Name: www.linuxmag-france.org Address: 212.198.253.142
Autorité
Les réponses se distinguent par leur source. Un serveur maître fait autorité sur les données d'un nombre limité de zones (authoritative answers). Un serveur secondaire offre une copie de sécurité des données d'un serveur maître. Chaque serveur cache des données obtenues d'autres serveurs (non authoritatives answers).
Installer un serveur de noms cache
Dans cette deuxième section, nous présentons l'installation d'un serveur de noms simple faisant cache mais ne gérant pas de domaine spécifique.
Installation du paquetage BIND
Nous utiliserons une version 8.x du paquetage BIND (Berkeley Internet Name Daemon), lui-même disponible sous la forme d'un paquetage standard :
rpm -ivh bind-8.2-6.i386.rpm
Notez que la syntaxe des fichiers de configuration diffère de celle des versions 4.x. Les utilisateurs maîtrisant BIND et souhaitant juste faire une mise à niveau peuvent utiliser le filtre named-boot-conf.pl inclus dans le paquetage.
Le script d'installation a ajouté une entrée dans l'arborescence /etc/rc.d (Red Hat) de sorte que le démon named soit invoqué à chaque démarrage.
Fichier named.conf
Le fichier /etc/named.conf indique la localisation des fichiers associés aux zones sur lesquelles nous fournissons de l'information. Dans notre cas :
/* Localisation des fichiers de zones */
options {
directory "/var/named";
};
/* Zone cache */
zone "." in {
type hint;
file "cache";
};
/* Zone inverse localhost */
zone "0.0.127.in-addr.arpa" in {
type master;
file "127.0.0";
};
Créez si nécessaire le répertoire /var/named. Détaillons la configuration. Comme vous le constatez, les informations sont présentées à la C.
Options
Les chemins des autres fichiers de configuration sont définis relativement au répertoire /var/named.
Zone "."
La zone "." correspond à la racine de l'espace des domaines. Le fichier cache contiendra une liste initiale de serveurs ayant autorité sur les domaines de premier niveau (edu, com ...). La liste exacte sera obtenue d'un des serveurs valides lors du lancement du démon.
Un domaine noté x. est pleinement qualifié. Dans un contexte définissant un domaine par défaut y, x qualifie le domaine x.y.
Zone 0.0.127.in-addr.arpa
La zone 0.0.127.in-addr.arpa associe nom de la machine locale et adresse de l'interface loopback. L'information est ici stockée dans le fichier 127.0.0.
Fichier cache
L'utilitaire BIND dig va nous permettre de récupérer une copie à jour de ce fichier d'initialisation du cache :
su root dig @rs.internic.net . ns > /var/named/cache
Nous obtenons :
;; ANSWER SECTION: . 5d18h2m25s IN NS G.ROOT-SERVERS.NET. . 5d18h2m25s IN NS F.ROOT-SERVERS.NET. ... ;; ADDITIONAL SECTION: G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 ...
Le DNS compte actuellement 13 serveurs à la racine. Vous devrez en charger une copie à jour régulièrement. Cependant, tout fonctionnera correctement avec un fichier relativement ancien. En effet, lors de l'initialisation, une copie à jour est obtenue dynamiquement d'un des serveurs de premier niveau valides. Le mot-clef "hint" identifie cet enregistrement spécial.
Fichier 127.0.0
Créez un fichier /var/named/127.0.0 de ce type :
; Infos recherche inverse machine locale
0.0.127.in-addr.arpa. IN SOA localhost. root@localhost. (
1; Numéro de série
3600; Rafraîchissement (1h)
600; Nouvelle tentative (10 mn)
604800; Expiration (7j)
86400 ); Durée de vie (1j)
IN NS localhost.
1 IN PTR localhost.
Ressources
IN identifie les enregistrements de type Internet. SOA est l'acronyme de Start Of Authority. Ici, nous précisons que la machine locale dispose des informations les plus fiables sur le domaine 0.0.127.in-addr.arpa. root@localhost est l'adresse de courrier électronique du responsable technique à contacter en cas de dysfonctionnement. Les durées en secondes servent à la synchronisation des serveurs esclaves et à définir la durée de vie (Time To Live) des données dans le cache des clients. Une valeur faible favorise une propagation rapide des modifications, ce au prix d'une charge système importante. A l'inverse, une valeur élevée implique une propagation plus lente. Pratiquement, copiez les valeurs indiquées et tout se déroulera correctement. NS indique les serveurs de noms de cette zone et l'enregistrement PTR, la correspondance machine 1 du réseau 127.0.0 <--> localhost.
Notez bien qu'ici la notation comporte un "." terminal.
Tests
Rebootez la machine pour initialiser le service :
shutdown -r now
Ou lancez le directement :
ndc sta new pid is 938
Le fichier /var/log/messages (Red Hat, localisation par défaut) donne le résultat de l'opération :
... named[937]: starting. named 8.2 Tue May 11 03:26:21 GMT 1999 Jan 27 12:33:51 robby named[937]: cache zone "" (IN) loaded (serial 0) Jan 27 12:33:51 robby named[937]: master zone "0.0.127.in-addr.arpa" (IN) loaded (serial 1) Jan 27 12:33:51 robby named[937]: listening on [127.0.0.1].53 (lo) Jan 27 12:33:51 robby named[937]: Forwarding source address is [0.0.0.0].1025 Jan 27 12:33:51 robby named[937]: Ready to answer queries.
Le fichier de trace confirme que le démon a chargé correctement les deux zones et écoute les requêtes sur le port 53. Lançons l'utilitaire nslookup pour tester les tables :
nslookup - localhost Default Server: localhost Adress: 127.0.0.1 > set type=ANY > 0.0.127.in-addr.arpa. 1.0.0.127.in-addr.arpa name = localhost ...
Modification du resolv.conf
Sauvegardez le fichier resolv.conf original :
mv /etc/resolv.conf /etc/resolv.conf.sav
resolv.conf devient sur une machine isolée :
# NS local search wanadoo.fr nameserver 127.0.0.1
Ici, la recherche se fera par défaut sur le domaine wanadoo.fr.
Cas d'une liaison point à point
Dans le cas d'une liaison intermittente de type dialup, la configuration est un peu plus complexe. Le serveur est lancé à l'initialisation, ce qui n'est à priori pas un problème. Cependant, hors connexion, les résolutions impliquant des appels à des serveurs extérieurs ne peuvent aboutir, entraînant des temps de dépassement importants. Une solution adaptée du Howto consiste à travailler avec une liste de serveurs racine vide hors connexion. Copiez le fichier named.conf :
cp /etc/named.conf /etc/named.conf.up
Modifiez l'original en supprimant la section ".". Reste à automatiser la permutation des deux configuration. Lorsqu'une liaison ppp est établie, le script /etc/ppp/ip-up.local est exécuté s'il existe. Créez-le sur ce modèle :
#!/bin/bash # Relancer named en mode connecté killall -9 named named -c /etc/named.conf.up
Sur un principe identique, créez un fichier /etc/ppp/ip-down.local :
#!/bin/bash # Relancer named en mode connecté killall -9 named named
Vérifiez les droits d'exécution de ces deux fichiers. Laissez de préférence votre machine en marche en permanence. les données du cache sont en effet perdues à chaque extinction.
Gérer un petit domaine
Architecture
Nous allons enrichir notre exemple précédent en gérant le petit domaine privé de classe C altair.net. Les machines suivantes sont disponibles :
Nom Adresse Fonction Bellerophon 192.168.0.1 Serveur DNS, courrier Robby 192.168.0.2 Portable Krell 192.168.0.3 Serveur FTP ...
Notre domaine n'est pas rattaché à l'espace général des noms de domaines. Dans le cas contraire, nous aurions du le déplacer et obtenir son rattachement à un domaine de niveau supérieur. Nous introduisons deux zones supplémentaires :
zone "altair.net" in {
type master;
file "altair.net";
};
zone "0.168.192.in-addr.arpa" in {
type master;
file "192.168.0";
};
Zone altair.net
Cette zone décrit les correspondances noms --> adresses :
altair.net. IN SOA bellerophon.altair.net.
root.altair.net. (
1; Numéro de série
3600; Rafraîchissement (1h)
600; Nouvelle tentative (10 mn)
604800; Expiration (7j)
86400 ); Durée de vie (1j)
IN NS bellerophon.altair.net.
bellerophon IN A 192.168.0.1
robby IN A 192.168.0.2
krell IN A 192.168.0.3
localhost IN A 127.0.0.1
La ressource A précise une adresse.
Zone 0.168.192.in-addr.arpa
Cette zone décrit les correspondances adresses --> noms :
0.168.192.in-addr.arpa. IN SOA bellerophon.altair.net.
root.altair.net.
1 ; Numéro de série
3600 ; Rafraîchissement (1h)
600 ; Nouvelle tentative (10 mn)
604800 ; Expiration (7j)
86400 ) ; Durée de vie (1j)
IN NS bellerophon.altair.net.
1 IN PTR bellerophon.altair.net.
2 IN PTR robby.altair.net.
3 IN PTR krell.altair.net.
Ajout d'alias
Les alias facilitent l'affectation de plusieurs noms à une même machine. Supposons que bellerophon héberge un serveur de courrier, krell des serveurs FTP et de nouvelles. Nous pourrions définir les alias suivants dans la zone altair.net :
; Alias mail CNAME bellerophon ftp CNAME krell news CNAME krell
Lors d'une résolution portant sur un alias, le terme droit est substitué au terme gauche et une nouvelle résolution relancée.
Passerelle de courrier
Les informations du DNS ne se limitent pas à la traduction. La ressource MX (Mail eXchange) indique le nom et la priorité du serveur de courrier d'une zone. Supposons que bellerophon soit notre passerelle :
Passerelle courrier altair.net. IN MX 10 bellerophon
Ainsi, les courriers de type sx@altair.net seront relayés correctement.
Activation du serveur de noms
L'entrée nameserver du fichier /etc/resolv.conf devient :
nameserver 192.168.0.1
Approfondir
Le DNS est en constante évolution. Voici une liste de lectures en ligne intéressantes :
DNS Howto
BIND FAQs
RFC 819, 920,
974, 1032,
1033, 1034,
1035, 1591