Ubuntu 24.04 : sudo est lent — corrections DNS/nom d’hôte pour supprimer le délai (cas n°6)

Ce que «sudo lent» est réellement (et ce que ce n’est pas)

«Sudo lent» n’est généralement pas votre disque, pas votre CPU, et pas un module PAM hanté invoquant des démons.
C’est typiquement un appel de résolution de nom bloquant qui se produit avant que sudo n’affiche l’invite de mot de passe.
Cet appel peut être une résolution DNS directe, inverse, mDNS, des services de nom LDAP/SSSD, ou même un résolveur mal configuré qui expire.

La raison pour laquelle on a l’impression que sudo est lent, c’est que l’humain ne voit qu’une seule chose : l’invite de mot de passe.
Sous le capot, sudo réalise des préparatifs (vérification de la politique, identification de l’hôte, audit, journalisation).
Si une dépendance bloque—en particulier la résolution de nom—vous restez planté.

À quoi ça ressemble

• Le délai se produit avant que l’invite de mot de passe apparaisse (classique).
• Le délai est constant : ~1–5 secondes, souvent correspondant exactement aux modèles de timeout/retry DNS.
• Le délai disparaît quand vous déconnectez le VPN / quittez le réseau d’entreprise / changez de Wi‑Fi.
• Le délai est présent sur la console et SSH, pas seulement dans un émulateur de terminal.

Ce que ce n’est pas (la plupart du temps)

• Ce n’est pas votre configuration de shell. Les invites de shell s’affichent avant que vous ne tapiez sudo.
• Ce n’est pas votre disque qui est lent. sudo lit de petits fichiers. Votre NVMe n’est pas le goulot d’étranglement ici.
• Ce n’est pas un problème de «manque de RAM». Le délai est temps réel, pas temps CPU.

Blague n°1 : DNS est le «ça marchait hier» du service informatique. C’est aussi le «ça marchera demain», ce qui est moins rassurant.

Plan rapide de diagnostic

Vous voulez le chemin le plus rapide vers «sur quoi ça bloque ?» sans vous perdre en futilités.
Voici le plan que j’utilise sur des hôtes de production où la patience est une faiblesse.

Première étape : mesurer le délai et confirmer que c’est la résolution de nom

1. Chronométrez sudo et reproduisez deux fois pour confirmer la régularité.
2. Exécutez strace sur sudo et cherchez des connect()/sendto() vers le DNS ou des appels getaddrinfo().
3. Testez la résolution de nom locale via getent (avant et inverse) parce que c’est ce que libc/NSS utilise réellement.

Deuxième étape : identifier quel chemin de résolveur est utilisé

1. Vérifiez /etc/nsswitch.conf pour la ligne hosts:. Elle dicte l’ordre des recherches (files, dns, mdns4_minimal, resolve).
2. Inspectez resolvectl status (systemd-resolved) ou /etc/resolv.conf pour voir où vont les requêtes.
3. Si vous êtes sur des systèmes d’entreprise, vérifiez l’intégration SSSD/LDAP/AD car elle peut s’intercaler dans les recherches d’hôte/utilisateur.

Troisième étape : corriger la chose la plus simple qui garantit un chemin rapide

1. Assurez-vous que votre nom d’hôte est mappé dans /etc/hosts vers une entrée loopback (127.0.1.1 ou 127.0.0.1) avec nom court et FQDN si nécessaire.
2. Supprimez les options de résolveur «mignonnes» qui augmentent le timeout (mauvais search domains, nameservers cassés).
3. Ce n’est qu’ensuite que vous touchez à sudo/PAM/journaux si vous avez une raison prouvée.

Pourquoi sudo touche au DNS/nom d’hôte

sudo est plus que «exécuter une commande en root». C’est un moteur de politique avec des traces d’audit.
Il doit décider si vous pouvez exécuter cette commande ici.
«Ici» signifie l’identité de l’hôte. «Vous» signifie un nom d’utilisateur et des groupes. «Audit» signifie des journaux qui incluent souvent des noms d’hôte.

Les coupables habituels du délai lié au nom d’hôte/DNS

• Résolution de nom pour journalisation et politique.
  Beaucoup d’environnements veulent des journaux avec des noms, pas des IP brutes. Cela peut déclencher des recherches inverses.
• Ordre NSS (Name Service Switch).
  Si votre ligne hosts: essaie mDNS, WINS, LDAP ou des démons résolveurs avant de vérifier files,
  vous pouvez en payer le prix à chaque appel.
