- Historique
- A quoi sert DNS dans un domaine Active Directory (AD) Windows 2000?
- Pourquoi installer un serveur Bind sur une machine Unix alors que le serveur Microsoft fait ça comme un grand?
1/ Configuration du serveur.
2/ La mise à jour des enregistrements SRV.
3/ La mise à jour des noms de machine.
1/ Du côté du serveur Windows 2000.
2/ Du côté du Serveur Linux Bind
1/ Du côté des stations:
2/ Du côté serveur DHCP.
3/ Du côté du serveur DNS
1/ Autorisation de mise à jour des zones slaves sur le serveur Linux
2/ Et mise en place des zones esclaves (secondaires sur le DC)
Du temps des réseaux Window NT4, l'intégration d'un serveur DNS dans un réseau windows était surtout utile pour l'accès des clients à des services de type internet:
- serveur www de l'entreprise
- serveur de mail de l'entreprise
- éventuellement un serveur ftp
- mettre un lien vers le monde extérieur.
L'architecture du domaine NT4 est basée sur netbios, et l'équivalent netbios
de DNS pour les grands réseau est WINS (Windows Internet Name Service).
On
peut bricoler du DNS dynamique avec un serveur microsoft NT 4.0 en indiquant au
serveur DNS Microsoft de piocher les noms des machines dans la base
WINS.
C'est pas mal, ça sert encore dans les réseaux où les machines windows
ne savent pas transmettre leur nom d'hôte au serveur DNS, mais depuis Microsoft
a fait mieux.
Pour rattraper son retard d'adaptation aux très grands réseaux, Microsoft a
racheté le principe d'arborescence à Netware, ce qui a permis de répartir des
milliers d'utilisateurs dans des domaines différents séparés par des liens
distants. Et en terme TCP/IP ce qui se rapprochait le plus de ce principe
d'arborescence, c'était DNS.
L'abandon de netbios-WINS au profit de DNS était
presque obligatoire pour deux raisons:
-Netbios est un protocole de réseau local qui fonctionne par diffusion, qui ne passe pas les routeurs (en principe).
-Les exigeances et la mauvaise qualité de WINS pour tout ce qui concerne les réplications de nom de machines le rendent mal adapté à de très grands réseaux répartis.
De ce point de vue, le fonctionnement hiérarchisé de DNS offre un très gros avantage, et permet en plus une intégration complète de Windows dans l'architecture Internet mondiale, ce qui correspond parfaitement à la stratégie commerciale de Microsoft. Microsoft a donc décidé de mettre en place le système de DNS dynamique expliqué dans la RFC 2136, et a utilisé le système des enregistrements SRV pour la résolution des principaux services du domaine.
Si vous installez windows 2000 pro ou XP dans un groupe de travail, il est
évident que l'intéret de DNS est simplement de faire DNS cache, ou de faire
joujou (ce qui n'a rien d'infâmant).
Quand on installe une station Windows
2000 sur un domaine Windows 2000, le DNS est capital: C'est celui qui permet aux
machines Microsoft de savoir qui est le contrôleur du domaine (serveur LDAP),
qui est le serveur Kerberos, quels sont les autres serveurs AD sur les autres
sites Microsoft. L'architecture AD a pour clé de voute DNS.
Exemple:
J'installe ma station Windows 2000. Je lui dis que son adresse IP est
192.16.3.5, et que son serveur DNS est la machine 192.16.3.1. Puis
l'installateur me demande si je veux la mettre dans un groupe de travail ou dans
un domaine. J'ai un domaine windows 2000, qui s'apelle toto.net, je lui dis donc
de rejoindre le domaine toto.net. Ma machine va donc interroger le serveur DNS
pour savoir si pour le domaine toto.net il y a un serveur AD: "As-tu un
enregistrement de type:
_tcp.pdc._msdcs.toto.net. ?" réponse du serveur DNS:
"oui, c'est la machine tata.toto.net". re-demande du client, "quelle est
l'adresse de la machine tata.toto.net?", et réponse: c'est la machine 192.16.3.1
(lui-même). Donc s'il n'y a pas de DNS sur le réseau ou que le DNS ne sait pas
donner l'enregistrement de type _tcp.pdc._msdcs.toto.net., rien ne marche et le
client ne peut pas rejoindre le domaine. Sur un réseau local, ça n'a rien de
dramatique, le client peut se rabattre sur une demande par diffusion netbios
(mode de compatibilité descendante - on enregistre la machine sur l'ancien nom
de domaine, celui qui sert pour les machines NT4-Win9x), mais si le serveur AD
est derrière un routeur, c'est cuit!
On voit donc que DNS en environnement MS, ce n'est plus de la rigolade pour admin en herbe qui se fait la main, il faut que ça marche. Pour cette raison, Microsoft lors de la première installation d'AD sur le premier contrôleur de domaine de la forêt, propose l'installation d'un serveur DNS sur la machine, si on ne lui a pas déjà donné l'adresse d'un autre serveur DNS (Microsoft, ou supportant les mises à jours dynamiques et les enregistrements SRV.
Si on désire installer un serveur DNS dans un domaine Windows 2000, il faut donc que celui-ci supporte à la fois les mises à jour dynamiques ET les enregistrements de type SRV.
Plusieurs raison vont du : "parce que j'ai envie, et que je fais tout pour éjecter MS de mon réseau", à "parce que mon responsable info m'a dit de faire comme ça, et je suis un tech bête et obéissant". Entre autres:
- Mon contrôleur de domaine a déjà assez de boulot comme ça, j'ai une machine Unix qui passe ses journées à décoder du RC5, on va la faire bosser.
- J'aime Linux, DNS, c'est une affaire de machine Unix depuis des dizaines d'années, il n'est pas question de laisser faire ce job par un sale serveur Microsoft incompétent.
- J'ai 800 postes en adressage fixe, un serveur DNS qui permet d'accéder à l'intranet de la société, 60 noms inscrits dans les fichiers de zone, je n'ai pas que ça à faire, de faire la tournée des popottes sur 800 postes, et de me retaper ces 60 enregistrements et leurs pointeurs.
- J'ai 200 postes en adressage dynamique, un serveur DNS qui tourne sur une machine dans un coin, on a rebooté tout ça il y a 6 mois, ça tourne bien on ne va pas changer une équipe qui gagne, avec BIND sur mon serveur Linux, je sais où je vais, je connais moins bien Microsoft, je vais modifier ma déclaration de fichiers de zones et mon serveur DHCP, pour se mettre à jour, ça va me prendre 1h, et je n'aurai plus besoin d'y toucher pendant des mois.
- Ma petite amie qui ressemble à une "Bellaminette" adore Linux, et va me quitter si le serveur DNS ne tourne pas sous Linux - imparable.
Il y a deux choses à voir, que l'on peut traiter de manière différente:
les noms des machines, et les enregistrements SRV
Il y a une chose complètement indépendante que l'on peut décider: mettre ou
non les machines sur un domaine DNS différent du domaine AD.
C'est possible,
cela permet de segmenter les zones plus facilement. C'est une option proposée
par Microsoft dans un de ses livres
blancs.
Il faut pour cela :
- faire un clic droit sur poste de
travail, puis propriété
- cliquer sur l'onglet "nom de l'ordinateur", puis
sur le bouton "modifier"
- cliquer sur "autres", décocher la case "modifier
le suffixe dns..."
- mettre le nom dns qu'on veut à la machine et qui est
différent du nom dns du domaine AD
cliquer sur OK jusqu'à revenir au bureau
et redémarrer.
Personnellement, je n'ai pas voulu faire comme ça, et
d'ailleurs Microsoft ne pousse pas spécialement, dans ce sens, et puis de toutes
manières ça ne rêgle pas du tout la suite: quelle méthode va-t-on utiliser pour
mettre à jour les enregistrements DNS des machines.
On va commencer par le plus simple (à mon avis): que le serveur BIND puisse recevoir des enregistrements SRV, et puis on finira par les enregistrements des machines
A ce stade là, je vais décrire la config sur laquelle j'ai mis ma solution en
place, il pourra y avoir des différences avec la votre.
Debian 2.2r3 à
l'origine, depuis elle est en partie en unstable.
les paquetages sont bind9.2
et dhcp3. Sont les deux dernières versions de l'isc mise à ma disposition en
paquetage .deb.
Avant cette mise à jour, la machine tournait avec un bind 8.3
et dhcp2 (on le voit sur une des captures d'écran). Cette précision est
peut-être importante, si vous avez la même configuration que moi et que les
résultats diffèrent. Le serveur tournait sans soucis depuis plusieurs mois avec
bind et dhcp. (srvinfo:~# uptime 4:08pm up 115 days, 15:56, 4 users, load
average: 1.00, 1.00, 1.00) ;-)
Tout ça pour dire que je ne pars pas d'une
installation neuve et propre et que si vous faites tourner une mandrake ou une
redhat, il faudra vous débrouiller un peu, si tout ne se ressemble pas.
(emplacement des fichiers de conf, notamment.)
J'ai privilégié la facilité de
mise en place au détriment de la sécurité et du chiffrement des transactions.
Soit mon domaine: intrafp.net
Soit mon serveur dns: 192.0.2.134
(srvinfo)
Soit mon serveur dhcp: 192.0.2.134 (le même)
Soit mon contrôleur
de domaine: 192.0.2.128 (srvprod)
Donc! Je disais quelle stratégie pour:
On a deux solutions:
- Sur le contrôleur AD (DC Windows 2000) on déclare le serveur Linux comme étant son serveur DNS (Les machines Windows 2000 ou supérieures cherchent automatiquement à s'inscrire auprès du DNS qui leur est assigné); dans ce cas là, on va paramétrer Linux pour accepter des mises à jour de la part du contrôleur AD. Dans ce cas là, du côté de bind, la configuration va très fortement ressembler à celle utilisée pour la mise à jour du nom des stations. Il suffira d'adapter.
- Soit on utilise le contrôleur AD comme hébergeur des zones principales, et le serveur Linux héberge les zones secondaires, et c'est lui qui reçoit toute la charge de connexion des clients. Régulièrement le contrôleur AD notifie le serveur Linux des modifications. C'est la solution que j'ai adoptée: Les fichiers de zone ne sont que des répliques des fichiers de zone Windows. Ca m'a semblé plus aisé comme mise en place, et ça me permet d'avoir le contrôleur AD en secours si le serveur Linux tombe.
Là, c'est un peu la même chose:
- Soit on dit aux machines de s'inscrire comme des grandes auprès du serveur DNS. Il faut autoriser tout un réseau à mettre à jour les fichiers de zone. C'est à mon avis la pire solution. La plus facile, mais la moins sécurisée. N'importe quelle machine peut venir pourrir vos fichiers de zone. On a beau être derrière un firewall, faut pas pousser non plus.
- Soit c'est le serveur DHCP qui met à jour les enregistrements. Dans ce cas là, on n'autorise qu'une machine à faire les mises à jour: le serveur dhcp. Dans mon cas, c'est la même. Il est à noter que les dernières versions de dhcp savent faire du failover, et détectent conflits d'adresse IP (ce qui est indispensable pour une bonne gestion du failover.). C'est la solution que j'ai adoptée.
- La troisième solution, la plus sécurisée, reprend la deuxième, mais permet de n'autoriser la mise à jour que depuis les serveurs dhcp ou dns qui auraient la même clé que notre serveur dns. C'est super bien, mais je pense qu'il est préférable d'entreprendre cette méthode quand on est certain que les autres méthodes marchent.
Cette méthode est documentée dans la page man de dhcpd.conf pour dhcpv3.
Voilà! on a fait le tour des grands principes, maintenant, il faut mettre les mains dans le cambouis. C'est bien gentil de causer, de la terre, des abeilles, Microsoft et DNS, mais on se met au boulot.
On va se placer pour l'exemple et les captures d'écran sur mon DC qui se trouve sur le domaine intrafp.
Au départ, à l'installation du premier contrôleur de domaine, et pour ne pas
s'embêter, je conseille très vivement d'utiliser un serveur DNS microsoft
Windows 2000 pour l'enregistrement. Une migration windows 2000, ce n'est pas
trop marrant (personnellement, j'ai moyennement ri), surtout quand on est
environnement de production, et que tout doit se faire de manière transparente
pour les utilisateurs. Donc on va partir du principe qu'à l'installation, vous
avez créé deux zones: la zone de recherche directe, et la zone inverse. Vous
avez cliqué là où il faut pour que la mise à jour des zones se fasse de manière
dynamique. Si vous ne savez pas faire ça, ce n'est pas la peine d'aller plus
loin, vous vous documentez, vous acheter un bouquin ENI ou Microsoft, vous
cherchez sur le Web, vous vous entraînez, vous faites quelque chose, mais vous
n'installez pas un serveur en production, sinon, c'est la cata.
Donc, le fait
de permettre la mise à jour dynamique des fichiers de zone va peupler ceux-ci
d'une drôle d'arborescence, en plus du nom des machines: ce sont les
enregistrements SRV. Les enregistrements A ont une tête de fichier texte, mais
pour les autres c'est plutôt une emboîtement de sous dossier. C'est cette
arborescence qu'on va faire mettre à jour sur le serveur bind. A partir de la
racine du domaine, on trouve 4 classes d'enregistrements: _msdcs, _sites, _tcp,
_udp.
Il faut supprimer ces enregistrements, et créer une nouvelle zone pour
chacune de ces grandes classes (laissez tout de même la zone principale et la
zone inverse!). Microsoft conseille de créer des zones active directory,
personnellement, j'ai préféré créer des zones primaires classiques:
Nouvelle
zone, suivant, zone principale standard (mais si vous voulez, rien ne vous
empêche de mettre zone principale AD) et suivant
Renseignez le nom de la zone
(_msdcs.intrafp.net), suivant, vous créez un nouveau fichier du nom que vous
voulez, suivant, et terminer.
Votre fichier de zone est créé. Vous activez la mise à jour dynamiques, et
vous allez dans l'onglet "transfert de zone", vous cliquez sur "uniquement vers
les serveurs suivants", vous entrez l'adresse de votre bind, vous cliquez sur le
bouton "avertir", puis cocher "les serveurs suivants" entrez l'adresse de votre
bind pour que celui-ci soit notifié à chaque mise à jour de la zone, puis vous
faites ok. Fini pour cette zone.
Vous faites pareil pour les suivants:
_sites, _tcp, _udp.
Vous faites redémarrer le service dns, vous attendez et
vos zones vont se peupler miraculeusement. Merci Bill, merci Tux.
Ca doit
ressembler à ça:
On y voit bien l'arborescence avec les 5 zones directes: _msdcs.intrafp.net,
_sites.intrafp.net, _tcp.intrafp.net, _udp.intrafp.net, intrafp.net
et aussi
les enregistrements qu'elles contiennent: _gc, _ldap, _kerberos, et les serveurs
qui hébergent ces enregistrements (srvprod et tempon-exchange).
Bien!! Maintenant qu'on est à peu près sur des zones maîtres (principales), on va passer aux zones (esclaves) sur le serveur bind.
On a le choix de commencer par modifier le fichier named.conf ou par créer les fichiers de zone.
Soyons fous, commençons par les fichiers de zone. Pas besoin d'aller chercher
midi à 14h:
moi, je mets mes fichiers de zone dans /etc/bind/, ça me permet
de tout avoir sous la main, mais vous pouvez les mettre où vous voulez:
touch _msdcs _sites _tcp _udp srvinfo:/etc/bind# ls _* _msdcs _sites _tcp _udp |
bref! ça roule, nos fichiers sont créés.
Maintenant, plus marrant, on modifie named.conf
Dans mon named.conf, il y avait ça:
key "key" {
algorithm hmac-md5;
secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};
controls {
inet 192.0.2.134 allow { 192.0.2.134; } keys { "key"; };
}; |
Ca sert à s'assurer que seule une machine qui possède cette clé (il faut en générer une autre, car toutes les machines debian ont la même) puisse mettre à jour les fichiers de zone. Je voulais quelque chose de simple, et je ne voyais pas trop comment faire avec les serveurs Microsoft, j'ai donc tout commenté. (voir plus haut, dans le cas des noms des stations ce que j'ai considéré comme la solution 3.
J'ai déclaré mes zones comme s'il s'agissait de zones classiques, sauf que je
les ai déclarées slave, et que j'ai déclaré le master.
voyez sur l'exemple,
il est déjà commenté, c'est plus rapide:
/// Les lignes suivantes définissent les fichiers de zone secondaires
/// utilisées par Active Directory, dont la mise à jour est assurée
/// par le serveur de nom du domaine intrafp.net : srvprod.intrafp.net
/// Les zones sont de type slave.
/// Les fichiers s'appellent du nom de la zone mais sans intrafp.net
/// Seul le DC a le droit de mettre à jour (c'est un minimum de sécurité
/// Avec Bind 8.2 il faut mettre la directive "check-names ignore" parce que les "_" ne
/// sont pas des caractères valides sous DNS, mais avec bind 9.2 cette directive
/// n'existe plus. Je l'ai donc supprimée
/// les zones sont: _msdsc, _sites, _tcp, udp
zone "_msdcs.intrafp.net"{
type slave;
file "/etc/bind/_msdcs";
masters {192.0.2.128;};
};
zone "_sites.intrafp.net"{
type slave;
file "/etc/bind/_sites";
masters {192.0.2.128;};
};
zone "_tcp.intrafp.net"{
type slave;
file "/etc/bind/_tcp";
masters {192.0.2.128;};
};
zone "_udp.intrafp.net"{
type slave;
file "/etc/bind/_udp";
masters {192.0.2.128;};
};
|
Une fois que c'est fini, il ne reste plus qu'à redémarrer
bind:
/etc/init.d/bind9 restart
n'oubliez pas de jeter un coup d'oeil aux logs pour vérifier que toutes les zones ont été correctement lancées et mises à jour, et que vous n'avez pas de coquille dans votre named.conf:
tail /var/log/syslog
et/ou
tail /var/log/daemon.log
Quelques minutes plus tard, on a de jolis fichiers de zones peuplés de jolis
enregistrements SRV.
Attention, ça peut mettre quelques minutes à arriver. Si
ça n'arrive pas, y a un truc, persévérez ça va venir.
srvinfo:/etc/bind# ls -l _*
-rw-r--r-- 1 root root 1679 mai 27 16:58 _msdcs
-rw-r--r-- 1 root root 778 mai 27 17:07 _sites
-rw-r--r-- 1 root root 848 mai 27 17:05 _tcp
-rw-r--r-- 1 root root 698 mai 27 16:55 _udp
srvinfo:/etc/bind#
srvinfo:/etc/bind#
srvinfo:/etc/bind# cat _msdcs
; BIND version named 8.3.1-REL-NOESW Sat Apr 20 09:01:32 MDT 2002
; BIND version lamont@whatone:/usr/local/src/Packages/bind/bind-8.3.1/src/bin/named
; zone '_msdcs.intrafp.net' first transfer
; from 192.0.2.128:53 (local 192.0.2.134) using AXFR at Wed May 22 18:23:48 2002
; NOT TSIG verified
$ORIGIN intrafp.net.
_msdcs 3600 IN SOA srvprod.intrafp.net. admin.intrafp.net. (
20 900 600 86400 3600 )
3600 IN NS srvprod.intrafp.net.
3600 IN NS srvinfo.intrafp.net.
$ORIGIN _msdcs.intrafp.net.
cf04f2b9-6402-4b61-952b-a40c23818509 600 IN CNAME tempon-exchange.intrafp.net.
$ORIGIN _tcp.premier-site-par-defaut._sites.dc._msdcs.intrafp.net.
_kerberos 600 IN SRV 0 100 88 srvprod.intrafp.net.
600 IN SRV 0 100 88 tempon-exchange.intrafp.net.
_ldap 600 IN SRV 0 100 389 srvprod.intrafp.net.
600 IN SRV 0 100 389 tempon-exchange.intrafp.net.
$ORIGIN _tcp.dc._msdcs.intrafp.net.
_kerberos 600 IN SRV 0 100 88 srvprod.intrafp.net.
600 IN SRV 0 100 88 tempon-exchange.intrafp.net.
_ldap 600 IN SRV 0 100 389 srvprod.intrafp.net.
600 IN SRV 0 100 389 tempon-exchange.intrafp.net.
$ORIGIN _tcp.3fffb21e-cee9-4450-83bc-ee56f809a524.domains._msdcs.intrafp.net.
_ldap 600 IN SRV 0 100 389 srvprod.intrafp.net.
600 IN SRV 0 100 389 tempon-exchange.intrafp.net.
$ORIGIN _msdcs.intrafp.net.
ead21d3b-b763-4315-8cef-1fc56c0a8e7c 600 IN CNAME srvprod.intrafp.net.
gc 600 IN A 192.0.2.128
$ORIGIN _tcp.premier-site-par-defaut._sites.gc._msdcs.intrafp.net.
_ldap 600 IN SRV 0 100 3268 srvprod.intrafp.net.
$ORIGIN _tcp.gc._msdcs.intrafp.net.
_ldap 600 IN SRV 0 100 3268 srvprod.intrafp.net.
$ORIGIN _tcp.pdc._msdcs.intrafp.net.
_ldap 600 IN SRV 0 100 389 srvprod.intrafp.net.
srvinfo:/etc/bind#
|
Le test qui dit oui ou qui dit non, maintenant, c'est de faire joindre le
domaine à une machine!
Si vous n'en avez qu'une, vous la sortez du domaine
pour la mettre en workgroup, et vous redémarrez.
Un fois redémarrée, vous lui faites joindre le domaine. Attention! Il ne
s'agit pas de lui faire joindre le domaine sous sa forme compatible NT du style:
MON-DOMAINE, mais mon-domaine.net. Là, vous saurez vraiment si votre station
récupère les informations SRV depuis bind. Si ça ne fonctionne pas, vous ne
pourrez même pas mettre le nom et mot de passe de l'admin, ça vous dira que le
domaine est introuvable.
Voilà. Maintenant, l'essentiel est fait: Vos clients peuvent se servir de votre serveur DNS bind pour tout ce qui concerne le réseau. Si le serveur Windows 2000 crashe, il sera toujours là pour indiquer aux client quel est le serveur de messagerie, ou pour indiquer une autre DC.
Pas grand chose à faire. Si aucun nom d'hôte n'est indiqué dans les
paramètres réseau, c'est le nom netbios de la machine qui est utilisé.
C'est
le serveur DNS qui indique la zone à laquelle la machine appartient. Le
fonctionnement est le même, que la machine soit sous Windows 9x, Windows 2000/XP
ou Windows NT.
Oui, il faut bien démarrer par l'un ou par l'autre, et tant qu'à faire autant s'occuper d'abord du mécanisme qui va "nourrir" les fichiers de zone.
Pour DHCP, donc, la principale documentation, c'est la page man de dhcpd.conf, je vous invite à vous y reporter après avoir lu ma méthode, cela vous permettra de comprendre plus en détail les mécanismes de mise à jour. La méthode de mise à jour a nettement changé entre la version 2 et la version 3 de dhcp. Ils continuent de documenter l'ancienne méthode (appelée ad-hoc) mais conseillent très nettement d'utiliser la nouvelle (appelée interim). On trouve donc facilement de la documentation et des exemples de fichier dhcpd.conf utilisant la méthode "ad-hoc", mais j'ai utilisé suivant leurs conseils, la méthode interim que voici.
Si vous migrez de dhcpv2 à v3, faites attention, l'emplacement du fichier
dhcpd.conf a peut-être changé. Chez moi, il est passé de /etc/ à /etc/dhcp3.
Vous risqueriez de faire des modifications non-prises en compte; ça marcherait
nettement moins bien ;-)
Votre serveur dhcp doit être totalement fonctionnel
et testé avant d'entreprendre la suite. Ca me semble presque évident, mais je
préfère le préciser.
Ensuite, il suffit d'ajouter ces deux lignes au fichier dhcpd.conf:
ddns-update-style interim;
ignore client-updates;
En plus de la classique option de déclaration du nom du domaine:
option domain-name "intrafp.net";
La valeur ddns-update-style peut prendre deux valeurs: ad-hoc et interim.
Note: J'ai trouvé que la page man de dhcpd.conf était floue en ce qui concerne la valeur ad-hoc. Elle dit d'une part que son usage est désormais (comprendre avec la version 3 de dhcp) dépréciée et ne marche pas, et quelques lignes plus loin, dit que celle-ci ne fonctionne pas si le serveur est configuré en "failover" (cela veut-il dire qu'il n'y a que dans ce cas que ça ne fonctionne pas?)...
J'ai donc utilisé, la méthode interim. Lorsque l'on déclare la
méthode de mise à jour interim,
il faut aussi donner mettre l'option client-updates. Cette option prend soit la
valeur allow, soit la valeur
ignore.
La valeur allow permet au client d'envoyer lui
même son FQDN (fully qualified domain dame) au serveur DNS (c'est un peu plus
complexe, mais je vous conseille de vous reporter à la page man de dhcpd.conf
pour les détails).
Si jamais le client ne le fait pas ou si client-updates a la valeur ignore, c'est le serveur DHCP qui le
fait (il peut le faire à partir des informations données par le client, si
celui-ci a fourni un hostname), et en y ajoutant la valeur option domain-name du fichier
dhcpd.conf. (pour en savoir plus toujours la partie dynamic dns update du man
dhcpd.conf)
Je ne dirai rien de l'autorisation de mise à jour par clé, elle aussi détaillée dans la page man, elle fonctionne de pair avec une ACL dans le fichier named.conf. Une fois que tout fonctionne correctement par la méthode interim, vous pouvez vous lancer dans les autorisations par clés.
redémarrez le serveur dhcp (/etc/init.d/dhcp3 restart, chez moi) et regardez si les logs ne crachent rien de suspect (tail /var/log/syslog)
Arrêtez le démon bind pour modifier les fichiers de zone ("/etc/init.d/bind9 stop" chez moi), et sauvegardez votre fichier named.conf et vos fichiers de zone.
On va autoriser l'accès en modification sur les fichiers de zone de notre
domaine. Là encore, il est capital que vos fichiers de zone soient tout à fait
fonctionnels de la première à la dernière ligne, sinon, ça risque d'être la
panique, ou tout bêtement de ne pas fonctionner (j'ai perdu pas mal de temps
avec ça).
Pour dire quelle machine a le droit de mettre à jour le fichier de
zone, le plus rigoureux est de définir une acl, puis de renvoyer ensuite à cette
acl.
exemple:
acl "clients-dhcp" {
192.0.2.134;
};
Mais comme j'ai juste une machine qui fait les mises à jour, je l'ai simplement mise dans la directive allow-update comme suit:
zone "intrafp.net"{
type master;
file "/etc/bind/intrafp.net";
allow-update {192.0.2.134;};
};
zone "2.0.192.IN-ADDR.ARPA"{
type master;
file "/etc/bind/192.0.2";
allow-update {192.0.2.134;};
};
|
au lieu de mettre allow-update {"clients-dhcp";};
Mais si vous voulez spécifier plus de deux machines ou un réseau IP, l'utilisation d'un acl est plus que conseillée.
Normalement, c'est suffisant, il suffit de redémarrer le serveur
(/etc/init.d/bind9 start). A ce stade là, on ne voit rien. le répertoire des
fichiers de zone ne change pas.
En revanche, il suffit dans une console sur
une machine NT de faire ipconfig
/release puis ipconfig /renew
pour voir apparaître des fichiers .jnl du même nom que nos fichiers de
zone:
-rw------- 1 root root 3037 mai 27 13:56 intrafp.net -rw-r--r-- 1 root root 36761 mai 27 13:41 intrafp.net.jnl -rw------- 1 root root 1205 mai 27 13:56 192.0.2 -rw-r--r-- 1 root root 6380 mai 27 13:41 192.0.2.jnl |
Si vous avez ça, c'est gagné. Maintenant, amis de l'ordre et des fichiers de zone aux petits oignons, munissez vous d'un mouchoir, car la moulinette vas leur laisser une drôle d'allure!
srvinfo:/etc/bind# cat intrafp.net
$ORIGIN .
$TTL 54800 ; 15 hours 13 minutes 20 seconds
intrafp.net IN SOA srvinfo.intrafp.net. hostmaster.srvinfo. (
2001070645 ; serial
3600 ; refresh (1 hour)
900 ; retry (15 minutes)
1209600 ; expire (2 weeks)
43200 ; minimum (12 hours)
)
NS srvinfo.intrafp.net.
$TTL 600 ; 10 minutes
A 192.0.2.128
A 192.0.2.136
$ORIGIN intrafp.net.
$TTL 21600 ; 6 hours
axel A 192.0.2.23
TXT "310d8d59373af280b893047e822604bf48"
blandineg A 192.0.2.41
TXT "3188f36533668176c6b4a48bd5663491ab"
carole A 192.0.2.50
TXT "3130002a5fb9c7fb8b206731902b6fd55a"
cecilesantz A 192.0.2.28
TXT "3129f222d2b5069b5f10772e7e358514a1"
charlotte A 192.0.2.51
TXT "311454954afa7eaa93b62bb639f1e3501f"
$TTL 54800 ; 15 hours 13 minutes 20 seconds
copieur_bas A 192.0.2.2
copieur_haut A 192.0.2.3
$TTL 21600 ; 6 hours
devpt2 A 192.0.2.30
TXT "31b9ce704bb4d1efe638369211e848b7d4"
|
Si vous êtes comme moi, la première réaction, est une grosse
surprise.
Déjà, vous n'aviez peut-être pas mis l'en-tête du fichier de cette
manière, et le pire, c'est: "qu'est-ce qu'il vient me mettre la zone avec ses
enregistrements TXT"
La réponse
se trouve dans le man dhcpd.conf (vous n'avez pas fini par le lire en entier,
depuis le temps que j'en parle?)
Ca sert au système de mise à jour à ne pas
écraser un enregistrement ajouté manuellement: Chaque fois qu'un nouvel
enregistrement est ajouté dynamiquement, on positionne une zone de texte du même
nom que l'enregistrement A. Quand la fois suivante, le système de mise à jour
essaie de mettre à jour l'enregistrement, il trouve un enregistrement A du même
nom. Si pour ce nom là il existe un enregistrement TXT, il effectue la mise à
jour. Dans le cas contraire, cela veut dire que l'enregistrement a été écrit
manuellement, et qu'il ne doit pas être écrasé.
IVALA!!!
Au fur et à mesure que vos clients vont s'enregistrer auprès du DHCP,
celui-ci ajoutera aux fichiers journaux les enregistrements A et PTR.
De
temps en temps le fichier journal ajoutera des enregistrements au fichier de
zone. Il le fera aussi systématiquement à chaque arret du serveur DNS.
Laissez mouliner quelques temps pour voir grossir les fichiers jnl, testez avec nslookup ou hosts ou dig, pour vérifier que tout fonctionne. Ben alors? QuiQuaDit que Microsoft c'était le plus fort? On fait la même chose avec le volatile des pays froids, et en plus, on sait comment ça marche!! Elle est pas belle la vie?
Pour résumer:
Nous avons sur le DC Windows, des zones principales pour _msdcs, _sites, _tcp, _udp. Ces zones sont répliquées sur le serveur Linux. Cela permet aux machines Windows de trouver les services Active Directory.
Et puis nous avons les zones principales contenant les machines elle-mêmes,
et les zones inverses qui en dépendent, sur le serveur Linux: intrafp.net et
2.0.192.in-addr.arp. Ca marche bien, les machines peuvent se pinger, tout
ça...
Oui, mais on a un problème: Nous avons ajouté notre machine au domaine.
Elle a trouvé les services du domaine, ça a eu l'air nickel, il faut redémarrer
le client Windows, suite à l'ajout dans le domaine, et là, se pose un soucis: au
redémarrage, ça nous dit que non, la machine n'a pas de compte dans le domaine,
comme si on ne l'avait pas ajoutée.
Le problème, c'est que les clients Windows ont pour serveur DNS le serveur Linux, et donc ils peuvent effectuer une résolution DNS, mais le contrôleur de domaine, vu qu'il est son propre serveur DNS n'a pas, lui, la résolution des noms des machines, et donc quand on ajoute la machine au domaine, il dit qu'effectivement, on a le droit d'ajouter cette machine au domaine, mais il n'arrive pas à l'inscrire proprement, parce que il ne peut résoudre le nom d'hôte. Il faut donc créer une zone esclave sur le DC Windows 2000, donc le maitre est la zone du serveur Linux
Au final, on a donc:
| Serveur Linux | DC Windows 2000 |
| zones de gestion AD slave | zones de gestion AD master |
| zones de gestion des machines master | zones de gestion des machines slave |
C'est parti!
Pour avoir les directives détaillées, rien de mieux qu'un coup d'oeil à la doc de bind 9. C'est un peu éparpillé, mais globalement, on va utiliser les directives: notify, also-notify et allow-transfer.
-notify, va permettre au serveur esclave de demander une mise à jour du fichier de zone
-also-notify permet l'envoi d'une notification de mise à jour la mise à jour sur toutes les machines déclarées par cette directive, en plus de celles déclarées comme serveur de nom (enregistrement NS)
-allow-transfert déclare les serveurs autorisés à recevoir un transfert de zone
Au total, la déclaration de fichier de zone dans le named.conf, ressemble à ça:
zone "intrafp.net"{
type master;
file "/etc/bind/intrafp.net";
allow-update {192.0.2.134;};
notify yes;
also-notify {192.0.2.128;};
allow-transfer {192.0.2.128;};
};
zone "2.0.192.IN-ADDR.ARPA"{
type master;
file "/etc/bind/192.0.2";
allow-update {192.0.2.134;};
notify yes;
also-notify {192.0.2.128;};
allow-transfer {192.0.2.128;};
|
redémarrer le serveur: /etc/init.d/bind9 restart
un coup d'oeil dans les
logs: tail -n30 /var/log/syslog
Tout va bien, on peut passer à la suite. Si ça ne va pas, c'est très certainement un problème de syntaxe.
Là encore, ça n'a rien de difficile:
-dans le gestionnaire dns de Windows 2000, se positionner sur: zone de recherche directe.
-clic droit, nouvelle zone, suivant, zone secondaire standard, suivant
-entrer le nom de la zone (le même nom que sur le serveur Linux), chez moi c'est "intrafp.net", suivant
-entrer l'adresse du serveur DNS de la zone maitre (principale) chez moi, c'est 192.0.2.134, et suivant
-terminer.
La zone est créée. Si elle ne se peuple pas immédiatement, un clic droit sur la zone, puis transfert à partir du maître Et ça devrait être bon. Si ça ne se peuple toujours pas, redémarrez bind sur le serveur Linux. Le fait de redémarrer le serveur, provoque l'envoi d'un notification de modification de zone aux serveurs esclaves. A partir de là, ce sera bon.
C'est la même chose pour la zone inverse, qu'il ne faut pas oublier de créer.
C'est un point crucial.
On a vu que pour que tout fonctionne correctement, il faut qu'on puisse faire des mises à jour dans les 2 sens:
Les machines mettent à jour les enregistrements du serveur Linux qui les répercute sur le serveur Windows, et le serveur Windows répercute la modification des enregristrements SRV sur serveur Linux. Mais à bien y réfléchir, il manque un détail:
Si nous ajoutons un serveur au domaine, quel serveur DNS allons-nous lui attribuer?: le serveur Linux, ou le serveur Windows? Et comment cela va-t-il se passer?
Personnellement, j'ai fait le choix de déclarer le serveur Windows comme DNS
de tous mes contrôleurs de domaine et de tous mes serveurs.
Si j'avais fait
l'inverse, mon serveur Linux aurait sans doute essayé de faire une mise à jour
des zones du serveur Windows, et comme mes machines sont en prod, je n'ai pas
voulu tester, mais je suis ouvert à tout retour d'expérience à ce
sujet.
Il se passe quelque chose de curieux: Je déclare sur mon nouveau
serveur, l'adresse 192.0.2.128 comme serveur DNS.
A le nouveau serveur essaie
donc d'ajouter son adresse aux zones existantes. J'ai autorisé le serveur Linux
à être mis à jour par le serveur Windows, donc en toute logique, la zone sur le
serveur Windows étant une zone esclave, elle va essayer de passer le bébé à la
zone principale du serveur Linux. Ce n'est pas ce qu'il se passe.
En fait, mon nouveau serveur essaie de mettre à jour le serveur Windows, qui doit lui retourner une erreur et lui dire que le serveur de la zone principale, c'est le serveur Linux, et donc le nouveau serveur se retrourne vers la zone principale, essaie de la mettre à jour... ... et échoue aussi, parce qu'elle ne fait pas partie des serveurs autorisés à modifier les zones. Il faut donc ajouter une nouvelle adresse autorisée à modifier les fichiers de zone dans le named.conf. Si on a plusieurs serveurs à ajouter, le mieux est d'utiliser une ACL, comme expliqué plus haut.
Hé bien... que dire?...
Soit ça marche, soit ça ne marche pas. Si ça
marche, bravo!! Si ça ne marche pas dans un permier temps, il faut examiner les
fichiers de logs pour savoir à quel niveau ça ne marche pas. Mais à priori, si
votre serveur DNS était pleinement fonctionnel juste avant de faire toutes les
manips, je ne vois pas pourquoi ça ne marcherait pas. Il est excessivement
important de faire attention au moindre ".", au moindre espace dans la
configuration des fichiers de zone sous Linux.
Si vous souhaitez une configuration mieux sécurisée, appuyez vous sur la "webographie" ci-dessous. DNS et DHCP fournis par l'ISC devraient bientôt fournir d'autres types de mise à jour que ceux fournis actuellement qui devraient encore plus coller à un environnement Windows 2000. Il peut-être intéressant de garder un oeil sur leur site pour voir ce qui en sort.
Bon!! et maintenant, l'instant que vous attendez tous: la Webographie, pour enfin avoir tous les détaills. C'est presque tout en anglais, sortez les dicos.
Pour bien commencer: un HOWTO:
http://www.tldp.org/HOWTO/DNS-HOWTO.html
et un petit lien de mise en place d'un DNS tout bête:
http://www.toolinux.com/linutile/reseau/dns/index.htm
Vous en avez aussi un très bien chez linux-france.org
http://www.linux-france.org/article/serveur/dns.html
Pour bien continuer:
Le document microsoft qui permet de faire ce qu'il faut pour leur propre
plateforme:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q255913
un ch'tit lien qui peut aider à comprendre. On comprend parfois mieux quand
c'est dit autrement:
http://www.jpsdomain.org/linux/linux.html#dhcp-dns
Et puis bien sur, la documentation de bind:
http://www.nominum.com/resources/documentation/Bv9ARM.pdf
Mais aussi la page man de dhcpd.conf
Le dernier lien est sans doute celui qui m'a le plus aidé:
http://www.abul.org/
Pour les remarques
Gentilles ou méchantes, les corrections:
fclercATlinux-france.org
rantamplanATseldon.dyndns.org
Merci à ma plante verte, mon chat, mon micro, mon écran et mon clavier pour leur soutien indéfectible.