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

Ce que « sudo lent » signifie généralement (et ce que ce n’est pas)

Quand sudo est lent, ce n’est que rarement parce que « sudo est lourd ». Le plus souvent, sudo appelle la pile de services de noms du système — les modules NSS de glibc — puis attend sur un chemin de résolveur dont vous ne saviez pas qu’il était essentiel.

Le schéma classique sur Ubuntu 24.04 :

• Le délai survient avant l’invite du mot de passe : recherche/initialisation (nom d’hôte, NSS, PAM, DNS, SSSD, LDAP, Kerberos, etc.).
• Le délai survient après la saisie du mot de passe : authentification d’annuaire, modules PAM, répertoires réseau, recherches de groupes ou cibles de journalisation.
• Le délai est de 5 secondes : ressemble fortement à une fenêtre d’expiration d’un timeout DNS unique ou à un chemin de secours qui attend son expiration.
• Le délai est de 10/15/20 secondes : plusieurs résolveurs interrogés en séquence, ou timeouts pour A et AAAA, ou des tentatives répétées.

Autre point : ne perdez pas de temps à blâmer le CPU, le disque ou « snap ». Si la machine répond autrement et que seule l’élévation de privilèges est lente, vous êtes dans le domaine de la résolution de noms et des recherches d’identité.

Une vérité opérationnelle : sudo est un test de fiabilité. Si la résolution de noms est instable, sudo vous le fera sentir en devenant agaçant.

Blague #1 : Le DNS est la dépendance que tout le monde oublie jusqu’à sa panne. Ensuite, il devient la personnalité entière de chacun.

Guide de diagnostic rapide

Si vous êtes d’astreinte ou connecté en SSH pendant une fenêtre de changement, vous n’avez pas besoin d’un tour philosophique des résolveurs. Vous avez besoin d’une séquence qui trouve le goulot en quelques minutes.

Première étape : confirmez que c’est la résolution de noms et non PAM/auth

1. Mesurez le temps de sudo et comparez avec sudo -n true.
2. Testez sudo avec un environnement propre.
3. Surveillez les appels de résolution de noms avec strace (rapide et définitif).

Deuxième étape : vérifiez le nom d’hôte et la résolution locale

1. Vérifiez que /etc/hostname correspond à hostnamectl.
2. Assurez-vous que /etc/hosts mappe 127.0.1.1 (ou 127.0.0.1) vers votre nom d’hôte/FQDN de façon cohérente.
3. Confirmez que getent hosts $(hostname) répond instantanément.

Troisième étape : validez le chemin du résolveur et la joignabilité des serveurs DNS

1. Inspectez resolvectl status, /etc/resolv.conf (symlink) et les domaines de recherche.
2. Interrogez votre nom d’hôte en forward et reverse avec resolvectl query et dig.
3. Recherchez des timeouts dans journalctl -u systemd-resolved.

Arrêtez-vous quand vous avez la preuve évidente

Vous n’essayez pas d’« améliorer le DNS ». Vous supprimez un timeout déterministe sur un chemin critique. Corrigez ce qui est lent ; laissez le reste tranquille.

Faits intéressants et contexte (les parties qu’on oublie)

• Fait 1 : sudo résout souvent le nom d’hôte local pour enregistrer « où la commande a été exécutée », et certaines configurations résolvent aussi l’utilisateur et les groupes via NSS.
• Fait 2 : Sur Debian/Ubuntu, 127.0.1.1 dans /etc/hosts est une convention ancienne pour mapper le nom d’hôte local sur des systèmes non purement loopback, surtout quand l’IP réelle peut changer (portables, DHCP).
• Fait 3 : Le NSS de glibc (Name Service Switch) est modulaire et dépend de l’ordre. Un module lent (DNS, mdns, sss) dans la chaîne peut bloquer tout appel à getaddrinfo().
• Fait 4 : systemd-resolved a introduit le DNS partagé et le routage des requêtes par lien ; idéal pour les VPN, mais aussi révélateur de domaines de recherche mal configurés.
• Fait 5 : Les recherches DNS inverses (enregistrements PTR) sont souvent absentes dans les réseaux d’entreprise — surtout pour des plages de postes de travail — pourtant de nombreux systèmes les sollicitent pour la journalisation ou la politique.
• Fait 6 : Une requête AAAA (IPv6) peut introduire des délais sur des réseaux IPv4 seuls si le résolveur tente le v6 en premier et attend des timeouts au lieu d’un NXDOMAIN rapide.
• Fait 7 : mDNS (.local via Avahi) et DNS peuvent interagir mal si vos choix de nom d’hôte ou de domaine de recherche sont imprudents ; « local » est une zone spéciale dans de nombreux environnements.
• Fait 8 : Une liste de domaines de recherche trop longue peut multiplier les requêtes : chaque recherche d’un nom court est étendue en plusieurs tentatives FQDN.
• Fait 9 : La « pause de cinq secondes » n’est souvent pas aléatoire : c’est un timeout de résolveur par défaut que vous pouvez littéralement compter.