• systemd-resolved ou timeouts des DNS en amont.
  Les timeouts des résolveurs durent souvent quelques secondes—exactement le délai que vous observez.
• Incohérence FQDN.
  Une machine nommée web-01 dont le DNS dit web-01.corp.example mais dont /etc/hosts est différent
  peut envoyer les recherches sur des chemins lents.
• Intégration SSSD / AD.
  Si vous utilisez des utilisateurs de domaine, SSSD peut ajouter de la latence quand il tente de contacter des contrôleurs—même pour des actions «locales».

La posture que je recommande : traitez l’identité d’hôte et le service de noms comme des dépendances.
Les dépendances tombent en panne de façons étranges. Faites en sorte que le chemin rapide soit local, déterministe et ennuyeux.

Citation (idée paraphrasée) de Werner Vogels (CTO d’Amazon) : Tout échoue tout le temps ; concevez en supposant que les composants vont casser.

Faits et contexte historique utiles pour argumenter

Ce ne sont pas des trivia pour le plaisir. Ils expliquent pourquoi la résolution de noms moderne sur Ubuntu peut ressembler à une machine de Rube Goldberg
si vous l’abordez comme si nous étions en 2009.

1. NSS (Name Service Switch) remonte à Solaris et a été largement adopté sur Linux pour contrôler l’ordre des recherches (files, DNS, LDAP, etc.). Un mauvais ordre cause toujours des «lentesses mystères».
2. Ubuntu utilisait historiquement 127.0.1.1 dans /etc/hosts pour le nom d’hôte local, surtout sur des systèmes sans IP stable. C’est étrange, mais cela évite les passages par le résolveur.
3. systemd-resolved a introduit un comportement de stub resolver local qui a changé le comportement de /etc/resolv.conf sur de nombreuses distributions. Le chemin «qui répond au DNS ?» est devenu moins évident.
4. mDNS (multicast DNS) est excellent pour les imprimantes et portables ; c’est une responsabilité sur les serveurs si c’est avant files et que votre réseau filtre mal le multicast.
5. Reverse DNS (PTR) est souvent absent ou incorrect sur les réseaux internes. C’est acceptable jusqu’à ce que quelque chose bloque dessus, comme la journalisation/audit.
6. Les clients VPN poussent souvent des search domains et des listes de nameservers qui sont corrects pour les applications internes mais désastreux pour la latence si le chemin réseau est peu fiable.
7. Le comportement de sudo a évolué avec les attentes de sécurité : plus d’audit, plus de contexte de politique, plus d’endroits où le nom d’hôte se retrouve dans les journaux.
8. Les pratiques DNS héritées de l’ère Windows (WINS, split DNS, longues listes de search) fuient encore dans les configs Linux via DHCP et peuvent ralentir les recherches dramatiquement.

Tâches pratiques : commandes, sorties et décisions (12+)

Chaque tâche inclut : une commande que vous pouvez exécuter, un exemple de sortie «mauvaise» ou «intéressante»,
et la décision que vous prenez à partir de cela. Ne survolez pas les décisions—c’est là que se trouve la valeur.

Task 1: Time the symptom like you mean it

cr0x@server:~$ time sudo -n true

real    0m2.312s
user    0m0.008s
sys     0m0.010s

Ce que cela signifie : 2,3 secondes de temps réel, presque zéro CPU. Ça crie «bloqué sur I/O», et DNS est de l’I/O.
Décision : Arrêtez de spéculer sur le CPU/disque. Passez au traçage du service de noms.

Task 2: Confirm it’s before the password prompt (interactive)

cr0x@server:~$ time sudo true
[sudo] password for cr0x: 

real    0m2.205s
user    0m0.009s
sys     0m0.012s

Ce que cela signifie : Le délai se produit avant que la saisie du mot de passe soit acceptée (l’invite apparaît tard).
Décision : Examinez la résolution de nom et la journalisation, pas la vérification PAM du mot de passe.

Task 3: Use strace to catch the blocker (fast and rude)

cr0x@server:~$ sudo strace -f -tt -o /tmp/sudo.trace sudo -n true
sudo: a password is required

