Problème de serveur DNS avec Windows 7 et dhcp (dans un cas bien particulier)

Imaginons un serveur isc dhcpd configuré de la sorte (centos 6.4) :


...
subnet 192.168.0.0 netmask 255.255.255.0 {
option domain-name-servers  192.168.0.1;
option  routers 192.168.0.254;
authoritative;
deny client-updates;
deny
pool {
allow unknown-clients;
range 192.168.0.100 192.168.0.200;
}
host  monposte.be-root.com {
option domain-name-servers  192.168.0.2;
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address 192.168.0.10;
}
}

Symptômes :

Sur la machine monposte :
si l’on boote sur un livecd (ubuntu), nous obtenons comme paramètres via le dhcp 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2 (les paramètres sont donc ceux attendus)
si l’on boote sur windows 7, nous obtenons comme paramètres via le dhcp 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.1  (le serveur dns n’est pas celui déclaré dans la section host. Il s’agit du dns déclaré dans la section subnet).

Si sous windows 7, nous effectuons un ipconfig /renew alors les parametres sont 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2. Cependant, au redémarrage suivant, les paramètres sont de nouveau 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.1.

Analyse :
Si l’on sniffe l’echange entre le poste windows 7 et le serveur dhcp, on remarque :
-1 requête DHCP Request de la part du client
-1 réponse DHCP ACK de la part du serveur DHCP lui fournissant les paramètres  192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2 (donc corrects).
-1 requête DHCP Inform de la part du client précisant sont adresse 192.168.0.10 et demandant les paramètres subnet mask/domain name/ router/ domain name server/…/private-proxy autodiscovery
-1 réponse DHCP ACK de la part du serveur dhcp lui fournissant la passerelle 192.168.0.254 et le dns 192.168.0.1 (donc erronés).
– …
A priori, tant que le client ne reçoit pas de réponses valides pour la recherche automatique de proxy, il continue a faire des requêtes DHCPInform toutes les 100 secondes.
La norme concernant les requêtes DCHP Inform stipule :

The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease.

Ainsi, le serveur dhcpd n’utilise pas les informations de son fichier de leases pour répondre avec les même paramètres que ceux envoyés lors du DHCP Request mais parcours le fichier de configuration.
Comme l’adresse ip indiquée dans la requête DHCP Inform fait partie du subnet 192.168.0.0, il répond avec les paramètres globaux de la zone.

Résolution :
On peut contourner de problème de plusieurs façons :

  • Virer le paramètre authoritative dans le subnet. Le serveur ne répondra plus aux requêtes DHCP Inform … (moyen)
  • Supprimer les déclarations globales de serveurs dns et les mettre par hôte/pool. (long et pas très pratique).
  • Si l’on n’utilise pas la fonctionnalité de découverte automatique de proxy (wpad) : sur le client Windows7, lancer l’éditeur de base de registres.
    Sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\Identifiant-de-l-interface , créer une clé nommée UseInform de type DWORD. Initialiser à la valeur 0.
    Ainsi le client Windows 7 ne fera plus de requêtes DHCP Inform et donc conservera les informations retournées par lors de la première transaction DHCP Request.

Ubuntu 10.04 : Obtenir le hostname de la machine via le dhcp

Nous supposons qu’un serveur dhcp fonctionne déjà et est correctement configuré pour fournir les noms de machine.
Par exemple, pour ISC dhcpd :

           group {
             use-host-decl-names on;
             host joe {
               hardware ethernet 08:00:2b:4c:29:32;
               fixed-address joe.fugue.com;
             }
           }

Pour forcer Ubuntu a utiliser le hostname fourni (ici joe), nous allons forcer la distribution à ne pas utiliser network-manager. La machine concernée étant un poste de travail ordinaire, ne possédant qu’une seule carte réseau, nous allons tout simplement désinstaller network-manager.


sudo apt-get remove network-manager network-manager-gnome

Nous allons ensuite enlever les références à hostname et networkmanager dans /etc/init :


sudo mv /etc/init/hostname.conf /etc/init/hostname.conf.old

sudo mv /etc/init/network-manager.conf /etc/init/network-manager.conf.old

Nous allons ensuite modifier le fichier /etc/network/interfaces pour y rajouter les définitions concernant eth0 :

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp

La machine étant destinée a être déployée sur d’autre machine par clonage, il est nécessaire de modifier l’affectation du nom eth0, ce dernier possédant par défaut une référence à l’adresse MAC :

sudo gedit /etc/udev/rules.d/70-persistent-net.rules

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

devient :

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",  ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

La couche graphique étant chargée très tôt dans ubuntu 10.04, il est déconseillé de modifier le hostname à la volée une fois cette dernière lancée. Nous allons donc créer un script qui modifiera le /etc/hostname et donc la modification sera prise en compte lors du prochain démarrage de la machine :

sudo gedit /etc/dhcp3/dhclient-exit-hooks.d/sethostname

#!/bin/sh
        echo $new_host_name > /etc/hostname
        if test -r /var/run/gdm.pid && ps -ef | grep $(cat /var/run/gdm.pid) | grep -q /usr/sbin/gdm ; then
                echo "GDM is running, hostname will be updated at the next startup" >> /var/log/sethostname.log ; 
       else
                hostname $new_host_name;
        fi

Nous terminons la manip en donnant les droits d’exécution :

sudo chmod +x /etc/dhcp3/dhclient-exit-hooks.d/sethostname