Une idée paraphrasée qui devrait être imprimée à l’intérieur de chaque carnet d’opérations : paraphrased idea de Gene Kim : la fiabilité vient de la réduction des transferts et des dépendances cachées — surtout celles qui expirent.

Mesurez correctement : faites avouer le délai

Avant de modifier quoi que ce soit, mesurez. Pas parce que nous aimons les tableaux, mais parce que « ça semble plus rapide » est la façon dont on finit avec un tas de configurations que personne ne comprend.

Ce que vous voulez :

• La durée exacte du délai.
• Si le délai est avant ou après le mot de passe.
• Si cela correspond aux timeouts DNS (5s, 10s, etc.).
• Quel appel système bloque (généralement connect() vers un serveur DNS, ou des lectures en attente).

Causes profondes : DNS, nom d’hôte, NSS et alliés

1) Nom d’hôte non résolvable localement

La machine connaît son nom d’hôte, mais ne peut pas le résoudre rapidement en adresse. Les programmes qui font un simple « quel est mon nom ? » suivi de « quelle est mon adresse ? » tombent dans le DNS, qui finit par des timeouts.

La solution habituelle d’Ubuntu : assurez-vous que /etc/hosts contient une entrée pour le nom d’hôte (et éventuellement le FQDN) sur le loopback. L’objectif est la rapidité et la détermination, pas l’élégance.

2) Serveur DNS inaccessible (ou DNS par lien erroné)

Votre résolveur pointe vers des serveurs DNS inaccessibles depuis cet hôte (DNS VPN obsolète, DNS de bureau ancien, réseau de laboratoire mort). Chaque recherche attend des timeouts avant de retomber.

3) Domaines de recherche trop ambitieux

Les domaines de recherche sont pratiques — jusqu’à ce qu’ils deviennent un multiplicateur de requêtes. Une recherche d’un nom simple comme myhost peut devenir :

• myhost.corp.example
• myhost.dev.example
• myhost.example
• …puis peut-être le nom nu

Si chaque étape timeoute, vous avez construit un générateur de délais. La solution est de réduire les domaines de recherche ou d’utiliser des FQDN quand c’est important.

4) L’ordre NSS fait intervenir des fournisseurs d’identité réseau lents

Si /etc/nsswitch.conf indique « consulter SSSD/LDAP/DNS pour tout », alors même les recherches utilisateur/groupe locales peuvent bloquer. sudo vérifie fréquemment les appartenances aux groupes et l’identité utilisateur. C’est normal. Le faire via un chemin réseau cassé ne l’est pas.

5) DNS inverse et hypothèses de journalisation

Certains environnements utilisent le DNS inverse pour l’audit. D’autres déclenchent accidentellement des recherches inverses à cause de la façon dont les noms d’hôtes sont résolus ou journalisés. Les enregistrements PTR manquants ne sont pas fatals, mais les timeouts le sont.

6) Discordance IPv6 et timeouts AAAA

Si votre réseau bloque les paquets IPv6 ou empêche le transport DNS v6, les recherches AAAA peuvent échouer lentement. Vous pouvez réparer le réseau, désactiver IPv6 cassé ou ajuster le comportement du résolveur. Le choix correct dépend de si IPv6 est volontairement pris en charge.

Blague #2 : Si vous voulez vous sentir puissant, corrigez un timeout DNS et regardez une plainte « Linux lent » disparaître en moins d’une seconde.

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