cr0x@server:~$ tail -n 25 /tmp/sudo.trace
12:20:01.101234 connect(6, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.0.0.2")}, 16) = 0
12:20:01.101540 sendto(6, "\252\273\1\0\0\1\0\0\0\0\0\0\6server\4corp\7example\0\0\34\0\1", 36, 0, NULL, 0) = 36
12:20:03.103901 recvfrom(6, 0x7ffd8b2a3f10, 2048, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
12:20:03.104220 close(6) = 0

Ce que cela signifie : Une requête DNS vers 10.0.0.2 a expiré après ~2 secondes.
Décision : Réparez l’accessibilité/ordre des résolveurs ou contournez le DNS pour le nom d’hôte local via /etc/hosts.

Task 4: Inspect what hostname sudo thinks it’s on

cr0x@server:~$ hostnamectl
 Static hostname: server
       Icon name: computer-vm
         Chassis: vm
      Machine ID: 8cbe2c8a1b3d4f1e9e6c0c4b3c1c9d2a
         Boot ID: 2f9c9a1de2bf44a6a3a8c5f5f7e38e0a
  Virtualization: kvm
Operating System: Ubuntu 24.04 LTS
          Kernel: Linux 6.8.0-31-generic
    Architecture: x86-64

Ce que cela signifie : Le nom d’hôte statique est server (nom court).
Décision : Assurez-vous que server se résout rapidement via /etc/hosts. Décidez si vous avez aussi besoin d’un FQDN.

Task 5: Check forward lookup through NSS (not “dig”, not “nslookup”)

cr0x@server:~$ getent hosts $(hostname)
10.22.1.17      server.corp.example server

Ce que cela signifie : NSS renvoie une adresse basée sur DNS rapidement (dans cet exemple).
Si cette commande bloque, sudo peut aussi bloquer.
Décision : Si c’est lent, priorisez la correction de /etc/hosts ou des paramètres de résolveur.

Task 6: Check reverse lookup for your primary IP

cr0x@server:~$ ip -br addr show scope global
ens3             UP             10.22.1.17/24

cr0x@server:~$ getent hosts 10.22.1.17
10.22.1.17      server

Ce que cela signifie : La recherche inverse renvoie server.
Si elle expire, votre pile de logs ou sudo peut déclencher des recherches PTR.
Décision : Si la recherche inverse est lente, corrigez le PTR dans le DNS (idéal) ou assurez un mappage local dans /etc/hosts.

Task 7: Check /etc/hosts for the classic missing mapping

cr0x@server:~$ sed -n '1,120p' /etc/hosts
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

Ce que cela signifie : Pas d’entrée pour server. Cela force NSS à consulter des sources réseau.
Décision : Ajoutez un mappage loopback pour votre nom d’hôte afin de rendre la résolution locale instantanée.

Task 8: Inspect NSS order for host lookups

cr0x@server:~$ grep -E '^\s*hosts:' /etc/nsswitch.conf
hosts:          files mdns4_minimal [NOTFOUND=return] dns

Ce que cela signifie : Cela tente files, puis mDNS, puis DNS.
Sur des serveurs, mDNS peut être un détour que vous ne voulez pas.
Décision : Si mDNS cause des délais, envisagez de le retirer ou de le déplacer après dns (prudemment—voir corrections).

Task 9: See whether systemd-resolved is in charge

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 10.0.0.2
       DNS Servers: 10.0.0.2 10.0.0.3
        DNS Domain: corp.example

Ce que cela signifie : Les requêtes vont vers 10.0.0.2/10.0.0.3. Le mode stub signifie que /etc/resolv.conf pointe vers un stub local.
Décision : Testez directement ces serveurs DNS. S’ils sont inaccessibles depuis cet hôte/réseau, corrigez la configuration DHCP/VPN/resolver.

Task 10: Validate that DNS servers respond quickly (direct query)

cr0x@server:~$ dig +time=1 +tries=1 @10.0.0.2 $(hostname).corp.example A

; <<>> DiG 9.18.24-0ubuntu0.24.04.1-Ubuntu <<>> +time=1 +tries=1 @10.0.0.2 server.corp.example A
;; global options: +cmd
;; connection timed out; no servers could be reached

Ce que cela signifie : Le serveur DNS configuré n’est pas accessible (ou filtré).
Décision : Corrigez la liste de résolveurs. Ou, si vous ne pouvez pas, court‑circuiter localement le nom d’hôte via /etc/hosts pour que sudo n’en tienne pas compte.

Task 11: Check /etc/resolv.conf for stub vs direct resolvers

cr0x@server:~$ readlink -f /etc/resolv.conf
/run/systemd/resolve/stub-resolv.conf

Ce que cela signifie : Vous utilisez le stub de systemd-resolved.
Décision : Ne «corrigez» pas /etc/resolv.conf manuellement à moins que vous ne choisissiez explicitement d’en sortir. Corrigez la configuration en amont à la place.

Task 12: See if SSSD is in the lookup path (common in enterprise)

cr0x@server:~$ systemctl is-active sssd
active

cr0x@server:~$ getent passwd $USER
cr0x:x:1000:1000:cr0x:/home/cr0x:/bin/bash

Ce que cela signifie : SSSD est actif. Il peut influencer les recherches selon la configuration NSS.
Décision : Si les délais de sudo corrèlent avec l’accessibilité des AD/DC, inspectez les journaux SSSD et la configuration NSS ; ne blâmez pas seulement le DNS.

Task 13: Detect search domain pain (slow NXDOMAIN walking)

cr0x@server:~$ resolvectl domain
Global: corp.example lab.example dev.example

Ce que cela signifie : Plusieurs search domains peuvent provoquer plusieurs requêtes par recherche, surtout avec des noms non qualifiés.
Décision : Préférez les FQDN dans les configurations, réduisez les listes de search quand c’est possible, et assurez-vous que votre nom d’hôte se résout sans parcours de search.

Task 14: Measure lookup latency through NSS (repeatable)

cr0x@server:~$ /usr/bin/time -f '%e seconds' getent hosts $(hostname) >/dev/null
2.01 seconds

Ce que cela signifie : La résolution NSS prend ~2 secondes.
Décision : Réparez la résolution de noms d’abord. sudo n’est que le messager qui se fait tirer dessus.

Task 15: Prove mDNS is or isn’t involved

cr0x@server:~$ /usr/bin/time -f '%e seconds' getent hosts server.local >/dev/null
1.99 seconds

Ce que cela signifie : Les recherches en .local peuvent déclencher mDNS. Si c’est lent et que votre hosts: inclut mdns, vous avez une piste.
Décision : Sur des serveurs, désactivez mDNS ou réordonnez-le sauf si vous avez un besoin réel.

Task 16: Confirm sudo log settings aren’t forcing FQDN weirdness

cr0x@server:~$ sudo -V | sed -n '1,60p'
Sudo version 1.9.15p5
Sudoers policy plugin version 1.9.15p5
Sudoers file grammar version 50
Sudoers I/O plugin version 1.9.15p5
Sudoers audit plugin version 1.9.15p5
Local IP address and netmask pairs:
    10.22.1.17 / 255.255.255.0

Ce que cela signifie : Vous voyez l’énumération des IP locales. Parfois cette énumération déclenche des recherches inverses selon l’environnement.
Décision : Restez concentré : réparez la résolution du nom/IP localement. Ne touchez pas aux réglages sudoers par mimétisme sans avoir mesuré.

Schémas de correction qui suppriment vraiment le délai

Il existe une douzaine de manières de «faire croire que c’est mieux» et deux manières de corriger réellement.
Les manières correctes sont : (1) rendre la résolution de nom d’hôte locale et instantanée, et (2) rendre le DNS en amont fiable et accessible.
Faites les deux quand vous le pouvez. Faites (1) quand vous devez.

Fix #1: Put your hostname in /etc/hosts (fast path, nearly always safe)

Sur Ubuntu, le correctif le plus courant est aussi le moins glamorous : assurez-vous que le nom du système se résout via files
sans toucher au DNS. Cela signifie ajouter un mappage loopback.

Que faire (exemple pour le nom d’hôte server et le FQDN server.corp.example) :

cr0x@server:~$ sudoedit /etc/hosts

Exemple de contenu à ajouter (conserver les lignes existantes) :

cr0x@server:~$ sed -n '1,20p' /etc/hosts
127.0.0.1       localhost
127.0.1.1       server.corp.example server

::1             localhost ip6-localhost ip6-loopback

Ce que cela signifie : Le nom d’hôte se résout immédiatement via files. Plus de dépendance DNS pour l’identité locale.
Décision : Si cela élimine le délai, vous pouvez planifier l’hygiène DNS plus tard au lieu de perdre l’après-midi.

Orientation d’opinion : pour un serveur, je veux que /etc/hosts contienne le nom d’hôte local.
Oui, même si «DNS devrait être la source de vérité». Le DNS est une source de vérité jusqu’à ce qu’il soit une source d’alertes.

Fix #2: Make sure your hostname and FQDN expectations match

Les problèmes surviennent quand différentes couches ne sont pas d’accord sur le fait que le nom «réel» soit court ou entièrement qualifié.
Certains environnements traitent server comme «server.corp.example» via des search domains ; d’autres non.
Votre travail est de rendre cela explicite.

Décidez quel doit être le nom d’hôte :

• Nom court (server) : courant pour les VM, hôtes internes, et quand vous ne voulez pas de renommages.
• Nom FQDN (server.corp.example) : parfois requis par des outils, certificats ou politiques AD.

Définissez-le clairement (si vous devez le changer) :

cr0x@server:~$ sudo hostnamectl set-hostname server.corp.example

Décision : Ne définissez le FQDN comme nom statique que si votre organisation en a besoin. Sinon gardez le nom court et mappez le FQDN dans /etc/hosts.
Renommer des hôtes en production est une bonne manière de découvrir tout ce qui suppose que les noms ne changent jamais.

Fix #3: Fix resolver reachability (stop timing out to dead DNS)

Si vos serveurs DNS configurés ne répondent pas, chaque recherche devient une loterie d’expirations.
Avec systemd-resolved, vous héritez souvent de résolveurs via DHCP, VPN ou la configuration netplan.

Trouver les serveurs DNS actifs :

cr0x@server:~$ resolvectl dns
Global: 10.0.0.2 10.0.0.3
Link 2 (ens3): 10.0.0.2 10.0.0.3

Décision : Si ceux-ci sont inaccessibles depuis ce segment réseau, corrigez la configuration réseau (DHCP scope, profil VPN, netplan).
Ne «résolvez» pas le problème en ajoutant des DNS publics sur un hôte d’entreprise à moins de vouloir des pannes split‑DNS et des soucis de conformité.

Fix #4: Trim search domains (reduce query multiplication)

Les search domains peuvent provoquer plusieurs requêtes pour un seul nom : server devient server.corp.example,
puis server.lab.example, etc. Quand les résolveurs sont lents, cela multiplie la douleur.

Décision : Préférez les FQDN dans les configs et configurez le mappage du nom de la machine pour qu’il ne dépende pas du search.
Si vous gérez le DHCP, gardez la liste de search courte et intentionnelle.

Fix #5: Reorder NSS lookups so “files” wins quickly

La ligne hosts: dans /etc/nsswitch.conf décide de l’ordre des recherches.
Pour les serveurs, je veux files en premier, dns en second, et mDNS uniquement si nécessaire.

cr0x@server:~$ grep -E '^\s*hosts:' /etc/nsswitch.conf
hosts:          files mdns4_minimal [NOTFOUND=return] dns

Si mDNS est impliqué, un modèle serveur plus sûr est souvent :

cr0x@server:~$ sudo sed -i 's/^hosts:.*/hosts:          files dns/' /etc/nsswitch.conf

Décision : Ne faites cela que si vous comprenez l’environnement. Sur des postes de travail, supprimer mDNS peut casser la découverte «ça apparaît tout seul».
Sur des serveurs, cela enlève généralement du poids mort.

Fix #6: Handle reverse DNS properly (PTR records or local mapping)

Un reverse DNS incorrect est courant et tolérable—jusqu’à ce qu’une politique de sécurité ou un chemin de journalisation bloque dessus.
La correction propre est de créer des enregistrements PTR pour les IP des serveurs dans le DNS autoritatif.
Le correctif tactique est d’assurer que l’IP propre du serveur reverse‑résout localement via /etc/hosts.

Orientation d’opinion : si vous gérez la zone DNS, faites des PTR. Ce n’est pas une hygiène optionnelle, c’est une dette opérationnelle avec intérêts.

Fix #7: Beware of “quick fixes” that hide symptoms

Vous verrez des conseils comme «désactiver les recherches DNS dans sudo» ou modifier la journalisation.
Parfois ces changements aident. Le plus souvent ils détériorent votre piste d’audit tout en laissant le DNS cassé pour tout le reste.
N’utilisez-les que si vous avez une raison mesurée et un enregistrement de changement.

Blague n°2 : Désactiver le DNS pour corriger la latence DNS, c’est comme supprimer votre compteur pour améliorer la consommation d’essence. Vous vous sentirez mieux brièvement.

Trois mini-récits d’entreprise (anonymisés, plausibles, techniquement exacts)

1) L’incident causé par une fausse hypothèse : «Notre DNS est toujours accessible»

Une équipe exploitait une flotte de VM Ubuntu sur deux zones réseau : serveurs applicatifs dans une zone, services partagés (dont DNS) dans l’autre.
Lors d’une revue de sécurité, les règles de pare-feu ont été durcies. Le DNS était «autorisé», mais seulement depuis des sous‑réseaux listés dans un tableur qui était—comment dire—optimiste.

Le premier symptôme n’était pas une panne d’appli. C’était des humains qui se plaignaient dans le chat que sudo «bloque parfois».
L’astreint a écarté ça comme des problèmes de portables et de VPN. Puis une fenêtre de mise à jour régulière a démarré, et l’automatisation qui utilisait sudo a commencé à expirer.
Là le problème est passé d’ennui à incident.

La fausse hypothèse : «Si SSH marche, le DNS doit marcher.» SSH fonctionnait parce que les routes IP étaient correctes et que les hôtes étaient épinglés dans known_hosts.
Le DNS ne fonctionnait pas parce que le pare‑feu laissait tomber UDP/53 silencieusement, ce qui se traduit par «attendre le timeout, puis réessayer».

Corriger le pare‑feu était nécessaire, mais la solution durable a été d’ajouter des mappages de nom d’hôte locaux dans /etc/hosts via la gestion de configuration.
Cela a rendu la résolution d’identité locale, donc même si le DNS vacillait, les actions d’administration ne bloquaient pas.

Après l’incident, ils ont aussi ajouté un contrôle de santé : latence de getent hosts $(hostname) mesurée et alertée.
Un métrique ennuyeux. Extrêmement efficace.

2) L’optimisation qui s’est retournée contre eux : «Ajoutons plus de search domains»

