Résolutions DNS lentes sur Linux : corriger systemd-resolved correctement

Playbook de diagnostic rapide

Si les résolutions DNS paraissent lentes, ne commencez pas par éditer des fichiers de configuration. Commencez par prouver où le temps est passé. Vous cherchez : des retransmissions, l’expansion des domaines de recherche, des délais de bascule IPv6/IPv4, des blocages DNSSEC, ou un stub local qui n’est pas réellement local.

1) Confirmez que c’est DNS, pas TCP

Choisissez un nom d’hôte que vous savez lent dans votre application (pas un domaine d’exemple). Mesurez la résolution de nom séparément de la connexion.

cr0x@server:~$ time getent ahosts api.internal.example
192.0.2.41      STREAM api.internal.example
192.0.2.41      DGRAM
192.0.2.41      RAW

real    0m2.183s
user    0m0.010s
sys     0m0.006s

Ce que cela signifie : getent utilise le même chemin NSS que vos applications. Si cela prend des secondes, vous avez trouvé le bon sous-système.

Décision : Si getent est lent mais qu’un dig @server direct est rapide, votre goulot d’étranglement est la logique du résolveur local (domaines de recherche, ordre NSS, comportement du stub), pas le DNS en amont.

2) Identifiez le chemin résolveur actif

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

Link 2 (ens192)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54
        DNS Domain: corp.example

Ce que cela signifie : Ceci vous indique si systemd-resolved est en jeu et quels serveurs DNS et domaines il connaît.

Décision : Si resolv.conf mode est stub, les applications interrogent probablement 127.0.0.53. Si c’est foreign ou static, quelque chose d’autre possède /etc/resolv.conf et vous devez déboguer ce propriétaire.

3) Cherchez les retransmissions et les timeout

cr0x@server:~$ resolvectl query api.internal.example
api.internal.example: 192.0.2.41                     -- link: ens192

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

Ce que cela signifie : Le temps « acquis en » est la douleur visible par l’utilisateur.

Décision : Si c’est >200ms de façon constante sur un réseau local, vous observez probablement des timeouts/retransmissions ou un domaine de recherche cassé. Passez à une capture de paquets ou aux logs de resolved.

4) Différencier “DNS amont lent” de “comportement local lent”

cr0x@server:~$ dig +tries=1 +time=1 @10.0.0.53 api.internal.example A

; <<>> DiG 9.18.24-1ubuntu1.2-Ubuntu <<>> +tries=1 +time=1 @10.0.0.53 api.internal.example A
;; global options: +cmd
;; ANSWER SECTION:
api.internal.example.  60 IN A 192.0.2.41

;; Query time: 7 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Wed Dec 31 12:12:12 UTC 2025
;; MSG SIZE  rcvd: 68

Ce que cela signifie : Le DNS en amont est rapide. Votre chemin de résolution local ne l’est pas.

Décision : Concentrez-vous sur la configuration de systemd-resolved, NSS et le stub. Ne perdez pas une semaine à hurler contre l’équipe DNS.

La chaîne de résolution : où se cachent les secondes

La résolution de nom sous Linux n’est pas « une requête DNS ». C’est une chaîne de décisions, et chaque décision peut ajouter un délai.

Le chemin que la plupart des gens utilisent réellement

1. Une application appelle getaddrinfo() (souvent pour A et AAAA). Certaines apps le font dans le chemin critique. D’autres le font à chaque requête parce que le cache est « compliqué ».
2. glibc consulte NSS via /etc/nsswitch.conf et parcourt les sources configurées (files, resolve, dns, mdns, wins…). L’ordre importe. La gestion des échecs importe encore plus.
3. Si systemd-resolved est activé et que NSS est réglé sur resolve, glibc parle à resolved via D-Bus ou le module nss-resolve. Sinon, glibc utilise /etc/resolv.conf et envoie des paquets DNS directement.
4. Si /etc/resolv.conf pointe vers 127.0.0.53, votre « nameserver » est un stub local écoutant sur localhost. Ce stub achemine vers l’amont, applique le routage split DNS, met en cache, peut valider DNSSEC, et essaie d’être utile.
5. Les serveurs en amont peuvent être des résolveurs de cache locaux, le DNS d’entreprise, un résolveur fourni par le VPN, ou quelque chose obtenu par DHCP dans un hôtel qui devrait être illégal.