Ce sont des commandes réelles que vous pouvez exécuter sur Ubuntu 24.04. Chaque tâche indique quoi surveiller et la décision à prendre.

Task 1: Time the pain

cr0x@server:~$ time sudo -v

real    0m5.214s
user    0m0.012s
sys     0m0.020s

Ce que cela signifie : environ 5,2s de temps mur avec un CPU négligeable suggère une attente d’E/S (souvent DNS).

Décision : Traitez-le comme une latence de dépendance externe, pas comme une charge système. Passez aux vérifications du nom d’hôte/DNS.

Task 2: Separate auth from lookup with non-interactive sudo

cr0x@server:~$ time sudo -n true

real    0m5.108s
user    0m0.004s
sys     0m0.006s

Ce que cela signifie : Toujours lent même sans invite. Ce n’est pas un « délai de frappe humaine » ni la gestion du mot de passe PAM.

Décision : Concentrez-vous sur l’initialisation pré-auth : résolution de nom d’hôte, NSS, résolveur, recherches sudoers.

Task 3: Check if the delay is tied to hostname resolution

cr0x@server:~$ hostname
app-node-7

cr0x@server:~$ time getent hosts $(hostname)
10.10.40.77     app-node-7.corp.example app-node-7

real    0m5.014s
user    0m0.003s
sys     0m0.006s

Ce que cela signifie : getent est aussi lent. Ce n’est pas spécifique à sudo ; c’est le service de noms.

Décision : Corrigez le chemin NSS/DNS. Sudo s’améliorera en conséquence.

Task 4: Verify local hostname mapping in /etc/hosts

cr0x@server:~$ grep -nE '^(127\.0\.0\.1|127\.0\.1\.1)' /etc/hosts
1:127.0.0.1 localhost
2:127.0.1.1 ubuntu

Ce que cela signifie : Le nom d’hôte est app-node-7, mais 127.0.1.1 est mappé sur ubuntu. Ce décalage déclenche souvent des recherches DNS pour le nom d’hôte réel.

Décision : Mettez à jour /etc/hosts pour mapper 127.0.1.1 vers votre vrai nom d’hôte (et éventuellement le FQDN).

Task 5: Confirm what the system thinks its hostname is

cr0x@server:~$ hostnamectl status
 Static hostname: app-node-7
       Icon name: computer-vm
         Chassis: vm
      Machine ID: 7c9d6e4f9c3d4c3a9d3b9d5d8c0c0e1a
         Boot ID: 2a4f4d8a0d824d1c9c4f2a1a7a3d8a9b
  Operating System: Ubuntu 24.04.1 LTS
            Kernel: Linux 6.8.0-41-generic
      Architecture: x86-64

Ce que cela signifie : Le nom d’hôte statique est correctement défini. Le décalage est probablement dans la résolution locale, le DNS ou les deux.

Décision : Ne changez pas le nom d’hôte juste pour corriger la résolution ; corrigez le mapping.

Task 6: Inspect NSS order (this is where delays hide)

cr0x@server:~$ grep -nE '^(hosts|passwd|group):' /etc/nsswitch.conf
8:passwd:         files systemd sss
9:group:          files systemd sss
12:hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname

Ce que cela signifie : La recherche des hosts essaie files, puis mDNS minimal, puis DNS, puis myhostname. Cet ordre peut forcer des recherches réseau avant le raccourci local.

Décision : Envisagez de déplacer myhostname plus tôt, ou assurez-vous que /etc/hosts est correct pour que files résolve instantanément.

Task 7: Confirm systemd-resolved is in play and what DNS it uses

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

Link 2 (ens18)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54
        DNS Domain: corp.example

Ce que cela signifie : Le système utilise le mode stub resolver et pointe vers des serveurs DNS d’entreprise.

Décision : Si ces serveurs ne sont pas joignables depuis cet hôte/segment réseau, corrigez l’affectation netplan/VPN DNS ou définissez des DNS par lien corrects.

Task 8: Check the /etc/resolv.conf symlink and contents

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Oct 10 09:12 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

cr0x@server:~$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search corp.example

Ce que cela signifie : Les requêtes vont au stub local 127.0.0.53, puis systemd-resolved relaie vers les DNS en amont configurés.