Une équipe réseau d’entreprise a voulu faciliter l’expérience développeur en poussant une généreuse liste de search via DHCP :
plusieurs domaines internes pour que les gens puissent taper des noms courts et que ça «marche tout seul».
Ça semblait anodin. Et ça fonctionnait—quand le DNS était rapide.

Puis un bureau distant a eu une perte de paquets intermittente vers les résolveurs DNS principaux.
Chaque recherche non qualifiée (comme server) est devenue une série de tentatives : server.corp, server.lab, server.dev, etc.
Multipliez ça par les timeouts et les retries, et soudain des commandes triviales prenaient des secondes.

Les ingénieurs l’ont remarqué d’abord dans des outils qui appellent NSS de façon répétée : sudo, ssh avec tentatives GSSAPI,
et des agents de monitoring faisant des recherches inverses pour le tagging.
L’«optimisation» de l’équipe réseau avait créé un amplificateur de latence.

Revenir sur la liste de search a aidé, mais la vraie réparation a été un nommage plus discipliné :
les systèmes critiques utilisaient des FQDN dans les configs, et les hôtes épinglaient leur propre nom localement.
Les noms courts restaient permis en shells interactifs, mais l’automatisation de production a cessé de dépendre de la magie du search.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : /etc/hosts standardisé

