Soit une machine sous Debian GNU/Linux wheezy, connecté à un réseau nazi que l'on contourne avec un VPN chez un FAI associatif et neutre. Sans ce VPN, la machine n'a pas d'adresse IPv6 globale.

Voici le contenu de son /etc/resolv.conf :
# Récursif 1
nameserver 192.0.2.1
nameserver 2001:db8::1

# Récursif 2
nameserver 192.0.2.2
nameserver 2001:db8::2

Explications :
    * On est dans la configuration standard, on n'utilise pas l'option « rotate » (« which causes round-robin selection of name servers from among those listed. This has the effect of spreading the query load among all listed servers, rather than having all clients try the first listed server first every time. »).
    * On a deux récursifs et, pour chaque, on utilise sa v4 et sa v6.
    * Ici j'utilise des IP de documentation mais ce n'est pas le cas dans la vraie conf', ofc.

On voit déjà une erreur : actuellement, le résolveur de la libc peut utiliser au maximum 3 serveurs/IPs. Source : http://linux.die.net/man/5/resolv.conf - « nameserver Name server IP address. Internet address of a name server that the resolver should query, either an IPv4 address (in dot notation), or an IPv6 address in colon (and possibly dot) notation as per RFC 2373. Up to MAXNS (currently 3, see <resolv.h>) name servers may be listed ».


Le problème est le suivant : quand le serveur récursif DNS 192.0.2.1 tombe et que le VPN n'est pas on (et donc que la machine n'a pas d'IPv6), le stub-resolver DNS de la libc est incapable de résoudre quelque nom que ce soit. Pourtant, il devrait basculer sur 192.0.2.2 !

On sort ltrace : la fonction de la libc appelée par ping (par exemple) est gethostbyname2(). On sort tcpdump : on voit un seul paquet DNS émis pour 192.0.2.1.

On remplace le contenu de /etc/resolv.conf par le suivant :
# Récursif 1
nameserver 192.0.2.1
#nameserver 2001:db8::1
nameserver 198.18.0.1

# Récursif 2
nameserver 192.0.2.2


198.18.0.1 est, comme 192.0.2.1, un récursif DNS qui ne fonctionne plus.

tcpdump nous montre : un paquet pour 192.0.2.1 puis, après expiration du timeout de 5 secondes (par défaut), un paquet pour 198.18.0.1, puis un paquet pour 192.0.2.2. La résolution de nom est lente mais est fonctionnelle.

Le soucis vient donc de la présence de l'IPv6 du 1er récursif qui bloque la libc si la machine n'a pas d'IPv6 configurée !

On sort une Debian Jessie, on reproduit les 2 configurations de test et... l'on constate que la présence d'une IPv6 n'est pas bloquante ! ltrace nous indique que c'est toujours gethostbyname2() qui est utilisée.

Il s'agit donc bien d'un bug de la glibc encore présent dans la v2.13 mais corrigée avant la 2.19 (packagée dans Jessie). Je n'ai rien trouvé dans le bugtracker de la glibc ni dans les changelog en cherchant « gethostbyname() ».

Conclusion : sur une version un peu old de la glibc, ne pas mixer IPv4 et IPv6 pour les récursifs DNS sur une machine qui n'a pas une adresse IPv6 globale en permanence. :D