Décision : Déboguez la joignabilité et les timeouts en amont via les logs de resolved et des requêtes directes.

Task 9: Query your hostname via resolved and watch latency

cr0x@server:~$ time resolvectl query $(hostname)
app-node-7: 10.10.40.77                          -- link: ens18

-- Information acquired via protocol DNS in 5.0062s.
-- Data is authenticated: no

Ce que cela signifie : Le résolveur a mis ~5 secondes pour répondre. C’est le même délai que vous voyez avec sudo.

Décision : Confirmez pourquoi le DNS en amont est lent : serveur injoignable, firewall, route erronée, domaines de recherche cassés ou timeouts de reverse lookup.

Task 10: Look for resolved timeouts in journald

cr0x@server:~$ sudo journalctl -u systemd-resolved --since "10 min ago" | tail -n 30
Oct 10 09:55:11 server systemd-resolved[812]: Sending query via TCP since UDP failed.
Oct 10 09:55:16 server systemd-resolved[812]: DNS server 10.10.0.53 unreachable, trying next.
Oct 10 09:55:21 server systemd-resolved[812]: DNS server 10.10.0.54 unreachable, trying next.
Oct 10 09:55:21 server systemd-resolved[812]: Using degraded feature set UDP instead of TCP for DNS server 10.10.0.53.

Ce que cela signifie : Les serveurs DNS en amont sont injoignables. Resolved parcourt les serveurs et les modes de transport, ce qui consomme du temps.

Décision : Corrigez le routage/firewall/VPN, ou changez les serveurs DNS pour ce lien vers des serveurs joignables. Ne « tunez les timeouts » qu’en dernier recours.

Task 11: Prove network reachability to DNS servers

cr0x@server:~$ ping -c 2 10.10.0.53
PING 10.10.0.53 (10.10.0.53) 56(84) bytes of data.

--- 10.10.0.53 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1014ms

cr0x@server:~$ nc -vz -w2 10.10.0.53 53
nc: connect to 10.10.0.53 port 53 (tcp) timed out: Operation now in progress

Ce que cela signifie : Pas de réponse ICMP et TCP/53 timeout. Même si l’ICMP est bloqué, un timeout TCP/53 est un fort signal.

Décision : Confirmez les IP DNS correctes pour ce sous-réseau/VPC ; corrigez les règles de sécurité/firewall ; ou définissez des résolveurs alternatifs joignables.

Task 12: Watch sudo itself with strace (fast, brutal truth)

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

