Conseil 3 : La curieuse façon pour Windows de traiter les serveurs DNS

configuré, et ainsi
de suite. Ainsi, si le premier serveur DNS tombait en panne,
Windows basculerait automatiquement sur le suivant en
ligne. C’est ainsi que les autres systèmes d’exploitation procèdent.
Or, Windows suit le chemin (ou la route)
le moins fréquenté. Il interroge tous les
noms de serveurs disponibles simultanément
puis prend la première réponse obtenue.
Cette curieuse technique de Windows
ne pose généralement pas de problème, hormis
une consommation inconsidérée des
services disponibles.
A moins que vos serveurs DNS listés ne
donnent pas tous la même réponse, ce qui se
produit plus souvent qu’on ne pense. Supposons
un serveur DNS interne, 10.11.12.13,
que tous vos utilisateurs ont configuré pour interroger les
entrées DNS. C’est votre propre serveur, à  l’intérieur de
votre zone protégée par pare-feu, qui procure l’avantage de
mettre en cache les consultations sur des noms de domaines
fréquemment interrogés. Sourcilleux quant à  l’éthique
Internet, vous configurez vos utilisateurs avec un serveur
DNS de secours 13.12.11.10. Il se trouve que c’est le serveur
DNS primaire de votre ISP. Mais cela ne vous préoccupe pas,
parce que vos utilisateurs n’interrogeront ce serveur que
quand le vôtre sera indisponible.
Sauf que Windows ne fait pas cela. Selon la documentation
de Microsoft, Windows interroge les serveurs DNS dans
l’ordre de la liste. Mais la documentation omet de mentionner
que Windows le fait sans aucun délai entre les requêtes.
Windows accepte ensuite le premier serveur DNS qui répond
et met cette réponse en cache. Essentiellement, Windows organise
une course entre les serveurs DNS. A l’occasion, bien
qu’il soit interrogé en second, le serveur DNS de votre ISP gagnera
la course. Peut-être que votre serveur DNS est encombré
par d’autres tâches, ou que le paquet UDP (User
Datagram Protocol) de réponse ne parvient jamais à  revenir
au demandeur (il n’est pas garanti qu’UDP survivra au trajet
de retour).
Et alors ? Votre ISP et votre serveur ne devraient-ils pas
donner les mêmes réponses pour vos requêtes DNS ? Oui, le
plus souvent. Mais la plupart des entreprises ont des enregistrements
de ressources dans leurs serveurs DNS locaux,
qui ne se trouvent pas dans le serveur de leur ISP — des enregistrements
listant des serveurs destinés au seul usage interne,
par exemple, ou qui fournissent des adresses IP privées,
plutôt que publiques, à  certains serveurs proposés au
public. Dans de telles situations, l’utilisateur obtient une réponse
« not found » ou une valeur fantaisiste. Cet utilisateur
se plaint alors « qu’il ne peut pas envoyer du courrier » ou
autre doléance. Mais, quand vous examinez son ordinateur
et essayez de reproduire le problème, il s’est corrigé tout
seul par magie.
Un comportement aussi erratique a de quoi dérouter les
spécialistes réseau les plus chevronnés. La seule prévention
consiste à  connaître ce comportement à  l’avance et à  en tenir
compte lors du dépannage. Au minimum, vous devriez
avoir deux serveurs DNS internes et ne pas compter du tout
directement sur le DNS de votre ISP.
Un rapide correctif aux problèmes intermittents causés
par les habitudes DNS particulières de Windows consiste
simplement à  enlever les adresses IP serveur DNS de votre
ISP, de la liste de recherche du serveur DNS des utilisateurs.
Si vous utilisez DHCP (Dynamic Host Configuration
Protocol) pour distribuer les adresses IP, ce correctif se fait en
une étape. DHCP distribue aussi généralement les paramètres DNS de l’utilisateur final. Si
vous configurez manuellement les paramètres
IP, vous devez supprimer les
valeurs DNS de l’ISP des paramètres
TCP/IP de chaque utilisateur — une
opération fastidieuse s’il y a beaucoup
d’utilisateurs. (Ce peut être le moment
opportun pour déployer un serveur
DHCP.) Utilisez le correctif rapide si
vous le devez, mais ne négligez pas la
solution à  long terme d’un second serveur
DNS interne.