Bonjour,
 
J'ai un serveur DNS dans un modem/routeur Speedtouch. Il ne sert pas de routeur d'ailleurs, juste de serveur DNS pour mon réseau interne: mydom.fr. Les machines Windows s'enregistrent sans problème sur ce serveur DNS. Mais pas Linux???
 
Admettons que le hostname du Linux soit toto. Dans un shell sur le Linux, la commande hostname renvoie bien toto.mydom.fr, mais ping toto renvoie unknonw host??? Un nslookup confirme que le serveur DNS par défaut est bien celui du Speedtouch, et lorsqu'on tape toto ou toto.mydom.fr, nslookup renvoie server can't find toto: NXDOMAIN???
 
Pour précisions, contenu des fichiers système:
/etc/dhclient-eth0.conf

/etc/sysconfig/network-scripts/ifcfg-eth0

/etc/resolv.conf

Si l'on pouvait éclaire ma lanterne pour savoir où chercher, et quoi modifier!
Un grand merci par avance.
Tchô

En fait, lorsqu'on veut qu'une machine ait une adresse IP attribuée par DHCP, que faut-il mettre dans le fichier /etc/hosts?
 
Moi je pensais qu'il ne fallait rien mettre, hormis bien sur, la ligne 127.0.0.1 localhost, parce que je pensais que dhclient, lorsqu'il aurait reçu une adresse, irait de lui-même écrire dans le fichier /etc/hosts une ligne du style:
192.168.x.x  toto.mydom.fr  toto
 
Mais pô du tout!???...
 
J'ai lu que certains préconisent d'écrire une ligne du style:
127.0.0.1 toto.mydom.fr localhost toto
 
Mais dans ce cas, si je ping toto j'obtiens 127.0.0.1 et pas du tout l'adresse fourni par dhcp dans le lease, qui est bien au format 192.168.x.x.
 
Je comprends plus bien la mécanique du dhcp client là...

J'ai rien compris à tes explications, ton problème et ta topologie réseau. Finalement tu t'en sors mieux que moi...

comment sais tu que ces machines windows s'enregistrent sur ton DNS ?
 
à mon avis, c'est netbios qui fait la résolution avec un ping sur les windows, pas ton DNS

?????????
Si je pas bien expliquer, je pouvoir simplifier ou expliquer différement, mais falloir dire à moi que moi pas bien expliquer!!!
Mais si je pas bien décrire problème
et si je pas avoir de réponse autre que ta tienne,
je pas comprendre en quoi moi "mieux m'en sortir"........

Explique en anglais si t'es pas a l'aise en francais.

As you wish my Lord...
 
I got 5 machines in my home network. 4 are Windows 2K/XP, 1 is Linux.
The home network is behind a NetGear router wifi/cable modem.
All machines should communicate together through IP.
All machines are dhcp client of the NetGear router. This one does only dhcp server, NOT dns server, so this dhcp server is just able to give: ip addresses, gateway and ISP DNS servers.
 
Because, I don't want to see the ISP DNS servers in the dhcp leases, I use a private domain name, let say: mydom.fr.
To manage the private domain name, I need a private dns server, which is in a SpeedTouch Home Ethernet modem/router. This one just do dns server, nothing else.
 
Within this architecture, all machines are configured to supersede the domain name (mydom.fr) and the domain name server in their ip config.
All machines receive correctly a dhcp lease (i.e: ifconfig and ipconfig are correct) for ip adresse, gateway.
 
The windows machines registered themselves correctly to the SpeedTouch dns server (i.e: nslookup confirm the presence of an NX record of these machines inside the private dns server).
The windows machines are able to ping themselves.
The Linux machine is able to ping Windows machines.
 
But, the Linux machine (name: toto) doesn't registered to the private dns server...
hostname command give the correct host name answer: toto.mydom.fr.
But pinging toto or pinging toto.mydom.fr doesn't work (unknown host).
 
What should be write in /etc/hosts for dhclient to work correctly?
Because I thought it was part of the job of dhclient, once the ip address is given, to write something in /etc/hosts like:
192.168.x.x toto.mydom.fr toto
 