cr0x@server:~$ tail -n 25 /tmp/sudo.trace
12:01:10.102345 connect(7, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
12:01:10.102612 sendto(7, "\244\243\1\0\0\1\0\0\0\0\0\0\10app-node-7\4corp\7example\0\0\1\0\1", 40, MSG_NOSIGNAL, NULL, 0) = 40
12:01:15.110991 recvfrom(7, 0x7ffd3b0d9a40, 2048, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
12:01:15.111244 close(7) = 0

Ce que cela signifie : Le blocage est une requête DNS via le stub local. Vous voyez un écart d’environ 5 secondes avant que recvfrom n’expire.

Décision : Arrêtez les débats. Corrigez la joignabilité DNS ou le mapping local du nom d’hôte pour que sudo n’ait pas besoin du DNS pour lui-même.

Task 13: Validate forward and reverse DNS explicitly

cr0x@server:~$ dig +time=2 +tries=1 app-node-7.corp.example A

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +time=2 +tries=1 app-node-7.corp.example A
;; connection timed out; no servers could be reached

cr0x@server:~$ dig +time=2 +tries=1 -x 10.10.40.77 PTR

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +time=2 +tries=1 -x 10.10.40.77 PTR
;; connection timed out; no servers could be reached

Ce que cela signifie : Le DNS est totalement injoignable. Le DNS inverse est mort aussi, mais c’est un symptôme du même problème de joignabilité.

Décision : Corrigez la sélection DNS en amont et le chemin réseau ; ne palliez pas avec des options timeout: aléatoires sauf en mode urgence.

Task 14: Confirm netplan DNS configuration (common after upgrades/templates)

cr0x@server:~$ sudo netplan get
network:
  ethernets:
    ens18:
      addresses:
      - 10.10.40.77/24
      gateway4: 10.10.40.1
      nameservers:
        addresses:
        - 10.10.0.53
        - 10.10.0.54
        search:
        - corp.example
  version: 2

Ce que cela signifie : Netplan définit explicitement des serveurs DNS. Si ceux-ci ne sont pas joignables depuis ce réseau, c’est un bug de configuration, pas un incident passager.

Décision : Changez les nameservers pour ceux corrects pour cet environnement (ou supprimez les overrides si le DHCP doit les fournir).

Task 15: Quick containment test: add hostname to /etc/hosts

cr0x@server:~$ sudoedit /etc/hosts

cr0x@server:~$ grep -n '127.0.1.1' /etc/hosts
2:127.0.1.1 app-node-7.corp.example app-node-7

cr0x@server:~$ time sudo -n true

real    0m0.085s
user    0m0.004s
sys     0m0.008s

Ce que cela signifie : Le délai disparaît. Vous avez contourné le DNS pour le chemin de résolution du nom d’hôte local.

Décision : Conservez ce correctif même après avoir réparé le DNS. Le mapping local est une assurance peu coûteuse contre de futures bizarreries DNS.

Task 16: If SSSD/LDAP is involved, test identity lookup latency

cr0x@server:~$ time id $USER
uid=1001(cr0x) gid=1001(cr0x) groups=1001(cr0x),27(sudo),1002(devops)

real    0m4.932s
user    0m0.000s
sys     0m0.008s

Ce que cela signifie : Même id est lent. C’est NSS (possiblement SSSD) qui attend un fournisseur d’identité réseau.

Décision : Vérifiez l’état de SSSD et la joignabilité de l’annuaire en amont ; envisagez de privilégier les comptes locaux files-first et assurez-vous que les fournisseurs d’annuaire sont sains.

Correctifs efficaces (et pourquoi)

Fix 1: Make the hostname resolvable locally (the boring, correct move)

Placez votre nom d’hôte dans /etc/hosts. Oui, même si vous avez le DNS. Oui, même si vous êtes « cloud native ». Il s’agit de supprimer une dépendance réseau du chemin local d’élévation de privilèges.

Modèle recommandé sur Ubuntu :

• 127.0.0.1 localhost
• 127.0.1.1 yourhost.yourdomain yourhost

Pourquoi cela fonctionne : NSS vérifie généralement files en premier. Cela résout instantanément et ne touche jamais au DNS.

Fix 2: Correct DNS servers for the actual network you’re on

Si vous pointez vers des serveurs DNS derrière un VPN auquel vous n’êtes pas connecté, ou dans un VPC différent, vous êtes assuré d’obtenir des timeouts. Corrigez l’affectation DNS à la source :

• Config statique Netplan : définissez des nameservers joignables.
• DHCP : assurez-vous que l’option DHCP fournit les bons serveurs DNS pour ce sous-réseau.
• VPN split DNS : assurez-vous que le DNS par lien est défini seulement quand le VPN est actif.

Fix 3: Reduce search domains (and stop single-label lookups in scripts)

Une longue liste de recherche est un auto-effet multiplicateur de requêtes. Si vous avez hérité d’une liste avec cinq suffixes, réduisez-la. Si vous ne pouvez pas, alors arrêtez d’utiliser des noms d’hôte courts dans l’automatisation. Utilisez des FQDN dans les scripts et la configuration.

Fix 4: Clean up /etc/nsswitch.conf ordering (with restraint)

Soyez prudent : les changements NSS peuvent avoir des effets étendus. Mais dans des environnements avec des besoins locaux prévisibles, vous pouvez réordonner hosts: pour éviter les modules lents.

Objectifs typiques assez sûrs :

• Assurez-vous que files est en premier.
• Assurez-vous que myhostname n’est pas dernier si vous en dépendez.
• Évitez mDNS à moins de réellement l’utiliser.

Si votre flotte dépend de mDNS pour des portables de développeurs, d’accord. Sur des serveurs ? Habituellement non.

Fix 5: If reverse DNS is required, make PTR records real

Si les outils de sécurité/audit attendent des recherches PTR, alors l’absence de PTR est un défaut, pas une excuse. Ajoutez des PTR pour les IP des serveurs. Faites correspondre forward et reverse. Vos futurs rapports d’incident seront plus courts et moins hostiles.

Fix 6: Handle IPv6 honestly (don’t half-support it)

Si IPv6 est pris en charge, assurez-vous que DNS et routage fonctionnent bout à bout. Si ce n’est pas le cas, désactivez-le de façon cohérente (ou au moins empêchez le résolveur de poursuivre des chemins cassés). L’IPv6 à moitié supporté est une source fiable de délais intermittents que personne ne reproduit en labo.

Trois mini-récits du monde de l’entreprise

Mini-story #1: The incident caused by a wrong assumption

Ils venaient de migrer un ensemble de runners de build internes d’un segment réseau à un autre. L’équipe a supposé « le DNS est universel », parce que le nouveau segment avait un accès sortant et pouvait résoudre des domaines publics.

Tout avait l’air en ordre jusqu’au premier jour de patch. Les ingénieurs se sont connectés en SSH, ont lancé sudo apt-get et ont attendu. La pause était constante — environ cinq secondes — sur chaque commande privilégiée. On a commencé à blâmer le nouveau kernel, l’agent EDR, et une personne a même suggéré « Ubuntu 24.04 est juste plus lourd ».

Le vrai problème était simple et discrètement humiliant : le template netplan avait codé en dur des serveurs DNS qui n’étaient joignables que depuis l’ancien segment. Le DNS public fonctionnait via un forwarder local, mais les zones internes non. Et les noms d’hôtes étaient internes.

Une fois que quelqu’un a chronométré getent hosts $(hostname) et vu le même blocage, le mystère a disparu. Ils ont remplacé la liste de serveurs DNS par les résolveurs corrects par segment et ajouté le nom d’hôte dans /etc/hosts comme garde-fou.

Deux leçons sont restées : « le DNS public fonctionne » n’est pas « le DNS fonctionne » et « ça n’affecte que sudo » est souvent « ça affecte la résolution de noms sur un chemin critique ».

Mini-story #2: The optimization that backfired

Une équipe plateforme voulait une « identité d’hôte plus propre ». Ils ont supprimé les entrées 127.0.1.1 de /etc/hosts via la gestion de configuration, affirmant que le DNS devait être la source de vérité. Techniquement juste à court terme et opérationnellement faux à grande échelle.

Pendant un temps, rien de grave ne s’est produit. Puis une fenêtre de maintenance DNS temporaire a touché une région. Pas une panne totale — juste une latence plus élevée et des timeouts occasionnels. Soudain, chaque action privilégiée sur des centaines d’instances est devenue collante. Les délais sudo ont entraîné des déploiements plus lents, une réponse aux incidents plus lente et un sentiment général que la région était hantée.

L’« optimisation » a aussi créé un piège de débogage. Comme le DNS finissait par fonctionner, le problème semblait intermittent. Ce n’était pas le cas. C’était le comportement déterministe du résolveur sous une latence amont transitoire.

Ils ont fait marche arrière : nom d’hôte dans /etc/hosts, DNS toujours autoritaire pour la découverte de services, et surveillance stricte de la latence DNS. Personne n’a dit qu’ils « revenaient en arrière », car il s’agissait vraiment de supprimer une dépendance du chemin d’élévation de privilèges.

Cette équipe a finalement adopté un principe : l’identité locale doit être résoluble localement. Le reste peut être global.

Mini-story #3: The boring but correct practice that saved the day

Un environnement lié aux finances appliquait des contrôles de changement stricts, ce qui rendait leurs images de base conservatrices. Chaque serveur avait une entrée /etc/hosts cohérente pour son nom d’hôte et FQDN sur 127.0.1.1. Aucune exception, même dans des groupes autoscaling éphémères.

Pendant un incident chez un fournisseur DNS en amont, de nombreuses équipes ont vu des défaillances en cascade : connexions lentes, sudo lent et timeouts pour tout ce qui faisait des recherches d’identité ou de nom d’hôte. Cet environnement financier ? Majoritairement indemne. Leurs applications dépendaient toujours du DNS pour des services externes, mais les administrateurs pouvaient obtenir root instantanément et exécuter des remédiations locales sans lutter contre des timeouts de résolveur.

Ce qui les a sauvés n’était pas de l’héroïsme. C’était une hygiène de configuration ennuyeuse : résolution locale déterministe, domaines de recherche minimaux et une configuration de résolveur sans tentatives de repli trop intelligentes.

Au post-mortem, ils n’ont pas cherché à se vanter. Ils ont juste montré leurs standards de base et dit : « Nous supprimons les dépendances réseau des opérations locales. » Personne n’a contesté les résultats.

Erreurs courantes : symptôme → cause → correctif

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

Cause : la recherche du nom d’hôte atteint le DNS et attend un timeout (résolveur injoignable ou mapping local manquant).

Fix : ajoutez le mapping correct du nom d’hôte dans /etc/hosts ; assurez-vous que les serveurs DNS sont joignables via resolvectl status et les règles réseau.

2) Symptom: sudo is slow only on VPN or only off VPN

Cause : split DNS mal configuré ; le DNS par lien pointe vers le résolveur VPN même quand le tunnel est fermé (ou l’inverse).

Fix : corrigez l’intégration DNS du client VPN ; assurez-vous que systemd-resolved met à jour le DNS par lien ; évitez de coder en dur le DNS dans netplan si le DHCP/VPN doit le gérer.

3) Symptom: SSH login is slow and sudo is slow

