Vous n'êtes pas identifié(e).
Pages : 1
Hors ligne
Donc le comportement observé est normal, il est nécessaire de préciser le serveur DNS à interroger dans le cas ou il est différent de ceux renseignés dans le resolv.conf.
Par contre, si je dig nommachine (où nommachineest la même qu'avant), je ne résous pas par mon DNS par mon serveur dns mais par un serveur root.
Tu peux donner un exemple ? Je pense que tu interprètes mal la sortie de dig. A moins de passer une option spéciale comme +trace, dig n'interrogera jamais un autre serveur DNS que celui spécifié ou ceux figurant dans /etc/resolv.conf.
Par contre, la même comande mais avec le nom de domaine (soit nomachine.mondomaine) fonctionne.
Le comportement par défaut de nslookup et dig est différent.
Si le nom n'est pas pleinement qualifié (avec un . final), nslookup utilise les domaines de la liste de recherche définis par l'option "domain" ou "search" dans /etc/resolv.conf.
host [server]
Look up information for host using the current default server or
using server, if specified. If host is an Internet address and the
query type is A or PTR, the name of the host is returned. If host
is a name and does not have a trailing period, the search list is
used to qualify the name.
En revanche dig n'utilise pas la liste de recherche sauf si on ajoute l'option +search à la commande.
+[no]search
Use [do not use] the search list defined by the searchlist or
domain directive in resolv.conf (if any). The search list is not
used by default.
Et bien entendu, c'est dig qui a raison. La notion de domaine de recherche est propre à la résolution de nom et non à la résolution DNS. Quand on teste un serveur DNS, on ne doit pas utiliser de noms courts ni de liste de domaines de recherche mais des noms de domaine complets.
Si tu ajoutes un . final au nom d'hôte avec nslookup, tu obtiendras le même comportement que dig.
Si tu ajoutes l'option +search avec dig, tu obtiendras le même comportement que nslookup.
Il vaut mieux montrer que raconter.
Hors ligne
Pages : 1