Forum général.général Dns et suffix

Posté par Philippe M (site web personnel) le 19 février 2013 à 10:25. Licence CC By‑SA.

Étiquettes : aucune

fév.

2013

Bonjour,

J'ai un serveur dns avec bind au boulot, pour les clients linux je n'ai pas de problème mais pour les clients windows (xp, seven) il arrive de façon assez aléatoire qu'ils n'arrivent pas à résoudre les noms sans ajouter le suffix.

Cette fois j'ai un cas bien concret, sur un serveur windows 2008 qui est serveur d'impression il n'arrive pas à résoudre le nom impachat02. En console si je fais un :

nslookup impachat02

J'ai :

C:\Users\Administrateur>nslookup impachat02
Serveur :   ns1.dom.mondom
Address:  192.168.x.1

*** ns1.dom.mondom ne parvient pas à trouver impachat02 : Non-existent domain

Je fais la même chose avec le suffix

C:\Users\Administrateur>nslookup impachat02.dom.mondom
Serveur :   ns1.dom.mondom
Address:  192.168.x.1

Nom :    impachat02.dom.mondom
Address:  192.168.x.2

Voila à quoi ressemble mon fichier de config de ma zone dns

$TTL 86400      ; 1 day
@       IN      SOA     ns1.dom.mondom. superadmin.mondom.fr. (
                                   2011120855 ; serial
                                   86400      ; refresh (1 day)
                                   7200       ; retry (2 hours)
                                   3600000    ; expire (5 weeks 6 days 16 hours)
                                   172800     ; minimum (2 days)
                                   )
                          NS      ns0.dom.mondom.
                          NS      ns1.dom.mondom.
                          NS      svfir.dom.mondom.
                          MX      10 mail.dom.mondom.
                          MX      20 ns1.dom.mondom.
localhost                A       127.0.0.1

[...]
impachat02               A       192.168.x.2

Et pour le reverse

$TTL 86400      ; 1 day
@       IN      SOA     ns1.dom.mondom. superadmin.mondom.fr. (
                                   2012050911 ; serial
                                   86400      ; refresh (1 day)
                                   7200       ; retry (2 hours)
                                   3600000    ; expire (5 weeks 6 days 16 hours)
                                   172800     ; minimum (2 days)
                                   )
                           NS      ns0.dom.mondom.
                           NS      ns1.dom.mondom.
                           NS      svfir.dom.mondom.
$ORIGIN x.168.192.in-addr.arpa. 
[...]
2                      PTR     impachat02.dom.mondom.

Bien sur le problème n'est pas que sur cette adresse mais bien toute les adresses du réseau. ns0.dom.mondom est la pour historique.
J'ai essayé je ne sais pas combien de configuration sans jamais trouver la solution et c'est un peu galère parque ça me pose des problèmes au niveau du lien odbc Oracle.

Est-ce que vous avez une idée ?

# problème côté client ?

Posté par nono14 (site web personnel) le 19 février 2013 à 10:56. Évalué à 2.

Zonecheck est pratique pour valider la configuration.

Système - Réseau - Sécurité Open Source
- [^] # Re: problème côté client ?
  
  Posté par Philippe M (site web personnel) le 19 février 2013 à 11:02. Évalué à 1.
  
  J'ai oublié de préciser que c'était pour un dns local.
  
  Born to Kill EndUser !
  - [^] # Re: problème côté client ?
    
    Posté par Philippe M (site web personnel) le 19 février 2013 à 11:10. Évalué à 0.
    
    oupsss je connaissais que le zonecheck de l'afnic et je ne savais pas qu'on pouvait avoir le même pour le local.
    
    Born to Kill EndUser !
# problème coté client

Posté par marquez le 19 février 2013 à 13:20. Évalué à 0.

le problème vient peut être du suffixe dns mal renseigné pour tes clients xp.

Il y a un suffixe dns principal à renseigner dans les propriétés du poste de travail, et dans le cas où il y a plusieurs zones dns concernées, on peut rentrer toute une liste dans les propriétés TCP-IP de la carte du poste.

Voir http://www.labo-microsoft.org/articles/win/delegation_dns/1/
pour plus d'infos sur le mécanisme de résolution de nom sous windows.
- [^] # Re: problème coté client
  
  Posté par NeoX le 19 février 2013 à 13:57. Évalué à 2.
  
  et avec tres peu de manip, ca peut se faire via le dhcp de ton reseau
- [^] # Re: problème coté client
  
  Posté par Philippe M (site web personnel) le 19 février 2013 à 14:00. Évalué à 0. Dernière modification le 19 février 2013 à 14:00.
  L'adressage est géré par un dhcp (sur linux) et c'est lui qui donne tout les paramètres aux machines.
```
subnet 192.168.x.0 netmask 255.255.255.0 {
[...]
   option domain-name "dom.mondom";
[...]
```
  Sur un client XP à la commande ipconfig /all j'ai :
