Mise à jour dynamique du DNS.
Microsoft, depuis Windows 2000 "server edition" et supérieures, a mis en place un système d'identification des stations du réseau par DNS, délaissant son antique système WINS. Nous pouvons très simplement, avec un contrôleur de domaine Windows 2000 installer un serveur DNS et un serveur DHCP. Les stations du domaine qui reçoivent une configuration dynamique via DHCP sont également enregistrées automatiquement sur le DNS.
La solution est élégante et efficace, mais onéreuse. Nous allons voir que nous pouvons faire la même chose avec Linux, Bind et DHCPd, mais de façon infiniment mois onéreuse, puisque c'est gratuit. Notez tout de même que la solution, si elle fonctionne, ne semble pas être entièrement stabilisée. A mon sens, le problème du DNS mis à jour dynamiquement ne sera définitivement et proprement résolu que lorsque DNS et DHCP seront deux services fournis par le même soft, et qu'ils utiliseront pour ce faire une vraie base de données commune.
Dans l'état actuel des choses, si vous souhaitez mettre en production une telle solution sur un réseau sur lequel il faut compter, je vous conseille la plus extrême prudence et un maquettage rigoureux de la solution finale sur un réseau expérimental. En effet, les surprises peuvent être nombreuses, et pas toujours bonnes. Là encore, pourquoi faire ? Si votre réseau est un petit réseau constitué de quelques machines toutes sous WIndows, ça ne présentera pas grand intérêt.
En revanche, c'est un moyen extrêmement élégant de retrouver simplement l'IP d'une machine de votre réseau, même si elle est attribuée dynamiquement, rien qu'en connaissant son nom d'hôte. Et puis, ça ne coûte rien et ça fait passer le temps...
Quelques mots sur le principe.
Attention, cette méthode est expérimentée avec DHCPd 3.0 et BIND 9.2
Il y a en réalité, deux moyens de le faire. Soit c'est le client qui va s'annoncer au DNS, une fois qu'il aura récupéré son bail, ça présente deux inconvénients : Tous les clients DHCP ne savent pas le faire, ça oblige à ce que tous les hôtes du réseau soient autorisés à effectuer des modifications sur le DNS, ce qui est loin d'être une solution sûre. Soit, c'est le DHCP qui sera chargé d'effectuer les mises à jour sur DNS, à chaque attribution d'un bail. C'est bien plus sûr, on est certain que ça fonctionnera avec tous les clients, ça augmente juste un peu la charge du serveur. Nous allons choisir cette seconde solution.
Cette méthode, qui est bien entendu très intéressante lorsque l'adressage est dynamique, c'est à dire que l'IP d'un hôte est susceptible de changer dans le temps, l'est moins si l'on a choisi d'attribuer une IP fixe à un ou plusieurs hôtes. D'ailleurs, par défaut, la mise à jour du DNS ne s'effectuera pas dans ces cas. Il y a cependant une clause qui permet de forcer cette mise à jour et nous allons l'utiliser.
Du côté de BIND.
Il faut lui indiquer que les zones de notre domaine peuvent être mise à jour par le serveur DHCP. Il existe une méthode sécurisée consistant à utiliser des clés MD5 pour l'authentification, nous ne l'utiliserons pas ici, mais suivant le cas de figure, ça peut être très vivement conseillé.
Nous allons juste signaler l'adresse IP nécessaire : 127.0.0.1, puisque les deux services tournent sur la même machine.
Nous allons modifier le fichier /etc/named.conf comme suit :
...
# La zone directe du domaine
zone "maison.mrs" {
type master;
file "/var/named/maison.mrs.hosts";
allow-update {
127.0.0.1;
};
};
# La zone de recherche inverse
zone "0.168.192.in-addr.arpa" {
type master;
file "/var/named/0.168.192.in-addr.arpa.rev";
allow-update {
127.0.0.1;
};
...
Si certaines de vos machines avaient une configuration fixe et étaient référencées dans votre DNS, détruisez leurs enregistrements aussi bien dans la zone directe que dans la zone inverse, sinon, la mise à jour dynamique échouera pour ces noms d'hôtes.
Côté Bind, c'est tout ce qu'il y a à faire, dans notre cas. Il ne faut ,bien entendu, pas oublier de redémarrer le service.
Du côté de DHCPd.
Là, il y a plus de travail. Il faut modifier le fichier /etc/dhcpd.conf de la manière suivante :
# méthode de mise à jour du DNS :
ddns-update-style interim;
# mise à jour autorisée
ddns-update on;
# ici, on force la mise à jour par le serveur DHCP
ignore client-updates;
# on force également la mise à jour des IP fixes
update-static-leases on;
Bien que ça puisse parfois fonctionner sans, il vaut tout de même mieux prendre la précaution d'ajouter en fin de fichier, ceci afin de définir clairement quel DNS doit être mis à jour pour ces zones :
zone maison.mrs. {
primary 127.0.0.1;
}
zone 0.168.192.in-addr.arpa. {
primary 127.0.0.1;
}
A aménager, bien entendu, en fonction de votre propre configuration. Faites bien attention à la syntaxe. N'oubliez aucun point dans les noms des zones, refermez les accolades et finissez vos directives par un point-virgule.
Relancez le service DHCPd, ça devrait maintenant fonctionner.
Mise en garde.
La mise à jour dynamique de DNS nécessite de connaître le nom de l'hôte qui vient de récupérer un bail, surtout si vous voulez conserver une cohérence entre les noms d'hôtes attribués localement et les noms DNS.
Il faut savoir que si le client DHCP de Windows envoie le nom d'hôte lors de la requête DHCP, les clients Linux comme dhcp client et même dhcpcd ne le font pas par défaut. Si vous n'y prenez garde, vos machines recevront bien leur bail, mais la mise à jour DNS ne s'effectuera pas.
Avec dhcp client, il faut créer un fichier /etc/dhclient.conf qui contiendra au moins la ligne :
send host-name "lenomdelamachine" ;
Consultez la doc de dhcp client pour savoir tout ce que l'on peut configurer par l'entremise de ce fichier,
Vérifications.
Dans /var/named, à la première attribution d'un nouveau bail, vous devez voir apparaître deux nouveaux fichiers de zone, avec le même nom que les zones de votre domaine, mais avec un suffixe .jnl. Ces fichiers constituent la preuve que ça fonctionne, ce sont des journaux. N'essayez pas de les lire, ils sont en mode binaire. Beaucoup plus tard, vous pourrez constater que les fichiers de zone ont eux aussi été modifiés. De nouveaux enregistrements A sont apparus, suivis d'un enregistrement TXT. Ne modifiez plus ces enregistrements, surtout, n'enlevez pas l'enregistrement TXT, il permet d'indiquer si le champ précédent est issu d'une mise à jour dynamique ou non, et son utilité est primordiale pour les mises à jour futures.
Les outils classiques, host sous Linux, nslookup sous Windows 2000/XP vous permettront de vérifier les réponses de votre DNS.
Remarques diverses.
Il faudrait étudier avec soin toute la documentation de bind et de dhcpd pour maîtriser parfaitement le mécanisme de mise à jour dynamique, j'avoue ne pas encore avoir eu le courage de le faire.
Vous risquez des ennuis si vous faites une mise à jour de la partie statique de votre zone. Après redémarrage de bind, il se peut que la zone ne fonctionne plus. Observez le journal /var/log/messages, vous aurez probablement une alerte vous indiquant que les journaux ne sont plus exploitables. Dans ce cas, détruisez les fichiers jnl et relancez named. Bien entendu, vous aurez sans doute perdu quelques mises à jour dynamiques, mais ça devrait rentrer dans l'ordre lorsque les bauds seront renouvelés.
Du "failover" avec DHCP.
L'un des problèmes majeur de DHCP, c'est qu'il n'est normalement pas possible de faire de la tolérance de pannes. Tout au plus pouvons nous mettre deux DHCP sur le même réseau, mais distribuant des adresses dans des réserves disjointes, ce qui n'est guère commode.
Sachez que la version 3.0 permet de créer un système redondant, en créant deux serveurs qui utiliseront une réserve d'adresse commune. Je vous laisse jouer avec, pour ma part, ce sera peut-être pour plus tard.
Ma configuration actuelle pour DHCPd.
Pour finir, à titre d'exemple, voici mon fichier de configuration. Mon réseau local dispose de cinq clients "habitués", auxquels j'attribue des IP fixes. Une plage dynamique est prévue pour les "invités". # Les directives de configuration
ddns-update-style interim;
ddns-updates on;
ignore client-updates;
update-static-leases on;
ddns-domainname "maison.mrs";
max-lease-time 3600;
default-lease-time 3600;
# Les options globales
option domain-name-servers 192.168.0.253;
option subnet-mask 255.255.255.0;
option routers 192.168.0.253;
# Un seul sous réseau...
subnet 192.168.0.0 netmask 255.255.255.0 {
# Adresses dynamiques pour les invités
range 192.168.0.64 192.168.0.127;
# Et les clients habituels, en IP fixe.
host pchris {
hardware ethernet 12:05:4D:47:F8:C9;
fixed-address 192.168.0.100;
}
host pdaniel {
hardware ethernet 05:20:18:2f:a7:5e;
fixed-address 192.168.0.101;
}
host pdaniel2 {
hardware ethernet 05:20:18:2a:fE:50;
fixed-address 192.168.0.102;
}
host premi {
hardware ethernet 05:20:18:2b:fE:5B;
fixed-address 192.168.0.103;
}
host pmichele {
hardware ethernet 52:54:C5:1C:2D:03;
fixed-address 192.168.0.104;
}
}
# Pour la mise à jour dynamique du DNS local
allow unknown-clients;
zone maison.mrs. {
primary 127.0.0.1;
}
zone 0.168.192.in-addr.arpa. {
primary 127.0.0.1;
}
|