> Tech > Localisation et réparation des pannes

Localisation et réparation des pannes

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Si l'installation d'un domaine se passe mal, que faire ? Il faut se reporter au manuel d'aide concernant le DNS sur OS/400 pour diagnostiquer les problèmes et les résoudre. Une des aides est l'outil de requête NSLOOKUP qui permet d'interroger la base de données DNS ainsi que les joblog et

qui contient quelques
options pour réparer ou modifier le DNS.



NSLOOKUP est le principal outil de diagnostic de DNS. Il n’est pas unique aux
iSeries (il a été créé sur Unix mais peut tourner sous Windows et en principe
sur n’importe quelle plate-forme). Malheureusement NSLOOKUP n’apparaît que sur
la version V4R4 de l’OS/400. Si l’ordinateur est plus ancien, il faut lancer le
programme depuis un ordinateur qui est connecté au même Lan que le iSeries. Cependant,
ceci n’est pas un vrai problème car NSLOOKUP est un standard et les commandes
sont identiques quelle que soit la plate-forme et il revient au même de les utiliser
à  distance ou localement. Il suffit d’exécuter le programme NSLOOKUP sur n’importe
quelle ligne de commande. Le programme lancé par la commande est qtoblkup de la
bibliothèque QDNS. Après avoir lancé la commande, l’utilisateur est accueilli
par le message suivant :



Nslookup

Default Server : as1.mycompagny

Address : 10.5.69.222

>



Le message du serveur par défaut indique le nom et l’adresse IP du serveur que
NSLOOKUP va interroger. Si NSLOOKUP tourne à  distance, il peut être nécessaire
de le rediriger vers le bon serveur. Pour cela on utilise la commande suivante
:



Nslookup

Default Server : as1.mycompagny.com

Address : 10.5.69.222

>server 10.5.69.221

Default Server : as5.mycompagny.com

Address : 10.5.69.221



On est prêt maintenant à  lancer les requêtes. Par défaut NSLOOKUP cherche dans
les enregistrements de type A. Il suffit de taper le nom que l’on veut vérifier
et on reçoit la réponse suivante :



>ntserver1.mycompagny.com.

Name : ntserver1.mycompagny.com

Address : 10.5.69.205



Notez l’enchaînement des points sur le nom au niveau de la première ligne. Ces
points dans les noms permettent d’éviter que NSLOOKUP ne complète de lui-même
en ajoutant le nom du domaine local. NSLOOKUP sait reconnaître une adresse IP
et vérifie automatiquement les enregistrements PTR correspondants :



>10.5.69.211

Name : as2.mycompagny.com

Address : 10.5.69.205



Cependant, pour tout autre type d’enregistrement, il faut changer le mode manuellement
dans NSLOOKUP. Par exemple pour consulter les enregistrements MX :



> set type=MX

> mycompagny.com

Server : as1.mycompagny.com

Address : 10.5.69.222

mycompagny.com preference = 10

mail exchanger = as2.mycompagny.com

mycompagny.com preference = 20

mail exchanger = as5.mycompagny.com

mycompagny.com nameserver = ns1.jet.net

mycompagny.com nameserver = ns1.sysci.org

as2.compagny.com Internet address = 10.5.69.211

as5.compagny.com Internet address = 10.5.69.221

ns1.jet.net Internet address = 206.83.0.42

ns1.sysci.org Internet address = 205.227.180.10



Comme on peut le constater, NSLOOKUP donne de nombreuses informations. Bien que
la liste d’enregistrements MX suffise à  répondre à  la question, NSLOOKUP va plus
loin en donnant une liste de serveurs de noms maîtres pour le domaine et les adresses
IP des serveurs nom et des serveurs mail. NSLOOKUP possède plusieurs autres commandes
et caractéristiques que l’on ne va pas voir en détail ici. Pour obtenir de l’aide
sur cette commande, on peut consulter la documentation en ligne ou taper la commande
help.



NSLOOKUP est un standard et les commandes sont identiques quelle que soit la plate-forme



A chaque fois que l’on ajoute ou modifie des enregistrements il faut vérifier
les modifications en utilisant NSLOOKUP. Si les modifications ne correspondent
pas à  ce que l’on attendait, il faut revoir la syntaxe des enregistrements. Si
le problème ne vient pas d’une erreur de syntaxe, on peut regarder attentivement
la joblog du serveur afin de voir s’il n’émet pas un message d’erreur (figure
6). Les messages indiquent généralement un problème de configuration plutôt qu’une
erreur de syntaxe parce que OpsNav vérifie la syntaxe de tous les enregistrements
DNS modifié. Si la consultation de la joblog ne donne rien, il faut surveiller
de près les requêtes DNS en temps réel pour voir comment le serveur les gère.
Pour cela il faut le demander au niveau de la fenêtre des propriétés du DNS. Cliquer
avec le bouton droit sur DNS dans OpsNav et sélectionner Propriétés (figure 7).
Le résultat est un fichier nommé QUERYLOG dans /QIBM/userData/OS/400/DNS. Avec
OpsNav on a aussi la possibilité de dépanner. Par exemple on peut envoyer la base
de données DNS active dans un fichier texte ou choisir d’avoir plus de détails
sur les messages de la joblog. Cependant ces outils sont généralement inutiles
au dépannage de routine. Ils sont parfaitement expliqués dans le redbook sur le
DNS d’IBM.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT