J'ai déjà parlé de DNS (Domain Name System) : les serveurs DNS sont des machines dont le rôle est de faire la corrélation entre un nom de machine (par exemple, machine1.beaubleu.com) et son adresse IP (192.126.7.14).
Beaucoup d'entre vous ont cependant sûrement entendu parler du système WINS (Windows Internet Naming Service) présent sur les systèmes Microsoft (serveurs NT), et qui, de loin, semble faire la même chose.
Alors qu'en est-il ? Pourquoi Microsoft aurait-il créé un nouveau système ?
Hors des réseaux Microsoft, le problème se réduit simplement à dire que les machines sont identifiées par une adresse IP et un FQDN (Fully Qualified Domain Name ou nom de domaine pleinement qualifié) de type Internet (par exemple machine1.beaubleu.com; machine1 est le hostname de la machine; beaubleu.com est le domaine Internet).
Pour résoudre un FQDN en adresse IP, ou inversément, c'est le système DNS qui est utilisé. Un point c'est tout.
Revenons dans le monde Microsoft. Les anciens réseaux Microsoft étaient basés sur le protocole NetBEUI (ce protocole est encore largement utilisé dans les petits réseaux locaux). Sur ces réseaux, les machines sont identifiées par un nom NetBIOS, par exemple, machine2, et leur adresse physique de carte réseau. C'est tout. Mais dites-vous bien que ce nom NetBIOS n'a, à priori, rien à voir avec un hostname Internet !
Lorsque vous installez le protocole TCP/IP sur un ordinateur Microsoft, vous remarquez que l'OS remplit le champ "hostname" (de l'onglet DNS) avec le même nom que le nom NetBIOS, mais ce sont bien deux choses différentes.
Il me faut maintenant faire une petite digression sur les applications qui utilisent le réseau. Dans le monde Microsoft, on en trouve principalement de deux sortes :
Le protocole TCP/IP de Microsoft a ceci de particulier qu'il supporte ces 2 API grâce à une couche discrète : NBT (NetBIOS Over TCP/IP). Un exemple typique est celui de la commande NET de Microsoft (par exemple Net Use) : cette commande est fondamentalement une commande basée NetBIOS; elle ne devrait, en principe, pas fonctionner avec des hostnames TCP/IP. Pourtant, grâce à NBT, une commande 'Net Use * \\hostname_TCPIP\ressource' sur un réseau n'utilisant que le protocole TCP/IP fonctionne très bien.
Imaginons un réseau Microsoft n'utilisant que TCP/IP comme protocole, et regardons ce qui se passe au niveau de la liste d'ordinateurs présents dans le voisinage réseau. Bien que cette liste, appelée "liste browse", soit une applications basée NetBIOS, tous les ordinateurs (fonctionnant sous Microsoft je précise) pourront se voir dans le voisinage réseau, pour peu qu'ils soient sur le même segment Ethernet, cela grâce à NBT.
Par contre imaginons un réseau TCP/IP composé de deux sous-réseaux séparés par un routeur :
Dans un tel réseau, un ordinateur du réseau A ne verra dans son voisinage réseau que les ordinateurs de son sous-réseau, et non les ordinateurs du sous-réseau B; de façon analogue, un ordinateur du réseau B ne verra dans son voisinage réseau que les ordinateurs de son sous-réseau, et non les ordinateurs du sous-réseau A (bien évidemment, seuls des ordinateurs basés Microsoft son susceptibles d'être vus dans le voisinage réseau).
Conséquence : les clients TCP/IP Microsoft ont besoin d'une assistance pour connaître les noms NetBIOS.
Cette assistance a été fournie par Microsoft avec le service WINS.
Les serveurs WINS font un travail un peu analogue aux serveurs DNS, mais corrélant les adresses IP non pas avec un FQDN, mais avec un nom NetBIOS :
Serveur DNS : FQDN (hostname) <--> adresse IP Serveur WINS : nom NetBIOS <--> adresse IP
WINS permet donc d'utiliser des noms NetBIOS dans un environnement TCP/IP.
La différence de fonctionnement entre WINS et DNS est que ce dernier est "statique" (il faut introduire manuellement les hostnames avec leur correspondance IP), alors que WINS est "dynamique" : un ordinateur à qui on a précisé un serveur WINS va immédiatement s'y annoncer lorsqu'il sera allumé sur le réseau. La base de données WINS est ainsi créée et maintenue dynamiquement, même si on peut y ajouter des entrées statiques.
Ainsi, pour notre réseau coupé par le routeur, il suffira de mettre en place un serveur WINS sur un des sous-réseau (A ou B) et d'indiquer son adresse IP aux ordinateurs de A et B pour que, cette fois, la liste browse soit complète de chaque côté.
Usuellement, on installe même un serveur WINS sur chaque segment Ethernet, et on crée des règles de "synchronisation" entre les différents serveurs WINS.
Vous avez peut-être déjà entendu parler d'un b-node ou d'un h-node à propos d'un ordinateur. En fait, cette classification découle de la manière dont l'ordinateur s'annonce sur le réseau et y recherche d'autres ordinateurs.
Le h-node est le mode de noeud par défaut d'un client Microsoft utilisant WINS. Si un client WINS ne peut pas contacter son serveur WINS, il se retransforme en b-node.
Notez que vous pouvez savoir facilement quel est le mode de noeud en utilisant la commande IPCONFIG /ALL sous Windows NT, ou le programme WINIPCFG.EXE sous Windows 9x.
NB : Evitez de faire cohabiter des b-nodes et des p-nodes sur le même réseau : à cause des modes de résolution, deux ordinateurs avec le même nom NetBIOS pourraient exister simultanément sur le même réseau !
Le fichier hosts contient donc des corrélations adresse IP<-->FQDN (hostname) alors que le fichier lmhosts contient des corrélations adresse IP<-->nom NetBIOS.
Ordre de recherche :
(C) 02/02/2008 - Dernière modification : 02/02/2008 - F4CVM / Pascal