Ou comment sont résolues les requetes DNS sur mon poste.

source

Sur les Debians récentes, la résolution DNS est prioritairement assurée par systemd-resolved qui s’initialise depuis le fichier /etc/resolv.conf mais qui l’ignore ensuite. Donc si l’on modifie le fichier systemd-resolved ne tient pas compte des modifications. dig qui ne lit que le fichier /etc/resolv.conf utilise alors un DNS différent de ping qui passe par la glibc, qui passe par NSS, qui passe par systemd-resolved.

Si on regarde la configuration de ce service avec la commande cat /etc/nsswitch.conf | grep hosts (on ne s’intéresse qu’a la partie hosts), on voit la ligne suivante :

hosts:          files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

Quelques explications :

• files: Représente les fichiers de configuration comme /etc/hosts
• mdns4_minimal: Est le service mDNS ou DNS Multicast fourni par Avahi. C’est le service qui découvre les noms des machines de votre réseau local en fonction de leur hostname sans avoir besoin de DNS central.
• resolve: C’est le service systemd-resolved
• dns: C’est la résolution DNS classique par resolv.conf
• myhostname: C’est la commande hostname. En gros il regarde si c’est pas le nom de la machine locale.

Cette ligne donne dans l’ordre des bases dans lesquelles le système cherche l’ip d’un nom de domaine. On voit donc que resolve est présent AVANT dns.

C’est de là que vient la différence. nslookup comme dig lisent le fichier resolv.conf, en sortent l’IP du DNS et lui demandent la résolution, ni plus ni moins. Ils ignorent NSS. ping quant à lui, comme la plupart des applications web (navigateurs, …) utilise la glibc qui passe par NSS pour résoudre les noms d’hôtes. Comme resolve est prioritaire à dns, s’il n’utilise pas les mêmes DNS que ceux présents dans le fichier resolv.conf le résultat des deux commandes est différent.