As mentionned in my first post, I thought these files should be modified in order to have a correct behavior of dhclient (or pump):
/etc/sysconfig/network
/etc/sysconfig/network-script/ifcfg-eth0
/etc/resolv.conf
/etc/dhclient-eth0
 
May be another conf file should be modified? Any idea?
The goal is that the Linux does its dhcp client correctly.
Thanx

Commande nslookup (sous Windows ou sous Linux).
D'une part le serveur par défaut est bien le serveur privé du Speedtouch, ce qui prouve que la configuration du stack ip est bonne pour dns.
D'autre part, dans nslookup, si je tape le nom des différentes machines (avec ou sans nom de domaine), il renvoie bien l'adresse IP. Et vice versa, si je donne l'adresse ip, il renvoie bien le nom.
 
Quand les machines ne sont pas enregistrés dans un dns, il retourne:
** server can't find nnnnnnnnn: NXDOMAIN
 

C'est plus clair en anglais
 
1/

 
Apparement ca diffère de ton:

 
2/ Les logs ne disent rien ?
 
3/ Sort un analyseur de trame (ethereal) et sniffe le réseau pendant l'update dns d'un windows, puis du Linux. Tu vas bien voir ce qui cloche et ca ira plus vite pour trouver la conf qui foire.
 
Regards,
AirbaT (ho yeah)

http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html

Bonjour à toutes et à tous,
 
Excusez-moi de ce long silence sur ce post, car de plus je ne vous avais pas remercié pour vos conseils ni pour les liens vers la littérature qui va bien.  
 
Info sur la résolution du problème:
Le DHCP server qui se trouve dans le routeur NetGear FWG114P est bien gentil, mais c'est lui qui fout la zone avec Linux...
 
Comme j'avais déjà le DNS server sur le SpeedTouch, j'ai passé également le DHCP server sur ce dernier, et depuis, ô miracle, plus d'emmerde!!! Tous les ordis Windows ou Linux choppent une IP par DHCP et sont correctement enregistrés dans le DNS. Merci Alcatel d'avoir mis un mini noyau unix dans ton SpeedTouch!!!
 
--------------------------
 
Sinon, j'ai un problème similaire, dans le sens où j'ai encore des Unix qui s'enregistrent pas ou mal dans un DNS.
 
Je débarque dans un réseau hétérogène où il y a une station en Windows 2000 server avec DHCP/DNS dynamique avec AD; des clients PC; des clients Mac OSX; un client Irix (SGI). Moi j'arrive avec mes gros sabots et je pose un serveur de fichiers sous Linux Suse 9.2 personnal pour faire des exports en NFS (pour les OSX) et Samba (pour les Win2K).
 
Au niveau du DNS: Les enregistrements des unix (OSX) dans le DNS Windows ne se font pas. J'ai bien vérifié et demandé au DNS Windows d'être le plus tolérant possible (pas de demande sécurisée, d'écouter toutes les adresses IP, d'écouter tous les noms), à DHCP Windows de mettre à jour automatiquement le DNS...
 
Le Suse étant un serveur, il n'est pas client DHCP, son adresse IP est fixe.
 
La station SGI Irix, en IP fixe aussi, n'arrivait pas à faire de résolution DNS du tout. Mais cela venait du fait que son nom d'hôte n'était pas FQDN. Une fois ceci corrigé, il pingue tout les autres par leurs noms.
 
Le truc qui me chiffone gravement c'est la chose suivante: Si j'ajoute manuellement les noms d'hôtes avec le reverse associé dans le DNS, le Suse et les OSX ne voient toujours pas les autres machines, par exemple avec un ping par le nom (FQDN ou pas). Mais par contre les commandes ssh, telnet, rlogin fonctionnent en utilisant le nom simplifié (pas FQDN). Donc, il y a quand même une résolution de nom quelque part...
 