Une autre entreprise avait une baseline stricte : chaque hôte Linux avait une entrée /etc/hosts pour son propre nom,
gérée par la gestion de configuration et revue comme tout autre changement.
Les gens se plaignaient car cela semblait redondant avec le DNS.

Lors d’une migration DNS planifiée, les résolveurs ont été permutés et les caches vidés.
Quelques zones ont été plus lentes pendant quelques heures à cause de la propagation et de quelques forwarders mal configurés.
Les développeurs se sont plaints que «le DNS est lent», mais le travail opérationnel sur les serveurs s’est poursuivi sans drame.

La raison : les workflows d’administration n’avaient pas besoin du DNS pour l’identité locale.
sudo, les tags de logs locaux, et de nombreux scripts utilisant hostname -f ne bloquaient pas car l’hôte pouvait répondre «qui suis‑je ?»
depuis des fichiers locaux instantanément.

Cela n’a pas éliminé le problème DNS. Ça l’a contenu.
C’est le but des baselines ennuyeuses : elles n’empêchent pas tous les incendies, mais elles empêchent que le feu se propage dans des pièces sans rapport.

Erreurs courantes : symptômes → cause racine → correctif

1) Symptom: sudo pauses ~2–5 seconds before password prompt

Cause racine : Les serveurs DNS dans la config de résolveur sont inaccessibles ; libc attend le timeout.

