Beh c’est pourquoi je suis d’accord avec toi sur le manque de fiabilité du truc…
Pour résoudre le problème de dFuuP je recommande une autre solution.
Quand a ce qu’affiche la box je ne le dis pas je l’écris.
Adresse MAC Adresse IP Port
1 00:26:2d:19:6d:63 192.168.1.39 (homepc) PC 1 <-- adresse dhcp
2 00:26:9e:25:b7:76 192.168.1.26 (lapdeb) TV <-- adresse dhcp
3 52:54:00:91:72:98 192.168.1.200 (37L4247E29-32) PC 2 <-- adresse statique (machine virtuelle windows, le nom de correspond pas)
4 52:54:00:4c:d1:9a 192.168.1.101 PC 2 <-- adresse statique (machine virtuelle Debian, le nom ne remonte pas)
5 00:15:17:25:ac:6c 192.168.1.100 (mld-win) PC 2 <-- adresse statique (hyperviseur KVM sous Debian, le nom correspond a l’ancien nom lorsque la machine était sous windows il y 3 mois)
6 52:54:00:45:b4:37 192.168.1.124 (z-imgsrv) PC 2 <-- adresse statique (machine virtuelle Debian, la ça correspond)
La sortie de la commande [mono]host[/mono] fournie plus haut montre bien que la box (192.168.1.1) retourne bien l’adresse en mode DNS (commande [mono]host[/mono] et port 53) alors que le tableau reproduit au dessus, généré par la box, ressemble plus à une table arp.
Bref un joli gloubiboulga pas frais…
Ça confirme que baser une résolution de noms locaux la dessus, ça craint !
Par ailleurs ma box forward les requètes DNS vers les serveurs publique de neuf, pour les machine en DHCP, pour les adresses statique l’une des VM résout (via bind9) les adresses locales et forward au DNS google pour les autres.
Quand a ARP et les nom, depuis l’hyperviseur:
# arp -a
lapdeb.mondomaine (192.168.1.26) at 00:26:9e:25:b7:76 [ether] on br0
imgsrv.mondomaine (192.168.1.101) at 52:54:00:4c:d1:9a [ether] on br0
? (192.168.1.1) at 00:25:15:ad:61:ac [ether] on br0
Mais je suis néanmoins d’accord avec toi qu’à la base le job d’arp n’a rien à voir avec les noms.