Ma Debian bullseye est folle ! Le sujet est résolu

[diesel]

Bonjour,

Intrigué par le délai d'accès à un serveur qui ne répond qu'en ipv6, j'ai lancé un petit tcpdump sur mon poste de travail et je constate le comportement (bizarre) suivant :

- 14:41:12 il lance une requête mDNS en ipv6 pour résoudre serveur.local en ipv4 (requête de type A)
- 14:41:12 juste derrière, il lance une requête mDNS en ipv4 pour résoudre serveur.local en ipv4 (requête de type A)

Cette suite de deux requêtes se répète à 14:41:13 et 14:41:15

Et ce n'est enfin qu'à :
- 14:41:17 il lance une requête mDNS en ipv6 pour résoudre serveur.local en ipv6 (requête de type AAAA)
- 14:41:17 il lance une requête mDNS en ipv4 pour résoudre serveur.local en ipv6 (requête de type AAAA)

et
- 14:41:17 le serveur répond en ipv6 à la requête mDNS avec son adresse ipv6 et les échanges ssh (puisqu'il s'agissait d'un accès ssh) commencent enfin, toujours à 14:41:17

Ce que j'aimerais comprendre, c'est pourquoi il a fallu 5 secondes à la Debian bullseye de mon poste de travail pour se dire qu'elle pourrait éventuellement demander une résolution d'adresse en ipv6.

Amicalement.

Jean-Marie

[PascalHambourg]

Que contient la ligne hosts: du fichier /etc/nsswitch.conf ?

[diesel]

Code : Tout sélectionner

hosts:          files mdns_minimal [NOTFOUND=return] dns myhostname

Ça fonctionne, mais c'est très lent.

Amicalement.

Jean-Marie

[diesel]

Bon, j'ai un peu cherché et c'est la bibliothèque libnss-mdns qui lit les paramètres mdns-minimal (ou mdns4-minimal ou mdns6-minimal ou...) et qui est manifestement buguée.

En effet, depuis au moins 15 ans, les composants réseau donnent la prédominance à l'ipv6 par rapport à l'ipv4 si les deux sont présents. Et là, on a un composant qui, en 2023, fait le contraire.

Le minimum qu'il devrait faire, c'est demander une résolution en ipv6 s'il fait la requête en ipv6 et une résolution en ipv4 s'il fait la requête en ipv4.

Pour l'instant, j'ai changé mdns-minimal en mdns6_minimal dans le fichier /etc/nsswitch.conf et ça marche parfaitement. Cependant, j'ai des composants sur mon réseau (imprimante par exemple) qui ne savent répondre qu'à des requêtes mdns en ipv4 et que je ne peux plus contacter par ce biais. J'ai trouvé un autre moyen, mais quand-même.

Je vais regarder les sources de la lib et je pense que je vais poster un bug (si je trouve comment faire).

Amicalement.

Jean-Marie

[diesel]

J'ai regardé les sources et la doc fournie avec.

La doc renvoie à des bugs qui ont fait l'objet de débats passionnés desquels il ressort essentiellement que avahi est abandonné (ou en passe de l'être, probablement au profit de systemd-networkd et systemd-resolved) et que la libnss-mdns qui va avec ne fait plus l'objet de développement actif.

Je vais donc rester avec ma directive mdns6_minimal en attendant que ça change "tout seul".

Amicalement.

Jean-Marie

[PascalHambourg]

De mon côté j'ai fait quelques tests et je ne suis pas convaincu que le problème vient de libnss-mdns car j'observe le même comportement avec les requêtes DNS. J'ai plutôt l'impression que cela vient de du résolveur de la libc lui-même, et de la façon dont on l'appelle.
Avec "gentent hosts (qui utilise gethostbyname())", requête AAAA puis A.
Avec "getent ahosts" (qui utilise gettaddrinfo()), requête A puis AAAA.