Le symptôme « DNS lent » peut venir de n’importe quelle couche. Et oui, dig peut être rapide alors que votre application est lente, parce que dig contourne des parties de cette chaîne. Si vous ne diagnostiquez qu’avec dig, vous déboguez le mauvais système.

Une citation à garder en tête pendant que vous poursuivez cela : « L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan. Ce n’est pas spécifique au DNS, mais ça s’applique douloureusement.

Blague #1 : Le DNS est le seul endroit où « c’est toujours le réseau » et « ce n’est jamais le réseau » sont étrangement vrais en même temps.

Faits et historique qui expliquent les bizarreries actuelles

• Le comportement du résolveur d’origine précède votre cloud. La logique par défaut des « search domain » vient d’une époque où printer résolvait en printer.office était normal, et le coût des requêtes supplémentaires était ignoré.
• NSS est un système de plug-ins, pas juste DNS. Les recherches de noms peuvent impliquer fichiers locaux, LDAP, mDNS, WINS, et le résolveur de systemd. Un mauvais ordre peut ajouter des secondes par appel.
• systemd-resolved a popularisé un stub local. Cette adresse 127.0.0.53 n’est pas un « vrai serveur DNS » ; c’est une couche de commodité pour supporter le split DNS, le cache, et la politique.
• La mise en cache des réponses négatives est une fonctionnalité de performance. Sans elle, fautes de frappe et domaines morts deviennent des timeouts répétés. Avec elle, les mauvaises configurations peuvent sembler « persistantes » jusqu’à l’expiration du cache.
• Les requêtes AAAA sont devenues standard, et ça a changé la latence. Les clients double-pile interrogent souvent AAAA puis A ; des chemins IPv6 cassés peuvent ajouter des délais même si IPv4 fonctionne.
• EDNS(0) a amélioré le DNS, puis les MTU l’ont ruiné. Les réponses UDP plus grandes aident pour les enregistrements modernes, mais quand la découverte de PMT échoue, vous avez des retransmissions et des recours qui ressemblent à une « lenteur aléatoire ».
• DNSSEC est peu coûteux en calcul jusqu’à ce que ce ne le soit plus. Le coût de validation est généralement faible, mais des problèmes de synchronisation horaire et des chaînes amont cassées peuvent provoquer des requêtes supplémentaires et des retards.
• Les VPN ont rendu le split DNS normal. Les environnements d’entreprise routent désormais couramment certains suffixes vers des résolveurs internes et le reste vers des résolveurs publics. C’est un moteur de politique, pas « juste du DNS ».

À quoi ressemble une « DNS lente » (et pourquoi dig peut mentir)

Voici les motifs classiques :

• La première requête est lente, puis rapide. Le cache à un certain niveau fonctionne, mais le premier miss est coûteux (timeouts ou expansion de la liste de recherche).
• Seuls certains noms d’hôtes sont lents. En général routage split DNS (mauvaise interface), fuite de zone interne, ou un serveur DNS qui peut résoudre les noms publics mais pas les privés (ou l’inverse).
• Seuls certains programmes sont lents. Les apps qui utilisent libc/NSS sont lentes ; des outils comme dig sont rapides. Cela pointe vers l’ordre NSS, le stub resolved, ou la bascule IPv6/IPv4.
• Tout devient lent après la connexion VPN. Le VPN a poussé des domaines de recherche et maintenant chaque nom sans point génère une petite tempête de requêtes.
• Pics intermittents de plusieurs secondes. Retransmissions à cause de perte UDP, problèmes de MTU, ou un serveur DNS parfois indisponible.
• NXDOMAIN est lent. Les réponses négatives empruntent la voie longue (expansion des search domains) ou expirent à cause d’un mauvais serveur DNS en amont.

Blague #2 : Si vous voulez voyager dans le temps, lancez apt update sur un portable avec une mauvaise liste de search domains.

Tâches pratiques : commandes, sorties, décisions

Ce ne sont pas des « commandes au hasard ». Chacune répond à une question précise, et chaque question doit changer ce que vous faites ensuite.

Task 1: Prouvez que le chemin lent utilise libc/NSS

cr0x@server:~$ time getent hosts github.com
140.82.121.3    github.com

real    0m1.612s
user    0m0.003s
sys     0m0.004s

Sens : getent hosts utilise NSS. Si c’est lent, vos applications seront lentes.