Correctif : Corriger la liste des serveurs DNS (DHCP/VPN/netplan), et ajouter le mappage du nom d’hôte dans /etc/hosts comme garde‑fou.

2) Symptom: sudo is fast on one network, slow on another

Cause racine : Split DNS / VPN modifie les résolveurs ou les search domains ; les requêtes vont vers un résolveur lent depuis cet emplacement.

Correctif : Mesurez avec resolvectl status et dig @server direct. Corrigez le profil VPN ou le routage DNS ; évitez les longues listes de search.

3) Symptom: getent hosts $(hostname) hangs, but dig works

Cause racine : L’ordre NSS utilise une source lente (mDNS, LDAP/SSSD) avant DNS ; dig contourne NSS.

Correctif : Ajustez /etc/nsswitch.conf pour préférer files, puis dns. Confirmez avec getent chronométré.

4) Symptom: hostname -f is slow; sudo is slow; logs show FQDN lookups

Cause racine : Incohérence nom/FQDN plus parcours de search domain ; reverse DNS absent, provoquant des recherches supplémentaires.

Correctif : Assurez une stratégie de nom d’hôte cohérente et une entrée correspondante dans /etc/hosts ; ajoutez des enregistrements PTR si vous gérez le DNS.

5) Symptom: sudo slow only when domain controllers are unreachable

