DNS là  où on l’attend le moins

pour résoudre les noms Windows.

Mais les clients WINS noeud-H tentent d’utiliser un serveur DNS comme s’il s’agissait
d’un serveur WINS : le client utilise une requête de nom NetBIOS de type WINS
plutôt qu’une requête de nom de client DNS, pour envoyer une requête de résolution
de nom au serveur DNS. Par conséquent, sauf si le serveur DNS se trouve être le
serveur WINS et possède un enregistrement dans sa base de données pour le nom
demandé, la tentative noeud-H a toutes les chances d’échouer.

Le processus de résolution noeud-H NetBT n’est pas la seule occasion pour les clients
d’interroger des serveurs DNS pendant une tentative de résolution de noms. Si
DNS est activé sur un client et si le client est configuré pour utiliser un ou
plusieurs serveurs DNS, ce dernier utilisera les requêtes client DNS (également
baptisé Domain Name Resolver, DNR) par le port UDP 53 standard pour envoyer des
requêtes de noms aux serveurs DNS.
Le client enverra ces requêtes centrées sur DNS après avoir vérifié un fichier
HOSTS local et avant toute tentative de résolution des noms NetBT. Pour créer
un FQDN (Fully Qualified Domain Name), par exemple serveur.entreprise.com, pour
la requête, le client annexera tous les noms par défaut configurés dans la section
DNS de sa boîte de dialogue de configuration TCP/IP au nom demandé. (J’ai utilisé
un outil de surveillance de réseau pour observer ce comportement. Pour savoir
comment afficher la résolution des noms de clients et autre trafic du réseau,
voir l’encadré  » Sous le capot avec le Moniteur réseau « ). Voici l’ordre complet
et exact dans lequel le client LAN Windows tente de résoudre les noms :

1. Il vérifie si le nom demandé appartient à  la machine locale.

2. Il utilise un fichier HOSTS local s’il en existe un.

3. Il interroge tous les serveurs DNS configurés au moyen de requêtes DNR par
le port UDP 53.

4. Il utilise la méthode de résolution du type de noeud NetBT appropriée, en fonction
du type de noeud NetBT du client (comme décrit ci-dessus).

Cette liste donne une image tout à  fait différente de la liste précédente. La
plupart des administrateurs avec lesquels je discute sont surpris d’apprendre
que les clients LAN Windows interrogent en toute logique les serveurs DNS avant
les serveurs WINS. (Ce malentendu est courant, car la plupart des documentations
de Microsoft et des support de formation qui parlent de l’ordre de résolution
NetBT négligent de mentionner ces requêtes DNS préliminaires). Vos clients LAN
supportant WINS effectuent sans doute régulièrement un nombre exorbitant de requêtes
de résolution de noms DNS qui échouent. Un serveur DNS qui n’a pas d’informations
répond simplement qu’il ne peut pas résoudre le nom demandé ; cette reconnaissance
ne prend guère de temps, aussi les utilisateurs remarquent rarement cette temporisation.

Mais si le client ne peut pas atteindre le/les serveur(s) DNS pour une raison
quelconque (par exemple si les adresses des serveurs ont été mal configurées,
si les serveurs ne peuvent pas être atteints à  partir de l’adresse IP du client,
ou si les serveurs sont arrêtés), il doit attendre que les requêtes successives
adressées aux serveurs DNS arrivent à  expiration, pour pouvoir tenter une méthode
NetBT. Selon le système d’exploitation du client et le niveau de révision du service
pack, cette attente peut aller de 5 secondes à  2 minutes.