Décision : Continuez avec les vérifications NSS et resolved. Si getent est rapide mais que votre app est lente, votre application fait autre chose (proxy, TLS, OCSP, ou boucles de retry).

Task 2: Comparez la vitesse d’une requête DNS directe

cr0x@server:~$ time dig +tries=1 +time=1 github.com A | sed -n '1,20p'
; <<>> DiG 9.18.24-1ubuntu1.2-Ubuntu <<>> +tries=1 +time=1 github.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48219
;; ANSWER SECTION:
github.com.              60 IN A 140.82.121.3

Sens : Si dig est rapide alors que getent est lent, le DNS en amont est correct.

Décision : Concentrez-vous sur la chaîne résolveur (search domains, stub, DNSSEC, IPv6).

Task 3: Identifiez qui possède /etc/resolv.conf

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

Sens : Si c’est un lien symbolique vers le stub de systemd, le stub local est utilisé.

Décision : N’éditez pas /etc/resolv.conf à la main. Vous perdrez. Configurez le gestionnaire (resolved, NetworkManager, netplan, ou votre client DHCP).

Task 4: Inspectez le contenu du stub et les domaines de recherche

cr0x@server:~$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
nameserver 127.0.0.53
options edns0 trust-ad
search corp.example dev.corp.example

Sens : Des listes de search longues ou erronées provoquent des requêtes supplémentaires. Certains résolveurs essayent aussi un comportement de type ndots ; libc utilise aussi options.

Décision : Si la liste de recherche est longue, réduisez-la à la source (config DHCP/VPN) ou définissez des domaines par interface correctement.

Task 5: Vérifiez l’ordre NSS (tueur silencieux de performance)

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

Sens : Cet ordre tente fichiers locaux, puis mDNS, puis systemd-resolved, puis DNS. mDNS peut ajouter du délai pour des noms non-.local s’il est mal configuré. Les règles entre crochets comptent.

Décision : Sur les serveurs, préférez un comportement déterministe. Si vous n’utilisez pas mDNS, retirez-le. Si vous utilisez resolved, gardez resolve avant dns pour éviter de contourner le split-DNS.

Task 6: Observez la vision du monde de resolved

cr0x@server:~$ resolvectl dns
Global: 10.0.0.53 10.0.0.54
Link 2 (ens192): 10.0.0.53 10.0.0.54

Sens : Confirme quels serveurs DNS resolved utilisera. Le DNS par interface compte avec les VPN et les interfaces multiples.

Décision : Si la mauvaise interface a le DNS de « DefaultRoute », corrigez les réglages par interface (NetworkManager, netplan, ou configuration resolved).

Task 7: Mesurez avec resolvectl (contourne NSS mais touche resolved)

cr0x@server:~$ resolvectl query -t A -c 1 api.internal.example
api.internal.example: 192.0.2.41                     -- link: ens192

-- Information acquired via protocol DNS in 2.044s.

Sens : Lent ici signifie que le chemin de transfert de resolved est lent (choix du serveur, retransmissions, DNSSEC, problèmes de paquets), pas seulement l’expansion de recherche NSS.

Décision : Vérifiez les logs et faites une capture de paquets ensuite.

Task 8: Activez les logs debug de resolved (temporairement)

cr0x@server:~$ sudo resolvectl log-level debug
cr0x@server:~$ sudo journalctl -u systemd-resolved -n 50 --no-pager
Dec 31 12:20:11 server systemd-resolved[612]: Sending query for api.internal.example IN A on interface 2/ens192.
Dec 31 12:20:12 server systemd-resolved[612]: Timeout reached on transaction 45123.
Dec 31 12:20:13 server systemd-resolved[612]: Retrying transaction 45123.

Sens : Vous pouvez littéralement voir les timeouts et les retransmissions.

Décision : Si vous voyez des timeouts, suspectez une perte UDP, un pare-feu, un mauvais serveur, ou des problèmes MTU/EDNS. Si vous voyez des tentatives répétées pour des domaines de recherche, suspectez la liste de recherche et des noms d’un seul label.

Task 9: Capture de paquets : prouver retransmissions ou problèmes de fragmentation