Cause : recherches DNS inverses ou fournisseur d’identité NSS (SSSD/LDAP) qui timeout affectent à la fois la connexion et sudo.

Fix : vérifiez les enregistrements PTR et la joignabilité des annuaires ; assurez-vous que files est en premier dans nsswitch.conf et que les caches sont sains.

4) Symptom: getent hosts is slow for everything, including public domains

Cause : serveurs DNS en amont injoignables ; resolved retente et bascule.

Fix : définissez des serveurs DNS joignables ; corrigez le firewall/routage ; validez avec dig et journalctl -u systemd-resolved.

5) Symptom: sudo sometimes fast, sometimes slow, correlated with network jitter

Cause : approche « DNS uniquement autoritaire » ; nom d’hôte local absent de /etc/hosts, donc sudo dépend de la latence en amont.

Fix : restaurez le mapping local du nom d’hôte ; considérez-le comme une fonctionnalité de fiabilité, pas un bricolage.

6) Symptom: sudo slow only when using a short hostname

Cause : les domaines de recherche provoquent plusieurs tentatives ; un suffixe timeout.

Fix : réduisez les domaines de recherche ; utilisez des FQDN dans l’automatisation ; assurez-vous que le nom court se résout localement s’il doit exister.

7) Symptom: after upgrade to 24.04, delays appear where 22.04 was fine