J'ai bien vérifié que, dans les différents fichiers ou dans les différents panneaux de configuration des systèmes, le nom de la machine était bien en FQDN au cas où le DNS rejette une demande réalisée par un nom d'hôte non FQDN. Vérifié aussi que dans la configuration IP de ces machines, l'adresse IP du serveur DNS ainsi que le nom de domaine étaient bien renseignés. Les /etc/resolv.conf et /etc/nsswitch.conf sont corrects également.
 
Donc là, je sèche gravement... Ce n'est pas un problème de TCP/IP, puisque certaines commandes passant par IP arrivent à faire une résolution de noms. Mais du coup, sur le Suse je ne peux pas pinguer les autres machines par leurs noms, et surtout, plus problématique, mes exports NFS ne fonctionnent pas, puisqu'à chaque fois qu'un client vient sur le partage (OSX et Irix), le serveur Suse n'arrive pas à faire la résolution de nom inverse et lui refuse l'accès...
 
Sur le Suse, je n'ai pas bricolé les fichiers de conf à la main, j'ai laissé YasT faire la configuration IP. Le fichier /etc/HOSTNAME contient le FQDN et la commande hostname renvoie le nom simplifié. nslookup lui fonctionne bien et répond à toutes les requêtes.
 
Il n'y a pas de Firewall activé sur le Suse (shorewall off).
 
Pour le moment, pour avancer, j'ai collé des adresses IP fixes sur les OSX, ainsi que le /etc/hosts du Suse, mais ça pue et puis on n'est plus vraiment DHCP/DNS dynamique pour les clients du réseau.
 
Les clients windows n'ont pas de problème pour aller sur les partages Samba du Suse, puisqu'ils ont un serveur Windows qui répond aux requêtes de noms par Netbios et/ou DNS.
 
Je ne vois plus où aller chercher là...
 
Z'auriez une idée?
Merci.
Tchô

si un ping ne marche pas, cela peut vouloir dire qu'il y a un firewall en face.
 
Question : les commandes host, nslookup permettent d'avoir des infos de résolutions de noms correctes ?

 
Salut Dark!
 
Non il n'y a pas de firewall sur le Windows 2000 server, ni non plus sur les clients OSX.
 
Oui, la commande nslookup, renvoie bien les bonnes infos, dans les deux sens, qu'on lui donne un nom d'hôte simple, un nom d'hôte FQDN ou une adresse IP.
 
Le mystère le plus grand pour moi étant:

J'ai ce même comportement dans un shell que ce soit sur un client OSX vers le Suse, ou sur le Suse vers l'OSX. Pinguer le serveur par son nom ne fonctionne pas, mais un ssh avec le nom fonctionne??????
 
Et si je fais un ping www.yahoo.fr, cela fonctionne sur les deux OS.
 
Groumpf?!

Là si tu veux gagner du temps, je te conseille de mettre en place un sniffer qqpart, et vérifies les dialogues Suse <-> DNS  et OSX <-> DNS ... Ca te permettra de mettre en lumière rapidement ce qui ne va pas ... ou au moins de te donner une ou plusieurs pistes ... parce que là, y'a trop de paramètres qui interviennent en même temps et les expérimenter un à un sans savoir dans quelle direction chercher risque d'être fastidieux
 
Ouala,
AMHA

Ben en fait, j'ai déjà fait un 'tit bout de spy réseau (avec tcpdump sur le Suse) ou en me servant de son équivalent sur Irix (snoop).
 
Mais je ne suis pas assez calé en analyse de trames pour percuter ce qui ne va pas. Donc, avant de vous soumettre un gros post plein de trames!!! Je préfèrais vous soumettre le problème vu côté user, au cas où cela évoque quelque chose de plus immédiat.
 
Alors, je vois bien passer des trames au protocole "domain" ou "mdns", et, effectivement, il y a une légère différence entre ce que provoque un "ping nom" et "ssh nom".

Donc, ce qui m'embête, c'est le fait que pour la commande ping vers la machine OSX (irishcoffee), le Suse (barman) fait une demande "mdns" en "unicast" (224.0.0.251?). Idem depuis un OSX vers un Win2K. Pourquoi ping ne provoque pas une demande sur le protocole "domain"? Alors que toutes ces stations ont dans leur configuration IP, l'adresse IP du serveur DNS ainsi que le nom de domaine interne.
 