cr0x@server:~$ sudo tcpdump -ni any '(udp port 53 or tcp port 53)' -vv -c 20
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
12:22:01.123456 ens192 Out IP 10.0.0.10.51234 > 10.0.0.53.53: 45123+ A? api.internal.example. (40)
12:22:02.124987 ens192 Out IP 10.0.0.10.51234 > 10.0.0.53.53: 45123+ A? api.internal.example. (40)
12:22:03.127001 ens192 In  IP 10.0.0.53.53 > 10.0.0.10.51234: 45123* 1/0/0 A 192.0.2.41 (56)

Sens : Même requête envoyée deux fois avant qu’une réponse n’arrive : c’est un comportement de retransmission, pas « le CPU est lent ».

Décision : Si les retransmissions sont courantes, cherchez une perte de paquets, des résolveurs surchargés, des limites de débit du pare-feu, ou des problèmes MTU. Si les réponses n’arrivent qu’en TCP, examinez EDNS et la fragmentation.

Task 10: Vérifiez si resolved tombe en fallback TCP

cr0x@server:~$ resolvectl statistics
Transactions: 2145
Cache: size 1024, hits 1432, misses 713
DNSSEC Verdicts: secure 0, insecure 0, bogus 0, indeterminate 0

Sens : Les statistiques peuvent indiquer si le cache aide. Elles ne diront pas directement si le fallback TCP se produit, mais combinées à tcpdump elles racontent une histoire.

Décision : Si les misses de cache sont élevés pour des noms répétés, vos TTL peuvent être minuscules, ou vos apps génèrent des noms uniques (service discovery débridé).

Task 11: Identifiez les délais induits par IPv6 (problèmes AAAA)

cr0x@server:~$ getent ahosts example.com | head
2606:2800:220:1:248:1893:25c8:1946 STREAM example.com
2606:2800:220:1:248:1893:25c8:1946 DGRAM
2606:2800:220:1:248:1893:25c8:1946 RAW

Sens : Si AAAA existe, votre application peut tenter IPv6 en premier. Si le routage IPv6 est cassé, vous verrez des délais de connexion qui ressemblent à des délais DNS.

Décision : Si la résolution de nom est rapide mais que les connexions stagnent, corrigez le routage IPv6/RA/pare-feu plutôt que de toucher au DNS. Si la résolution elle-même est lente, poursuivez le débogage de resolved.

Task 12: Tracer une seule résolution lente avec strace

cr0x@server:~$ strace -f -tt -o /tmp/ga.trace getent hosts api.internal.example
192.0.2.41      api.internal.example
cr0x@server:~$ tail -n 12 /tmp/ga.trace
12:24:41.100112 connect(3, {sa_family=AF_UNIX, sun_path="/run/systemd/resolve/io.systemd.Resolve"}, 110) = 0
12:24:41.100321 sendto(3, "{...}", 224, 0, NULL, 0) = 224
12:24:43.142901 recvfrom(3, "{...}", 4096, 0, NULL, NULL) = 312
12:24:43.143210 close(3) = 0

Sens : Vous pouvez voir l’écart de 2 secondes entre l’envoi et la réception. C’est la latence du résolveur, pas du CPU de l’application.

Décision : Si les délais surviennent avant de contacter resolved (par ex. en itérant fichiers, mdns), corrigez l’ordre NSS. Si les délais surviennent en attendant resolved, corrigez resolved ou l’amont.

Task 13: Vérifiez la configuration de systemd-resolved (ce que vous avez réellement défini)

cr0x@server:~$ systemd-analyze cat-config systemd/resolved.conf
# /etc/systemd/resolved.conf
[Resolve]
DNS=10.0.0.53 10.0.0.54
Domains=corp.example
DNSSEC=no
DNSOverTLS=no
Cache=yes

Sens : C’est la configuration effective, y compris les drop-ins. C’est mieux que de deviner quel fichier est utilisé.

Décision : Si DNSSEC est « allow-downgrade » ou « yes » et que vous êtes dans un environnement d’entreprise chaotique, envisagez de le définir explicitement (mais faites-le avec intention, pas en panique).

Task 14: Assurez-vous que /etc/resolv.conf ne se bat pas avec votre gestionnaire réseau

cr0x@server:~$ resolvectl status | grep -E 'resolv\.conf mode'
  resolv.conf mode: stub

Sens : « stub » signifie que le chemin d’intégration prévu est actif.

Décision : Si vous voyez resolv.conf mode: foreign, trouvez qui l’a écrasé (souvent un client VPN ou le paquet legacy resolvconf) et arrêtez la lutte de tirage.