```
[...]
Suffixe DNS principal . . . . . . : dom.mondom
[...]
```
  Born to Kill EndUser !
  - [^] # Re: problème coté client
    
    Posté par marquez le 19 février 2013 à 18:41. Évalué à 0.
    
    Tu as bien un type de noeud hybride dans le ipconfig /all ? ça influe sur l'ordre de résolution(wins/dns).
    - [^] # Re: problème coté client
      
      Posté par nono14 (site web personnel) le 19 février 2013 à 20:24. Évalué à 2.
      
      Sinon, tu mets un samba avec proxy wins.
      
      Système - Réseau - Sécurité Open Source
      - [^] # Re: problème coté client
        
        Posté par Philippe M (site web personnel) le 20 février 2013 à 05:55. Évalué à 1.
        
        Samba et wins ok pour moi ça va ensemble mais il me semble que DNS est sensé être au dessus de wins qui a terme devrait disparaitre avec l'arrivé de samba4 et surtout que tout les services microsoft sont basés sur dns maintenant… Sauf si tu a un antique NT4 qui traine ;)
        
        Born to Kill EndUser !
        
        [^] # Re: problème coté client
        
        Posté par nono14 (site web personnel) le 20 février 2013 à 10:23. Évalué à 2.
        
        Il existe une option dans le fichier de conf du serveur dhcp qui spécifie les domaines de recherche.
        
        Système - Réseau - Sécurité Open Source
        
        [^] # Re: problème coté client
        
        Posté par Philippe M (site web personnel) le 20 février 2013 à 10:54. Évalué à 1.
        
        Bingo quand je tape domain-search sur google je tombe sur des posts de gens qui ont le même problème que moi. Ni une, ni deux pouff j'ajoute ça dans mon dhcpd.conf et un reload et ça tombe en marche :
        
        Feb 20 10:40:51 xxxx dhcpd: /etc/dhcpd.conf line 51: unknown option dhcp.domain-search Feb 20 10:40:51 xxxx dhcpd: option domain-search "dom.mondom" Feb 20 10:40:51 xxxx dhcpd: ^ Feb 20 10:40:51 xxxx dhcpd: Configuration file errors encountered -- exiting #rpm -qa | grep dhcp dhcp-3.0.5-29.el5_7.1
        
        Dans le pire des cas je peux monter jusqu'à la version dhcp-3.0.5-33.el5_9 ou après va falloir que je passe à rh6 mais mettre à jour un serveur de domaine c'est pas anodin :( et je ne suis pas certain que la version rh6 intègre la bonne version de dhcp.
        
        Born to Kill EndUser !
        
        [^] # Re: problème coté client
        
        Posté par -=[ silmaril ]=- (site web personnel) le 20 février 2013 à 11:07. Évalué à 2.
        
        le support native de domain-search est present à partir de la version 3.1
        
        Tu peut toujours le configurer à la main
        
        But you can still configure the domain-search option by hand. The
        easiest thing is to configure it without compression tags;.
        
        # declaration de l'option option domain-search code 119 = text; # creation d'une liste de recherche avec "mondom, dom.mondom": option domain-search "\006mondom\000\003dom\006mondom\000";
        
        les code \00x sont des nombres encodés en octal, qui correspondent au nombre
        de caractères du bloc qui suit (mondom = 6 dom = 3, ..), chaque domaine de la liste
        de recherche est terminé par un null (\000).
        
        [^] # Re: problème coté client
        
        Posté par Philippe M (site web personnel) le 20 février 2013 à 11:17. Évalué à 1.
        
        oufff ça marche enfin.
        
        Merci pour la solution et merci à tous pour l'aide.
        
        Born to Kill EndUser !
    - [^] # Re: problème coté client
      
      Posté par Philippe M (site web personnel) le 20 février 2013 à 11:08. Évalué à 1.
      
      oui il est de type 8 ou H-node dans le fichier de config de dhcp et se paramètre est bien repris sur les clients.
      
      Born to Kill EndUser !
# Le bug est dans l'étoile noire

Posté par ʭ ☯ le 19 février 2013 à 18:42. Évalué à 0.

J'ai souvent constaté ce bug côté Windows. Pour le régler, il faut déclarer à la mimine toutes les zones dans lesquelles tu veux que Windows cherche. Et ça passe pas par DHCP, je le fais avec un .reg au démarrage des postes.

⚓ À g'Auch TOUTE! http://afdgauch.online.fr
- [^] # Re: Le bug est dans l'étoile noire
  
  Posté par Philippe M (site web personnel) le 20 février 2013 à 05:53. Évalué à 0.
  
  En fait j'ai l'impression que le suffixe définit au niveau de la connexion réseau et donc attribué par dhcp est à peine pris en compte par windows alors que si je l'ajoute au niveau du paramétrage général ça passe. Pas très pratique et je vois pas trop pourquoi mettre un dhcp si c'est pour devoir intervenir sur chaque machines. Je vais voir pour le coups du reg mais va falloir que je le trouve dans la bdr et puis comme les utilisateurs sont pas admin pas sûr que ça passe au niveau droit à la connexion.
  
  Born to Kill EndUser !
# Directement dans Bind ?

Posté par Kerro le 20 février 2013 à 02:46. Évalué à 0.

Le plus simple ne serait-il pas de configurer directement des suffixes dans Bind ?
Je n'ai aucun idée de la faisabilité de la chose. Le principe serait que toute requête non résolue serait testée en ajoutant le premier suffixe, puis le second, etc.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.