Nouvel ordre

des noms par défaut du client. (Pour en savoir plus sur le comportement de résolution
des noms du client, voir la première partie de cet article).

Lorsque j’ai commencé à  creuser cette idée, j’ai été encouragé en trouvant plusieurs
articles de Microsoft expliquant comment changer l’ordre de résolution des noms
sur les clients exécutant plusieurs plates-formes Windows. L’article  » How to
Change Name Resolution Order on Windows 95 and Windows NT  » (http://support.microsoft.com/support/kb/articles/q139/2/70.asp)
décrit deux méthodes – l’une pour NT et l’autre pour Windows 95 – permettant de
contrôler manuellement l’ordre dans lequel Windows tente les résolutions des noms.
(Pour une liste des articles de Microsoft portant sur la résolution des noms,
voir l’encadré  » Les ressources de la -résolution des noms « ).
J’ai d’abord essayé la méthode Win95. Dans Windows 95, l’ordre de résolution des
noms se contrôle grâce à  un groupe de quatre sous-clés du Registre : LocalPriority,
HostsPriority, DnsPriority et NetbtPriority. (Ces sous-clés sont du type REG_DWORD
et résident dans la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VXD\MSTCP\ServiceProvider).
Elles contrôlent respectivement la priorité relative d’utilisation de la mémoire
ache locale des noms, du fichier HOSTS, de DNS et des méthodes de résolution des
noms NetBT (y compris WINS). Les valeurs peuvent aller de -32768 à  32767 (les
nombres inférieurs spécifient une priorité plus élevée) avec les valeurs par défaut
suivantes (en décimales) :

· LocalPriority = 499

· HostsPriority = 500

· DnsPriority = 2000

· NetBTPriority = 2001.

Ces valeurs expliquent la préférence du client pour DNS (DnsPriority = 2000) par
rapport à  WINS (NetbtPriority = 2001). Comme on peut s’y attendre, l’article suggère
de simplement réordonner les valeurs pour donner à  DNS une valeur plus élevée
(et donc une priorité inférieure) que NetBT et WINS. Cette suggestion m’a paru
très simple et j’ai donc mis en oeuvre les changements sur mon système de tests
Win95 OSR2 (OEM Service Release 2), puis j’ai réinitialisé. Mais je n’ai, étonnamment,
détecté aucune différence dans l’ordre de résolution des noms du client : mon
Observateur réseau a constaté que le client continuait à  interroger DNS en premier.

En parcourant de nouveau le site Web de Microsoft j’ai déniché un autre article
intitulé :  » Windows 95 Service Provider Priority Values Not Applied  » (http://support.microsoft.com/support/kb/articles/q170/6/19.asp),
qui disait en substance  » Désolé, nous nous sommes trompés dans le premier article
« . Apparemment, les changements suggérés dans le premier article ne fonctionnent
pas car les premières versions de Winsock (c’est-à -dire celles antérieures à  wsock32.dll4.00.1112)
contiennent un bug qui fait lire au système les données du Registre à  partir de
la clé de Registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSTCP\ServiceProvider.
Pour corriger ce problème, l’article suggère de mettre manuellement en miroir
les valeurs de l’emplacement original correct dans l’emplacement interrogé à  tort.
Mais quelle ne fût pas ma surprise de constater que malgré ces changements, mon
client Win95 OSR2 continuait à  interroger d’abord DNS. Même après avoir mis à 
niveau le client vers Win98, je n’ai pas pu constater de différence dans l’ordre
de résolution des noms.

à€ peine remis de ma défaite avec Win95, je décidai de m’attaquer à  la solution
recommandée pour les clients NT : expérience plus agréableJuste après avoir pratiquement
abandonné ces valeurs du Registre, j’ai installé Win98SE° (Win98 Second Edition)
et soudain, mon client s’est mis à  interroger WINS avant DNS. Intrigué par ces
incohérences, je suis retourné sur le site Web de Microsoft et j’ai trouvé quelques
articles expliquant que les valeurs du Registre ne fonctionnaient qu’avec Winsock
1.x et d’autres suggérant le contraire.
J’ai eu beau essayer tout ce que j’ai pu imaginer, je ne suis jamais parvenu à 
inverser l’ordre sur Win95 OSR2 avec Winsock 2.x. Qui sait ? J’aurais peut-être
mieux réussi avec la version du commerce de Win95 et je ne sais pas si ces problèmes
résultaient de bogues dans le code, d’une documentation Microsoft erronée ou des
deux. En tous cas, l’expérience m’a laissé un goût amer dans la bouche sur la
fiabilité de certains articles de Microsoft.

à€ peine remis de ma défaite avec Win95, je décidai de m’attaquer à  la solution
recommandée pour les clients NT. L’expérience fût nettement plus agréable qu’avec
Win95. La modification NT prend la forme d’une sous-clé du Registre, DnsNbtLookupOrder
(attention à  la casse) du type REG_DWORD. Cette sous-clé n’existe pas par défaut,
il faut la créer dans la clé du Registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.
Elle peut avoir une valeur de 0 ou de 1. La valeur par défaut (c’est-à -dire 0)
indique au client d’utiliser DNS avant les méthodes NetBT ; la valeur 1 indique
au client d’utiliser d’abord les méthodes NetBT. Comme le montre la Figure 2,
j’ai ajouté la sous-clé et fixé sa valeur à  1, et le système client s’est mis
à  interroger WINS avant DNS.

Quel est l’inconvénient de cette méthode pour changer l’ordre de résolution des
noms d’un client ?
Elle risque d’introduire un délai d’attente mineur (c’est-à -dire plusieurs secondes)
lorsque les clients interrogent des noms qui ne se trouvent pas sur le LAN local
ou ne peuvent pas être résolus par WINS.
Par exemple, j’ai remarqué qu’il a fallu quelques secondes de plus qu’avant pour
naviguer vers un site Web de l’Internet sur mon client modifié (malgré des délais
d’attente pour WINS plus courts que ceux précédemment constatés pour DNS).
Est-ce là  un compromis acceptable ?
Tout dépend probablement du temps que l’utilisateur passera à  naviguer sur le
Web et à  s’engager dans d’autres activités liées à  Internet par rapport au temps
passé connecté au réseau de l’entreprise à  résoudre les noms de serveurs internes.
Puisque la plupart des utilisateurs passent beaucoup de temps à  accéder à  Internet,
la meilleure solution dans la plupart des cas sera probablement de mettre à  niveau
à  NT Service Pack 4 (SP4), ou version ultérieure, (ou à  Win98SE sur les systèmes
Win9x). Autre possibilité, la mise à  niveau à  Windows 2000 Professionnel, qui
a aussi des délais d’attente de serveurs DNS rapides.

Par ailleurs, les requêtes de noms ne sont pas toutes créées pareil. Un client
Windows ou une application peuvent générer deux sortes de requêtes de noms : les
requêtes de noms NetBIOS et les requêtes de noms d’hôtes. Les applications qui
envoient des requêtes de noms NetBIOS contournent DNS et utilisent les méthodes
NetBT (qui commencent généralement par WINS).
Les autres applications et utilitaires font des requêtes de noms génériques, traitées
par le client comme des requêtes de noms d’hôtes et passant d’abord à  DNS. (Vous
vous étonnerez sans doute d’apprendre que même Microsoft Outlook utilise des requêtes
de noms d’hôtes génériques pour résoudre le nom de ses serveurs Exchange. Comme
le champ du serveur d’Outlook peut accepter des FQDN – Fully Qualified Domain
Names – l’application ne se limite pas à  la seule utilisation des noms NetBIOS).
Ces applications souffriront en cas de problèmes liés aux délais d’attente de
DNS sur un PC client.

La plupart des commandes et des utilitaires centrés sur NetBIOS, comme l’utilitaire
Ping, émettent aussi des requêtes de noms d’hôtes. Mais certaines applications
et utilitaires contournent DNS et transmettent directement les requêtes à  NetBT.
Par exemple, si on tape la phrase UNC (Uniform Naming Convention) dans la boîte
de dialogue Démarrer, Exécuter, pour afficher une liste de ressources partagées
sur un serveur nommé SERVER1, un client h-noeud traite la requête comme une requête
de nom NetBIOS, comme sur la Figure 3.
D’autres consultations de noms du type UNC, comme ceux utilisés dans le mapping
des unités pour les scripts d’ouverture de session, ont le même comportement.
Mais sur mon réseau, j’ai remarqué davantage de requêtes de noms d’hôtes générées
que de noms NetBIOS.