Corriger systemd-resolved correctement (modèles de réglage)

« Désactiver systemd-resolved » est l’équivalent DNS de retirer le détecteur de fumée parce qu’il est bruyant. Parfois il faut le remplacer, mais la plupart du temps il faut le configurer pour qu’il cesse de faire des choses coûteuses à votre place.

Modèle A : Corriger les domaines de recherche (le multiplicateur silencieux de requêtes)

Si votre /etc/resolv.conf contient plusieurs domaines de recherche, une requête pour db devient :

• db.corp.example
• db.dev.corp.example
• db (selon les options)

Multipliez par A et AAAA, multipliez par les retries, multipliez par chaque microservice. Vous voyez l’idée.

À faire : Sur les serveurs, privilégiez les FQDN dans les configs et maintenez la liste de recherche courte. Si le DHCP pousse des choses inutiles, corrigez le DHCP. Si un VPN pousse des éléments inutiles, corrigez le profil VPN. Si aucun des deux n’est possible, imposez des domaines rationnels via la configuration par interface de resolved à travers votre gestionnaire réseau.

Modèle B : Utiliser le DNS par interface et les domaines de routage pour le split DNS

L’approche correcte pour entreprise + Internet est généralement le split DNS : suffixes internes vers résolveurs internes, tout le reste vers un résolveur général. systemd-resolved est conçu pour cela. Le mode d’échec fréquent est que le DNS de « DefaultRoute » se retrouve sur la mauvaise interface (VPN vs Wi‑Fi), ou que le VPN veut seulement corp.example mais devient par erreur le résolveur pour tout.

À faire : Faites des domaines internes des domaines de routage où c’est approprié. Dans la sémantique de systemd-resolved, préfixer un domaine par ~ en fait un domaine de routage. Cela signifie « envoyer les requêtes pour ce suffixe à ces serveurs DNS », pas « ajouter ce suffixe aux noms non qualifiés ». Vous réduisez les expansions inutiles tout en continuant à router correctement.

Modèle C : Décidez explicitement du DNSSEC (ne laissez pas les défauts vous surprendre)

DNSSEC est excellent quand la chaîne est intacte et que l’heure est synchronisée. En entreprise, vous rencontrerez des middleboxes qui réécrivent le DNS, des portails captifs qui détournent, et des zones internes jamais signées. Cela ne signifie pas « désactiver DNSSEC partout ». Cela signifie décider où vous voulez la validation et où vous ne la voulez pas.

À faire : Sur des serveurs dans un réseau contrôlé, définissez la politique DNSSEC explicitement dans /etc/systemd/resolved.conf et vérifiez que votre amont la prend en charge. Sur des portables itinérants, « allow-downgrade » peut éviter des tickets de support mais c’est un compromis de sécurité. Faites ce compromis en connaissance de cause.

Modèle D : Ne vous battez pas pour la propriété de /etc/resolv.conf

Les distributions modernes s’attendent à ce que quelque chose gère /etc/resolv.conf. Si vous l’éditez manuellement, il sera écrasé. Si vous installez un second gestionnaire, vous obtenez des heisenbugs.

À faire : Choisissez une autorité : NetworkManager, systemd-networkd/netplan, ou une configuration statique délibérée. Assurez-vous que votre client VPN s’intègre à cette autorité plutôt que d’écrire directement sur /etc/resolv.conf.

Modèle E : Corrigez les timeouts en réparant le réseau, pas en les masquant

Il existe des réglages pour le nombre de retries et les timeouts, mais si vous les devez sur un LAN, quelque chose d’autre est cassé : perte de paquets, règles de pare-feu, résolveur surchargé, MTU blackholes. Vous pouvez « optimiser » autour et perdre la bataille à 2h du matin.

Si vos logs montrent des timeouts, capturez des paquets, identifiez quel serveur est lent, et retirez-le de la rotation ou réparez-le. Si un des serveurs DNS configurés est mort, votre « DNS rapide » est en réalité « rapide la moitié du temps ».

Trois mini-récits d’entreprise issus du terrain

Incident 1 : La mauvaise hypothèse (dig est rapide, donc le DNS va bien)

Une entreprise de taille moyenne a subi une vague « d’interruptions intermittentes » sur des API internes. Côté application, cela ressemblait à des blocages de connexion TCP. Les ingénieurs ont lancé dig sur le nom interne et ont obtenu des réponses en quelques millisecondes. Affaire classée, pensaient-ils. L’équipe API a commencé à enquêter sur les pools de threads et les load balancers à la place.

