Résolution de nom sur debian 9

Bonjour,

Je viens d’installer debian 9 sur un de mes portables (celui-ci porte l’adresse ip 192.168.10.1)

à partir de ce portable, je pingue mon poste de travail (adresse ip 192.168.10.2) à l’aide de la commande :

ping jean-marie.local

Le ping marche parfaitement, mais à l’enregistrement des trames réseau, je constate ceci :

01) 18:24:31.306366 ARP, Request who-has 192.168.10.1 tell _gateway, length 28
02) 18:24:31.306887 ARP, Reply 192.168.10.1 is-at 00:21:86:a2:32:d5 (oui Unknown), length 46
03) 18:24:31.427852 ARP, Request who-has _gateway tell 192.168.10.1, length 46
04) 18:24:31.427861 ARP, Reply _gateway is-at 00:1e:37:18:68:b4 (oui Unknown), length 28
05) 18:24:32.794798 ARP, Request who-has _gateway tell 192.168.10.2, length 46
06) 18:24:32.794813 ARP, Reply _gateway is-at 00:1e:37:18:68:b4 (oui Unknown), length 28
07) 18:24:38.088422 IP6 fe80::221:86ff:fea2:32d5.mdns > ff02::fb.mdns: 0 A (QM)? jean-marie.local. (34)
08) 18:24:38.088430 IP 192.168.10.1.mdns > 224.0.0.251.mdns: 0 A (QM)? jean-marie.local. (34)
09) 18:24:38.089090 IP jean-marie.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 (Cache flush) A 192.168.10.2 (44)
10) 18:24:38.090026 ARP, Request who-has jean-marie tell 192.168.10.1, length 46
11) 18:24:38.090035 ARP, Reply jean-marie is-at 4c:cc:6a:f4:3d:3e (oui Unknown), length 46
12) 18:24:38.090040 IP 192.168.10.1 > jean-marie: ICMP echo request, id 1641, seq 1, length 64
13) 18:24:38.090281 IP jean-marie > 192.168.10.1: ICMP echo reply, id 1641, seq 1, length 64
14) 18:24:38.091236 IP 192.168.10.1.37587 > ns0.fdn.org.domain: 27076+ PTR? 2.10.168.192.in-addr.arpa. (43)
15) 18:24:38.126696 IP ns0.fdn.org.domain > 192.168.10.1.37587: 27076 NXDomain* 0/1/0 (102)
16) 18:24:39.091519 IP 192.168.10.1 > jean-marie: ICMP echo request, id 1641, seq 2, length 64
17) 18:24:39.092030 IP jean-marie > 192.168.10.1: ICMP echo reply, id 1641, seq 2, length 64
18) 18:24:40.099926 IP 192.168.10.1 > jean-marie: ICMP echo request, id 1641, seq 3, length 64
19) 18:24:40.100401 IP jean-marie > 192.168.10.1: ICMP echo reply, id 1641, seq 3, length 64
20) 18:24:43.290754 ARP, Request who-has 192.168.10.1 tell 192.168.10.2, length 46
21) 18:24:43.290761 ARP, Reply 192.168.10.1 is-at 00:21:86:a2:32:d5 (oui Unknown), length 46

J’aimerais comprendre pourquoi le portable se croit autorisé à emmerder le serveur DNS ns0.fdn.org avec la résolution inverse de l’adresse 192.168.10.2 (ligne 14) ) alors qu’il vient juste d’avoir la correspondance (ligne 09) ).

Amicalement.

Jean-Marie

Une correspondance n’est valable que dans un seul sens.
“nom -> adresse” n’implique pas “adresse -> nom” (et vice versa).

PS : quand on fait des captures de trafic DNS, il vaut mieux désactiver la résolution d’adresse (-n) car ça peut générer du trafic DNS supplémentaire.

Bonsoir,

Merci pour ta contribution.

Cependant, je ne vois pas pourquoi le ping aurait besoin de faire une résolution de nom inverse (vu ce qu’il affiche).

D’autre part, les deux machines concernées font tourner le daemon avahi pour mettre en œuvre le protocole mDNS. Si ce daemon ne sert QUE pour faire la résolution de nom directe et pas la résolution inverse, il ne sert à rien.
Dans le cas présent, le portable est allé poser la question à un serveur DNS sur internet qui a été bien incapable de résoudre en inverse une adresse locale.

Y a-t-il un paramètre à fixer dans avahi pour qu’il aille aussi demander la résolution de nom inverse à l’aide du protocole mDNS ?

Amicalement.

Jean-Marie

P.S. La capture réseau a été faite sur une troisième machine qui, pour la petite histoire, envoie ses requêtes DNS ailleurs que sur le réseau 192.168.10.0

Pour afficher le nom d’hôte associé à l’adresse IP qui répond (qui n’est pas forcément l’adresse IP de destination du ping) lorsque l’option -n est absente.

Je ne connais pas assez mDNS pour te répondre.

Bon, je viens d’essayer la même manip à partir d’un macbook.

Pour le coup, je ne vois pas passer de requête DNS inverse sur l’adresse de mon portable. Cela dit, je ne sais pas quelle est l’implémentation de “ping” sur macos (est-ce qu’il n’a pas l’option -n par défaut ?).

Par contre, avant de me faire la requête mDNS de résolution du nom de mon portable, il lance une requête DNS sur le domaine “.local” ! Moi qui espérais que “Bonjour” serait bien implémenté sur mac…

Sur mon réseau local, j’ai besoin de mDNS pour faire tourner mon serveur d’impression sous “cups”.

De plus, comme je suis en train de passer sous ipv6 avec des adresses de machines dynamiques (sauf les serveurs, quand-même), je me suis dit que ce n’était pas une mauvaise idée de confier la résolution des noms locaux à un système, lui aussi dynamique. Et puis, ça faisait un service de moins à administrer.

Mais vu le résultat (déjà en ipv4, et c’est pire en ipv6), je vais faire marche arrière et remettre un serveur DNS sur mon serveur.

Amicalement.

Jean-Marie

J’ai regardé la documentation du paquet libnss-mdns dans /usr/share/doc/libnss-mdns/.
mDNS peut faire de la résolution inverse mais il y a deux variantes du résolveur (sans compter les variantes IPv4 seul et IPv6 seul) :

  • mdns_minimal : ne traite que les noms de domaine en *.local et les adresses en 169.254.* (link local).

  • mdns : traite tous les noms et adresses

Il faut regarder dans /etc/nsswitch.conf le contenu de la ligne “hosts:”. Si c’est par exemple

hosts: files mdns4_minimal [NOTFOUND=return] dns

Alors le résolveur utilisera mDNS uniquement pour les noms de domaine en *.local et les adresses IPv4 en 169.254.*. Avec

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

le résolveur utilisera aussi mDNS pour tout nom de domaine et adresse IPv4 si la résolution DNS ne retourne pas de résultat, mais au prix d’un délai de quelques secondes si aucune réponse mDNS n’est reçue.

Merci beaucoup PascalHambourg,

Effectivement, je m’étais penché sur la doc de mdns et mdns_minimal et j’y avais bien relevé une différence, mais pas aussi précise que ce que tu me dis (169.254.*).

Je vais relire ça de plus près.

Amicalement.

Jean-Marie