Cause : changements dans les valeurs par défaut de resolved, intégration de la pile réseau, ou sélection différente de serveurs DNS (surtout avec split DNS/VPN).

Fix : vérifiez le DNS effectif via resolvectl status ; ne supposez pas que votre ancienne chaîne de résolveurs a survécu à la mise à niveau.

Checklists / plan étape par étape

Step-by-step: fix slow sudo with minimal risk

1. Mesurez : chronométrez sudo -n true et getent hosts $(hostname). Si les deux sont lents, c’est le service de noms.
2. Garde-fou local : assurez-vous que /etc/hosts mappe 127.0.1.1 vers hostname (et le FQDN si vous en utilisez un).
3. Confirmez l’amélioration : retimez sudo -n true. Si c’est maintenant rapide, vous avez éliminé le principal goulot.
4. Corrigez le DNS en amont : vérifiez resolvectl status ; assurez-vous que les serveurs DNS sont joignables ; corrigez netplan/DHCP/VPN.
5. Réduisez le fan-out des requêtes : resserrez les domaines de recherche ; cessez d’utiliser des noms courts dans les scripts.
6. Sanité NSS : vérifiez l’ordre dans /etc/nsswitch.conf hosts ; évitez les modules lents sauf si nécessaire.
7. Prévention de régression : ajoutez une vérification de surveillance de la joignabilité/latence DNS et un simple test « sudo est rapide » dans les pipelines de provisioning.

Change-control checklist (for fleets)