Puis quelqu’un a exécuté getent ahosts et a vu des délais de 1–3 secondes, surtout pour des noms qui n’existaient pas. C’était le premier indice : le service n’était pas lent, le résolveur l’était lorsqu’on lui demandait des fautes de frappe, des noms de service périmés, ou des points de terminaison désactivés.

La cause racine était une longue liste de domaines de recherche poussée par un profil VPN. Chaque nom à un seul label générait plusieurs requêtes à travers des frontières split DNS. Pire encore, certains suffixes étaient routés vers des résolveurs incapables d’y répondre et qui se contentaient de timeout plutôt que de répondre NXDOMAIN. Chaque timeout faisait une ou deux secondes. Multipliez cela par les retries et par A+AAAA, et vous obtenez l’« interruption intermittente ».

La correction n’a pas été de désactiver systemd-resolved. Il a fallu convertir les « Domains » du VPN en domaines de routage pour les suffixes internes, raccourcir la liste de recherche, et arrêter les résolutions à un seul label dans les configs de production. L’incident a disparu. Le postmortem a inclus une nouvelle règle : pour les services Linux, mesurer avec getent, pas seulement dig.

Incident 2 : L’optimisation qui a mal tourné (forcer un résolveur « rapide »)

Dans une autre société, quelqu’un a décidé que les résolveurs d’entreprise étaient « lents », basé sur quelques tests de portables pris dans des cafés. L’optimisation proposée : hardcoder des résolveurs publics dans /etc/systemd/resolved.conf sur toutes les stations de développement. Ils l’ont déployé comme tweak standard de l’image.

Les performances se sont améliorées pour les domaines publics. Puis les outils internes ont commencé à échouer. Certaines zones internes n’étaient résolvables que sur le DNS corporate. Les développeurs ont commencé à ajouter des rustines : entrées dans /etc/hosts, scripts DNS ad-hoc pour le VPN, et l’habitude de copier des IPs dans les configs « juste pour faire avancer les choses ». Évidemment, ces IP ont changé, et les hacks sont devenus des interruptions.

Le plus amusant : les résolveurs publics étaient bloqués sur certains segments réseau corporate, donc l’« optimisation » provoquait des timeouts et de longues bascules exactement là où on en a le moins besoin — pendant la réponse à incident sur un segment restreint.

La correction a été un rollback et une meilleure conception split DNS : suffixes corporate routés vers les résolveurs corporate, tout le reste utilisant les résolveurs du réseau local avec mise en cache. Les développeurs ont gagné en rapidité sans casser les noms internes. La sécurité a obtenu une politique. Les opérations ont eu moins de tickets. Tout le monde a arrêté de prétendre qu’« un serveur DNS pour tout » est une stratégie.

Incident 3 : La pratique ennuyeuse et correcte qui a sauvé la journée (rendre le comportement du résolveur observable)

Une grande entreprise n’avait pas un DNS parfait. Elle disposait de multiples résolveurs, VPNs, et un mix de distributions. Ce qu’elle avait, en revanche, c’était une pratique ennuyeuse et disciplinée : chaque image de flotte livrée contenait un script léger « santé du résolveur » et un bundle de débogage standard qui capturait resolvectl status, /etc/nsswitch.conf, /etc/resolv.conf, et une courte trace de paquets quand déclenché.

Un après-midi, une nouvelle politique de pare-feu a commencé à limiter le débit des fragments UDP. Personne ne l’a annoncé comme « lié au DNS ». Le premier symptôme a été une lenteur de connexion aléatoire, puis des soucis d’installation de paquets, puis des microservices qui time-out.

Parce que le bundle résolveur existait, l’astreinte n’a pas deviné. Ils ont comparé des traces de paquets d’hôtes sains et malsains. Les hôtes malsains montraient des réponses tronquées, un fallback TCP, et des retries répétées. La corrélation avec un segment réseau spécifique a été immédiate. Ils ont fourni à l’équipe pare-feu des preuves, pas des impressions.

La correction a été chirurgicale : autoriser les réponses DNS fragmentées ou imposer des tailles EDNS plus petites au bon niveau. L’incident s’est terminé sans le carrousel habituel de blâme d’une semaine. La pratique ennuyeuse a gagné. Encore une fois.