Alors que pour la commande ssh, il fait correctement une demande en "domain" au serveur DNS déclaré (leshalles). De plus, le nom demandé est bien complété en FQDN et le serveur répond 1/0/0, ce qui, au vu des autres trames, signifierait qu'il a le nom/adresse en stock et retourne la bonne réponse. Quand il ne l'a pas, je vois passer des NXDomain.
 
Confirmation également que le reverse DNS fonctionne, puisqu'une commande traceroute de l'adresse IP de irishcoffee, retourne bien:

 
Voilà, si vous ça vous en dit plus! Moi je suis un peu largué dans l'analyse de paquets!!!
 
A+

 
Je crois que je commence à comprendre ...
 
Il a quelle tête ton nsswitch.conf sur la Suse pour info ?
 
sinon, ce que tu peux déjà faire, c'est désactiver ce service mDNSResponder (sur la Suse et ur OS X) et rééssayer de pinger pour voir  
 
EDIT : chuis pret à parier que tu as un mdns qui traine dans ton nsswitch.conf, à la ligne commençant pas "hosts :", sur ta Suse  
Pour OS X, tu dois trouver l'équivalent du système (name service switch dispatcher ... enfin en partie) dont fait partie le fichier "nsswitch.conf" sur la Suse

Tant mieux!!! Ca va m'aider!!!    
 
Alors, voilà la ligne hosts du nsswitch.conf Suse

J'ai ajouté Winbind pour ce que j'ai à faire avec le Windows 2000 server.
Je ne sais pas ce qu'est lwres, donc je l'ai laissé.
Mais point de trace du mdns...
 
Un locate ne donne rien; dans xinetd.conf et /etc/xinetd.d rien; un grep dans les services de démarrage /etc/init.d rien; dans le script network rien; chkconfig rien...
 
En fait, je n'avais pas compris que c'était un protocole à part entière... Du coup j'ai googlisé avec "Suse+mdns+domain" et je suis tombé sur l'article qui va bien:
 
http://support.novell.com/products/tips/10034.html
 
Et hop, une fois la ligne "mdns off" ajouté dans le /etc/host.conf, nickel!!!    Même pas besoin de redémarrer le network!!! Ouf!
 
Faut que je m'attaque aux OSX, mais avec cette info, il y a fort à parier que c'est le même principe, peut-être pas rangé au même endroit!
 
Merci de vos réponses et d'avoir aiguillé les recherches!!!
 
A+

Regardes par là pour OS X, ptet que ça peut t'aider
==> http://www.multicastdns.org/DLLC/

Ca a l'air d'être tout à fait ça!!! J'en étais arrivé au point où, sur Osx point de nsswitch.conf... Faut dire que tout est planqué pour rester "user friendly", même pour root, et ils commencent à jouer à la base de registre avec leur base Netinfo
 
Finalement un grep dans les fichiers de conf me donne le /etc/resolver comme étant la source probable du problème! Et effectivement, ton lien amène vers une solution qui overload ce resolver!!! Koooooool!
 
M'enfin, en conclusion, ça me montre bien que l'ingé système qui a construit le réseau avant moi, il n'aurait pas dû mettre un nom de domaine interne en .local Quel boxon!!! Entre Windows qui créé ses noms de domaine en .local, OSX qui ajoute .local à ses noms de machines pour RendezVous, le gars a trouvé "malin" de garder un nom de domaine interne en mydom.local...
 
C'est sûr que ça peut pas aider la séparation des problèmes!!!  
 
Le grand merci à tous pour les tuyaux et les liens.  
Tchô. Mikee.

 
  C'est pas de l'unicast mais du multicast .. tu as à affaire à une addresse de classe D typique des processus de multicast (==> IGMP )  
 
  C'est le propre de ce nouveau "protocole qu'est mDNS"  (le m signifiant multicast justement )