• Baseline /etc/hosts inclut le mapping du nom d’hôte sur loopback.
• Les templates netplan n’encodent pas en dur des DNS qui n’existeront pas dans tous les environnements.
• Les domaines de recherche sont courts et intentionnels.
• La configuration NSS est cohérente entre les hôtes, avec résolution locale prioritaire.
• Les fournisseurs d’annuaire (SSSD/LDAP) sont surveillés, et les timeouts sont compris.
• IPv6 est soit supporté bout à bout soit désactivé de manière cohérente (pas d’« IPv6 fantôme »).

FAQ

1) Why does sudo care about DNS at all?

Parce qu’il demande au système qui vous êtes (recherches utilisateur/groupe) et résout souvent le nom d’hôte local pour la journalisation, la politique ou les vérifications d’environnement. Ces appels passent par NSS, qui peut consulter le DNS.

2) I added the hostname to /etc/hosts and sudo is fast now. Is that a hack?

Non. C’est un modèle de fiabilité : les opérations locales ne doivent pas dépendre des services réseau. Conservez le DNS pour la découverte de services ; conservez le mapping local pour l’identité de la machine.

3) Why is the delay so often exactly five seconds?

Parce que les timeouts et tentatives du résolveur sont souvent réglés dans cette plage, et une seule requête échouée peut bloquer l’appelant jusqu’à son expiration. Ce n’est pas aléatoire ; c’est une minuterie.

4) What’s the difference between /etc/hosts and DNS for hostname resolution?

/etc/hosts est local, immédiat et déterministe. Le DNS dépend du réseau et peut échouer ou se bloquer. NSS décide quelles sources sont consultées et dans quel ordre.

5) Should I disable systemd-resolved to fix this?

Normalement non. systemd-resolved est rarement la cause racine ; il vous montre que votre configuration DNS est erronée ou injoignable. Corrigez le chemin DNS en amont d’abord.

6) Can search domains alone cause slow sudo?

Oui. Un nom court peut être étendu en plusieurs requêtes DNS. Si un suffixe timeoute, vous obtenez un délai qui ressemble à « sudo lent » mais qui est en réalité « le DNS tergiverse ».

7) How do I know if SSSD/LDAP is the problem instead of DNS?

Chronométrez id $USER et getent passwd $USER. Si ceux-ci sont lents, la recherche d’identité est lente. Si seule la résolution de nom d’hôte est lente, concentrez-vous sur la résolution hosts: et la joignabilité DNS.

8) Why did this show up after moving the VM or changing networks?

Parce que les serveurs DNS sont spécifiques au réseau dans de nombreux environnements. Les résolveurs codés en dur, les options DHCP obsolètes ou les politiques DNS VPN ne survivent pas proprement aux déplacements.

9) Does IPv6 matter here if I “don’t use IPv6”?

Ça compte si votre résolveur tente des requêtes AAAA et que votre réseau bloque ou noie l’IPv6. Soit prenez en charge IPv6 correctement, soit désactivez-le de façon cohérente ; les demi-mesures créent des timeouts.

10) What’s the single best quick fix under pressure?

Ajoutez le mapping correct du nom d’hôte dans /etc/hosts et vérifiez que getent hosts $(hostname) est instantané. Ensuite réparez le DNS en amont quand vous êtes hors zone de turbulence.

Conclusion : prochaines étapes que vous ferez vraiment

Un sudo lent sur Ubuntu 24.04 n’est généralement pas « sudo qui est lent ». C’est votre pile de services de noms qui attend le DNS, les domaines de recherche ou les fournisseurs d’identité. La bonne nouvelle : c’est diagnostiquable avec un chronomètre et une ou deux commandes.

Faites ceci, dans l’ordre :

1. Chronométrez sudo -n true et getent hosts $(hostname).
2. Corrigez /etc/hosts pour que le nom d’hôte se résolve localement et instantanément.
3. Utilisez resolvectl status et les logs de resolved pour trouver les serveurs DNS injoignables et corriger netplan/DHCP/VPN.
4. Resserrez les domaines de recherche et évitez les noms à label unique dans l’automatisation.
5. Ce n’est qu’ensuite que vous devrez envisager des ajustements d’ordre NSS, et faites-le délibérément.

Si vous supprimez le timeout, vous supprimez le drame. Et votre futur vous — regardant un terminal figé pendant un incident — approuvera silencieusement.