Cause racine : Les délais SSSD/AD influencent les chemins de résolution NSS/PAM.

Correctif : Confirmez avec systemctl is-active sssd et des getent chronométrés. Corrigez le basculement/les timeouts SSSD, et gardez la résolution locale dans files.

6) Symptom: sudo delay appears after enabling Avahi or “desktop features” on a server

Cause racine : mDNS est testé et expire ou est filtré, ajoutant du délai aux recherches.

Correctif : Supprimez/désactivez mDNS sur les serveurs ou réordonnez NSS pour éviter mDNS sur des recherches non‑.local.

7) Symptom: sudo slow only on IPv6-enabled networks

Cause racine : Les serveurs DNS IPv6 ou les routes sont mal configurés ; le résolveur tente AAAA puis A avec des délais.

Correctif : Vérifiez resolvectl status pour les résolveurs v6 et testez avec dig -6. Corrigez les routes ou désactivez les résolveurs v6 défaillants ; conservez le mappage local du nom d’hôte.

8) Symptom: “sudo: unable to resolve host …” plus slowness

Cause racine : Le nom d’hôte ne se résout pas du tout via NSS ; sudo se plaint et attend sur un fallback lent.

Correctif : Ajoutez l’entrée correcte dans /etc/hosts pour le nom d’hôte ; vérifiez avec getent hosts $(hostname).

Listes de contrôle / plan pas à pas

Checklist A: One-host surgical fix (10 minutes, no meetings)

1. Mesurez le délai :

   cr0x@server:~$ time sudo -n true
   sudo: a password is required
   
   real    0m2.101s
   user    0m0.008s
   sys     0m0.010s

   Décision : Si le temps réel est de l’ordre de secondes avec un CPU minime, passez aux vérifications de résolution de nom.

2. Chronométrez la recherche NSS du nom d’hôte :

   cr0x@server:~$ /usr/bin/time -f '%e seconds' getent hosts $(hostname)
   2.00 seconds
   10.22.1.17      server.corp.example server

   Décision : Si c’est lent, corriger la résolution du nom d’hôte résoudra probablement sudo.

3. Ajoutez le mappage du nom d’hôte si manquant :

   cr0x@server:~$ sudo grep -nE '127\.0\.1\.1|127\.0\.0\.1' /etc/hosts
   1:127.0.0.1       localhost

   cr0x@server:~$ sudoedit /etc/hosts

   Décision : Ajoutez 127.0.1.1 server.corp.example server (ou vos noms réels). Enregistrez.

4. Retestez :

   cr0x@server:~$ /usr/bin/time -f '%e seconds' getent hosts $(hostname)
   0.00 seconds
   127.0.1.1       server.corp.example server

   cr0x@server:~$ time sudo -n true
   
   real    0m0.050s
   user    0m0.008s
   sys     0m0.012s

   Décision : Si c’est corrigé, stop. Vous pouvez maintenant traiter la cause DNS en amont sans gêne utilisateur.

Checklist B: Fleet-level fix (the one you wish you’d done earlier)

1. Standardiser l’identité des hôtes : décider politique nom court vs FQDN.
2. Appliquer une baseline /etc/hosts : mappage local pour le nom d’hôte et (si utilisé) le FQDN.
3. Définir l’ordre NSS intentionnellement : hosts: files dns pour les serveurs sauf besoin documenté contraire.
4. Surveiller la latence des recherches : alerter sur getent hosts $(hostname) prenant > 200ms soutenu.
5. Corriger les enregistrements PTR pour les sous‑réseaux serveur si vous gérez le DNS. Évitez la mythologie «reverse DNS optionnel».
6. Tester les changements VPN/DHCP sur un hôte canari en chronométrant les recherches NSS et sudo.

Checklist C: If you must change DNS configuration

1. Confirmer qui gère les résolveurs (équipe réseau, plateforme, fournisseur cloud).
2. Vérifier l’accessibilité (UDP et TCP 53) depuis le sous‑réseau affecté.
3. Garder la liste des résolveurs courte (2–3 serveurs) et locale à la région réseau.
4. Éviter les longues listes de search domains ; considérez‑les comme des multiplicateurs d’échec.
5. Déployer progressivement et mesurer la latence NSS, pas seulement «dig marche».