Erreurs courantes : symptôme → cause racine → correctif

1) « dig est rapide mais curl est lent »

Symptôme : dig renvoie vite ; les applications bloquent avant de se connecter.

Cause racine : Les applications utilisent libc/NSS ; dig contourne l’ordre NSS et peut interroger un serveur différent. De plus, les apps interrogent souvent A+AAAA plus l’expansion de recherche ; votre test dig a probablement fait une seule requête.

Correctif : Testez avec getent ahosts et resolvectl query. Auditez /etc/nsswitch.conf et les domaines de recherche ; assurez-vous que le routage de resolved est correct.

2) « Tout est lent après le VPN »

Symptôme : Les résolutions sont rapides avant le VPN, lentes après.

Cause racine : Le VPN pousse de longs domaines de recherche et/ou vole la route DNS par défaut, envoyant toutes les requêtes vers un résolveur seulement accessible via un tunnel encombré.

Correctif : Configurez le split DNS avec des domaines de routage pour les suffixes internes ; laissez le DNS par défaut sur le lien local sauf si la politique exige le contraire.

3) « NXDOMAIN prend 5 secondes »

Symptôme : Fautes de frappe ou enregistrements manquants sont douloureusement lents.

Cause racine : Expansion de la liste de recherche + serveurs amont qui timeout au lieu de répondre ; parfois un serveur secondaire mort provoquant des retries.

Correctif : Réduire les domaines de recherche, retirer les serveurs DNS morts, et garantir que les résolveurs amont répondent correctement pour les noms inexistants.

4) « Seuls les domaines internes sont lents »

Symptôme : Les domaines publics se résolvent vite ; les zones internes traînent.

Cause racine : Mauvais routage split DNS : le suffixe interne est envoyé au mauvais résolveur, ou plusieurs interfaces se concurrencent (Wi‑Fi + VPN + bridge Docker).

Correctif : Utilisez le DNS par interface et des domaines de routage ; vérifiez avec resolvectl status quelle interface possède le domaine.

5) « Pics aléatoires : parfois 20ms, parfois 2s »

Symptôme : Majoritairement OK, parfois des blocages.

Cause racine : Perte UDP, limitation de débit par le pare-feu, problèmes MTU/EDNS, ou un des serveurs DNS configurés qui échoue de manière intermittente.

Correctif : Capture de paquets pour voir les retransmissions ; retirer ou réparer les résolveurs instables ; corriger MTU ou le traitement des UDP fragmentés.

6) « systemd-resolved n’arrête pas de changer mon resolv.conf »

Symptôme : Les modifications manuelles disparaissent.

Cause racine : Ce fichier n’est pas à vous. Il est géré par resolved ou un autre composant réseau.

Correctif : Configurez le propriétaire (resolved conf, paramètres de connexion NetworkManager, netplan/systemd-networkd). Arrêtez d’éditer /etc/resolv.conf directement.

Checklists / plan étape par étape

Étape par étape : de « lent » à « corrigé » sans conjectures

1. Mesurez avec le bon outil : lancez time getent ahosts name. Enregistrez le délai réel.
2. Vérifiez la propriété : ls -l /etc/resolv.conf. Si c’est un symlink stub, resolved est dans la boucle.
3. Inspectez les domaines de recherche : cat /etc/resolv.conf et resolvectl status. Si la recherche est longue, c’est suspect.
4. Inspectez l’ordre NSS : vérifiez la ligne hosts:. Retirez les sources inutilisées (particulièrement sur les serveurs).
5. Comparez les couches : dig @upstream vs resolvectl query vs getent. Identifiez où le délai apparaît.
6. Activez brièvement le debug : mettez le niveau de log de resolved sur debug et lisez les timeouts/retries.
7. Capturez des paquets : confirmez retransmissions, truncation, fallback TCP, ou « pas de réponse ».
8. Corrigez la cause : serveur DNS erroné, secondaire mort, MTU cassé, routage split DNS, incompatibilité DNSSEC, ou bloat de la liste de recherche.
9. Restaurez les réglages de debug : remettez le niveau de log à normal et gardez le journal propre.
10. Re-testez et documentez : relancez les mêmes mesures et capturez les timings avant/après.

Checklist opérationnelle : empêcher un retour du problème

