Jump to content
Justneuf

Sheldon Cooper

Membres
  • Content Count

    3
  • Joined

  • Last visited

Community Reputation

1 Neutre

About Sheldon Cooper

  • Rank
    Mousse

Informations diverses

  • Dégroupage
    Dégroupage total
  • SFR TV
    Oui
  • Modem
    Neuf Box 4 FXC
  1. Re-bonjour, Petite amélioration qui apporte plus d'élégance par rapport à ma réponse précédente, on peut éviter d'avoir des doublons dans la déclaration DNS grâce au paramètre search de resolv.conf qui reproduit le mécanisme d'ajout de suffixe sous Linux: [root@search01n ~]# cat /etc/resolv.conf search local nameserver 192.168.1.1 Ainsi, les domaines search01n et search02n seront également résolus par les FQDN search01n.local, search02n.local qui restent les seuls déclarés dans le serveur DNS de la box. Ne pas oublier d'ajouter à le FQDN à /etc/hosts pour sa résolution locale dans vos applicatifs. Une bonne expérience finalement !
  2. Bonjour, Merci pour votre réponse omegatron, je comprends maintenant le mécanisme de résolution des noms de domaines non FQDN par Windows. Je trouve qu'installer du samba sur chaque VM (ou sur une VM tierce pour en faire un serveur WINS) n'est pas le plus élégant. Je préfère garder la centralisation des noms de domaines au niveau de la box. J'ai donc, comme préconisé, utilisé des noms FQDN (en plus des non FQDN) dans mes enregistrements DNS puis l'option d'ajout automatique de suffixe pour les noms non FQDN dans le gestionnaire de connexion Windows. Et maintenant : $ ping.exe search01n Envoi d'une requête 'ping' sur search01n.local [192.168.1.11] avec 32 octets de données : Réponse de 192.168.1.11 : octets=32 temps<1ms TTL=64 Réponse de 192.168.1.11 : octets=32 temps<1ms TTL=64 Réponse de 192.168.1.11 : octets=32 temps<1ms TTL=64 Réponse de 192.168.1.11 : octets=32 temps<1ms TTL=64 Statistiques Ping pour 192.168.1.11: Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%), Durée approximative des boucles en millisecondes : Minimum = 0ms, Maximum = 0ms, Moyenne = 0ms Merci encore pour ces éclaircissements et à bientôt !
  3. Bonjour à tous, Je suis actuellement en train de mettre en place des machines virtuelles CentOS sur mon poste tournant sur Seven. J'en ai pour l'instant deux et les ai nommé search01n et search02n. Afin de pouvoir utiliser les noms des machines plutôt que leurs IPs sur l'ensemble du réseau local, j'ai déclaré chaque machine virtuelle dans la section DNS de la neufbox. Sur ces machines virtuelles CentOS, tout marche bien, la résolution se fait bien par la box. [root@search01n ~]# host -a -c IN search02n Trying "search02n" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51110 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;search02n. IN ANY ;; ANSWER SECTION: search02n. 0 IN A 192.168.1.12 Received 43 bytes from 192.168.1.1#53 in 2 ms [root@search02n ~]# host -a -c IN search01n Trying "search01n" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42673 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;search01n. IN ANY ;; ANSWER SECTION: search01n. 0 IN A 192.168.1.11 Received 43 bytes from 192.168.1.1#53 in 2 ms En revanche, depuis le poste sous Windows Seven les noms ne sont pas résolus : $ ping.exe search01n La requête Ping n'a pas pu trouver l'hôte search01n. Vérifiez le nom et essayez à nouveau. $ ping.exe 192.168.1.11 Envoi d'une requête 'Ping' 192.168.1.11 avec 32 octets de données : Réponse de 192.168.1.11 : octets=32 temps<1ms TTL=64 Réponse de 192.168.1.11 : octets=32 temps<1ms TTL=64 Réponse de 192.168.1.11 : octets=32 temps<1ms TTL=64 Réponse de 192.168.1.11 : octets=32 temps<1ms TTL=64 Statistiques Ping pour 192.168.1.11: Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%), Durée approximative des boucles en millisecondes : Minimum = 0ms, Maximum = 0ms, Moyenne = 0ms Malgré cette configuration et un flush du cache dns via ipconfig.exe /flushdns : $ ipconfig.exe /all Carte Ethernet Connexion au réseau local : Suffixe DNS propre à la connexion. . . : Adresse physique . . . . . . . . . . . : 00-21-85-9F-E0-F0 DHCP activé. . . . . . . . . . . . . . : Oui Configuration automatique activée. . . : Oui Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.5(préféré) Masque de sous-réseau. . . . . . . . . : 255.255.255.0 Bail obtenu. . . . . . . . . . . . . . : samedi 6 avril 2013 20:10:20 Bail expirant. . . . . . . . . . . . . : dimanche 7 avril 2013 20:15:03 Passerelle par défaut. . . . . . . . . : 192.168.1.1 Serveur DHCP . . . . . . . . . . . . . : 192.168.1.1 Serveurs DNS. . . . . . . . . . . . . : 192.168.1.1 NetBIOS sur Tcpip. . . . . . . . . . . : Activé Avez-vous déjà rencontré un tel problème? Y-a-t'il une conf Windows que j'ai raté (je ne suis pas au taquet sur cet OS) pour la déclaration du serveur DNS qui a pourtant l'air d'être correcte d'après le retour ipconfig ? C'est d'autant plus singulier qu'ayant installé un Cygwin sur mon poste sous Seven, les commandes suivantes donnent : $ host -a -c IN search01n Trying "search01n" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16294 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;search01n. IN ANY ;; ANSWER SECTION: search01n. 0 IN A 192.168.1.11 Received 43 bytes from 192.168.1.1#53 in 1 ms $ host -a -c IN search02n Trying "search02n" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25152 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;search02n. IN ANY ;; ANSWER SECTION: search02n. 0 IN A 192.168.1.12 Received 43 bytes from 192.168.1.1#53 in 1 ms A n'y rien comprendre ! Merci de votre patience, les idées sont bienvenues !
×
×
  • Create New...