FAQ

Pourquoi sudo se soucie du DNS ?

Parce que c’est un outil de politique/audit, pas un simple basculeur de privilèges. Il peut résoudre des noms d’hôte pour la journalisation, le contexte de politique, ou les vérifications d’identité via NSS.
Si NSS heurte le DNS et que le DNS est lent, sudo hérite de ce délai.

Pourquoi dig semble rapide mais sudo est lent ?

dig interroge le DNS directement. sudo utilise la résolution de nom libc via NSS, qui peut consulter files, mDNS, SSSD/LDAP, puis DNS—dans cet ordre.
Vous devez mesurer avec getent, pas seulement dig.

Ajouter le nom d’hôte dans /etc/hosts est-ce «mauvaise pratique» ?

Pour l’auto‑résolution locale, c’est une bonne pratique. Vous ne remplacez pas le DNS pour la découverte de services ; vous permettez à la machine de s’identifier sans le réseau.
Cela réduit le rayon d’impact des problèmes DNS.

Faut‑il utiliser 127.0.1.1 ou 127.0.0.1 ?

Sur Ubuntu, 127.0.1.1 est une convention courante pour mapper le nom de l’hôte sans détourner localhost.
L’un ou l’autre peut fonctionner, mais gardez localhost propre et évitez de mapper plusieurs noms non liés vers 127.0.0.1 sans précaution.

Et si l’IP «réelle» du serveur doit être dans le DNS, pas en loopback ?

Mettez la vraie IP dans le DNS (A/AAAA) et PTR en reverse DNS. Gardez quand même un mappage loopback pour le nom d’hôte si votre environnement le tolère,
ou mappez le nom d’hôte à l’IP primaire dans /etc/hosts si vous devez refléter la réalité. L’objectif est une résolution rapide et cohérente.

systemd-resolved cause‑t‑il ce problème ?

systemd-resolved est souvent le messager. Il peut révéler des listes de résolveurs en amont incorrectes, du DNS poussé par VPN, ou des nameservers inaccessibles.
Utilisez resolvectl status pour voir ce qu’il fait réellement avant de le blâmer.

L’IPv6 peut‑elle être la cause du délai ?

Oui. Si votre configuration de résolveur inclut des chemins IPv6 cassés ou des serveurs DNS IPv6 inaccessibles, les recherches peuvent temporiser avant de retomber.
Mesurez avec resolvectl et testez la reachabilité v6 ; ne désactivez pas IPv6 aveuglément sauf si vous maîtrisez l’environnement et acceptez les compromis.

Est‑il sûr d’éditer /etc/nsswitch.conf pour retirer mDNS ?

Sur les serveurs, généralement oui si vous ne dépendez pas de la découverte .local. Sur des postes de travail, retirer mDNS peut casser la découverte de périphériques.
Faites le changement intentionnellement et vérifiez avec des appels getent hosts chronométrés.

Quelle est la preuve la plus rapide que le DNS est le goulot d’étranglement ?

Chronométrez getent hosts $(hostname) et lancez strace sur sudo en cherchant des timeouts sur les sockets DNS.
Si la résolution NSS prend des secondes, sudo n’est pas le problème—c’est le service de noms.

Pourquoi ça empire sur le VPN ?

Les VPN poussent souvent des serveurs DNS internes et de longues listes de search domains. Si le chemin VPN est instable ou les résolveurs inaccessibles depuis votre emplacement actuel,
chaque recherche devient une chaîne de timeouts. Corrigez le profil DNS du VPN ou assurez la résolution locale du nom d’hôte via /etc/hosts.

Étapes suivantes

Si sudo est lent sur Ubuntu 24.04, traitez‑le comme un problème de dépendance, pas un problème de sudo.
Mesurez avec time, prouvez avec strace, validez avec getent.
Ensuite, rendez le chemin rapide local : mappez votre nom d’hôte dans /etc/hosts et assurez‑vous que files est en premier dans les recherches d’hôtes.

Après cela, corrigez la cause réelle : résolveurs inaccessibles, DNS surchargé, search domains absurdes, enregistrements PTR manquants, ou services de noms d’entreprise qui expirent.
Faites‑le calmement, avec des métriques, et avec un hôte canari. Votre futur vous se plaindra toujours du DNS, mais au moins vous n’attendrez plus pour taper un mot de passe.