• Standardisez la gestion du DNS sur chaque distro (NetworkManager vs networkd) et ne mélangez pas les gestionnaires sur le même hôte.
• Définissez des domaines de recherche autorisés par environnement ; gardez les serveurs de production conservateurs.
• Surveillez la latence et les taux d’erreur du résolveur depuis les hôtes, pas seulement depuis les serveurs DNS.
• Ayez un ensemble de commandes « sanity » pour l’astreinte : getent, resolvectl, journalctl, tcpdump.

FAQ

1) Dois-je désactiver systemd-resolved pour résoudre une DNS lente ?

Généralement non. Le désactiver casse souvent le split DNS, le routage VPN, et le comportement cohérent entre applications. Corrigez le goulot réel (domaines de recherche, DNS par interface erroné, timeouts) et conservez le moteur de politique.

2) Pourquoi 127.0.0.53 est dans /etc/resolv.conf ?

C’est le stub local de systemd-resolved. Les applications interrogent localhost ; resolved relaie vers les serveurs DNS réels et applique le routage/le cache. Si c’est lent, soit il relaie lentement soit il effectue trop de travail par requête.

3) Pourquoi dig est rapide mais getent est lent ?

dig est un client DNS ; getent suit NSS et utilise le même chemin que la plupart des applications. Un getent lent signifie généralement que l’ordre NSS, les domaines de recherche, ou l’intégration de resolved provoquent des requêtes supplémentaires ou des timeouts.

4) Comment savoir si le délai vient de l’expansion du domaine de recherche ?

Regardez les logs debug de resolved et les captures de paquets. Vous verrez des requêtes répétées pour le même nom de base avec différents suffixes. Comparez aussi une recherche à un seul label (db) vs un FQDN (db.corp.example).

5) DNSSEC rend-il les résolutions plus lentes ?

Ça peut arriver, mais ce n’est pas le méchant par défaut. La plupart des surcoûts DNSSEC sont faibles. La lenteur apparaît lorsque la validation déclenche des requêtes supplémentaires, l’heure est incorrecte, ou l’amont casse la chaîne. Décidez la politique explicitement plutôt que d’espérer que les défauts fonctionnent.

6) IPv6 peut-il causer une « lenteur DNS » même si le DNS va bien ?

Oui. Beaucoup d’apps résolvent AAAA puis testent IPv6 en premier. Si la connectivité IPv6 est cassée, le délai de connexion peut être confondu avec un délai DNS. Séparez le timing de la résolution (getent) du timing de la connexion (curl -v ou nc).

7) Quelle est la façon la plus sûre de changer les paramètres du résolveur sur des serveurs ?

Changez-les via le gestionnaire réseau du système et engagez-les comme du code (configs netplan, profils NetworkManager, ou units systemd-networkd). Évitez les modifications ponctuelles de /etc/resolv.conf.

8) J’ai plusieurs serveurs DNS configurés. Pourquoi cela pourrait-il être plus lent ?

Si un serveur est mort ou laisse tomber des réponses, votre résolveur peut attendre, retrier, puis basculer. Cela peut ajouter des secondes. Plusieurs serveurs sont bénéfiques quand ils sont sains ; ils sont catastrophiques si l’un d’eux est brisé silencieusement.

9) Pourquoi les réponses NXDOMAIN prennent parfois plus de temps que les réponses réussies ?

Parce que le résolveur peut essayer les domaines de recherche et plusieurs types d’enregistrement, et certains serveurs amont timeout au lieu de répondre proprement pour certains suffixes. Les réponses négatives devraient être rapides ; si ce n’est pas le cas, quelque chose est mal routé ou cassé.

Prochaines étapes à réaliser aujourd’hui

Faites trois choses, dans cet ordre :

1. Mesurez avec getent ahosts et resolvectl query pour déboguer le même chemin que vos applications.
2. Rendez la chaîne résolveur ennuyeuse : ordre hosts: sensé, listes de recherche courtes, routage DNS par interface correct, et pas de guerre de territoire sur /etc/resolv.conf.
3. Quand vous voyez des secondes, capturez des preuves : logs debug de resolved et un court tcpdump. Puis corrigez la cause réelle—résolveurs morts, routes erronées, MTU/EDNS cassé—plutôt que de maquiller le problème.

Une fois le DNS rapide et prévisible, le reste du système cesse d’avoir l’air hanté. Ce qui est tout l’objet de l’ingénierie de fiabilité : moins de mystères, plus de sommeil.