DNS : Mouvements puissants dig/drill — commandes qui résolvent 90 % des mystères DNS

La bonne approche DNS : arrêter de deviner, commencer à localiser le saut

Le DNS est une base de données distribuée avec mise en cache, délégation et défaillance partielle comme caractéristiques de conception. Si vous le traitez comme un serveur unique (« le DNS est en panne »), vous perdrez du temps. Si vous le traitez comme une chaîne de responsabilité, vous réparerez plus vite.

La plupart des mystères DNS se réduisent à l’un des cas suivants :

• Vous avez interrogé le mauvais endroit. Différents résolveurs, vues différentes (split-horizon), contenus de cache différents.
• Vous avez interrogé le bon endroit pour le mauvais nom/type. A/AAAA vs CNAME/ALIAS, point manquant en fin de nom dans les fichiers de zone, suffixes de recherche dans les résolveurs.
• La chaîne est cassée. Mismatch de délégation, glue incorrecte, délégation « lame », registre non mis à jour, mismatch DS.
• C’est mis en cache. TTL, cache négatif, réponses obsolètes, prélecture du résolveur, caches clients.
• “C’est correct” mais opérationnellement faux. Vous pointez vers un load balancer injoignable depuis ce réseau, ou vous retournez une AAAA pour un service qui n’écoute pas réellement en IPv6.
• C’est une question de politique. Validation DNSSEC, filtrage, réécriture NXDOMAIN, proxys d’entreprise, ou résolveurs internes faisant des choses « utiles ».

Votre tâche pendant un incident est de répondre, avec des preuves : qui a répondu, quel chemin a été suivi, et ce qui changera si nous corrigeons maintenant (TTL/caches). dig et drill sont votre couteau suisse et votre lampe de poche.

Une citation à garder en tête, parce que le débogage DNS est un problème de fiabilité déguisé en simple requête :

Idée paraphrasée (John Allspaw) : « Vous ne résolvez pas les incidents en accusant les gens ; vous les résolvez en améliorant les systèmes et en comprenant comment le travail se déroule réellement. »

Blague n°1 : Le DNS est le seul système où « c’est mis en cache » est à la fois une excuse et une loi de la physique.

Faits intéressants sur le DNS (utiles en cas de panne)

1. Le DNS a été créé avant l’Internet moderne tel que vous le percevez. Il a remplacé le modèle centralisé HOSTS.TXT au début des années 1980, quand « tout le monde édite le même fichier » a cessé d’être viable à grande échelle.
2. « Récursif » et « autoritatif » sont des rôles différents. Les serveurs autoritatifs publient la vérité pour des zones ; les résolveurs récursifs récupèrent la vérité et la mettent en cache pour les clients.
3. Le cache négatif existe. Un NXDOMAIN (ou NODATA) peut être mis en cache, piloté par le champ « minimum »/TTL négatif du SOA — donc un enregistrement corrigé peut rester considéré comme inexistant pendant un certain temps.
4. Les enregistrements glue existent à cause du problème poule-œuf. Si le nom d’un nameserver est à l’intérieur de la zone qu’il sert, le parent doit fournir des A/AAAA glue pour amorcer la résolution.
5. Le flattening des CNAME est un contournement opérationnel. La spécification DNS interdit CNAME à l’apex de zone, pourtant on veut souvent un comportement apex→CDN — d’où ALIAS/ANAME ou le flattening côté fournisseur.
6. EDNS0 a été ajouté parce que les messages DNS ont grossi. Le DNS classique sur UDP avait des limites de taille ; EDNS0 les étend pour que les enregistrements modernes (surtout DNSSEC) tiennent sans basculement TCP immédiat.
7. Les échecs DNSSEC ressemblent à des « SERVFAIL aléatoires ». Beaucoup de résolveurs cachent les détails à moins que vous ne posiez les bonnes questions ; les erreurs de validation ressemblent souvent à des pannes au premier abord.
8. Les résolveurs ne sont pas tenus de se comporter de la même façon. Algorithmes de cache, prélecture, « serve stale », mise en cache agressive de NSEC et stratégies de timeout varient — donc « ça marche sur 8.8.8.8 » est une preuve, pas un verdict.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Premier : confirmer ce que le client fait réellement

• Quel résolveur le client utilise‑t‑il ? VPN d’entreprise, routeur local, stub systemd-resolved, DoH du navigateur ?
• Quel nom et quel type ? A vs AAAA, expansion des suffixes de recherche, point final manquant, la casse mixte n’a pas d’importance (le DNS est insensible à la casse dans les labels).
• Quel est exactement le symptôme ? NXDOMAIN, SERVFAIL, timeout, IP incorrecte, intermittent ?

Deuxième : comparer récursif vs autoritatif

• Interrogez un résolveur public connu (ou deux) et comparez : s’accordent‑ils ?
• Interrogez directement les serveurs autoritatifs. Si l’autoritatif est correct mais que le récursif est faux, vous êtes en terrain de cache/propagation/validation.
• Tracez la délégation. Si la chaîne casse au niveau du parent, corrigez le registrar/NS/glue/DS — pas le fichier de zone.

Troisième : décidez si vous luttez contre le cache, la délégation, la connectivité ou la politique

• Cache : TTL, TTL négatif, caches clients, « serve-stale » des résolveurs, NS obsolètes en cache.
• Délégation : NS enfant vs parent mismatch, glue incorrecte, délégation lame.
• Accessibilité : UDP/53 bloqué, TCP/53 bloqué (important pour DNSSEC/réponses volumineuses), problèmes de chemins anycast.
• Politique : validation DNSSEC, RPZ filtering, réécriture NXDOMAIN, vues split-horizon différentes.

Si vous suivez ces trois étapes, vous aurez rapidement le bon énoncé du problème : « L’autoritatif est correct mais le résolveur X met en cache NXDOMAIN pendant 10 minutes à cause du TTL SOA », c’est mieux que « le DNS est bizarre ».

Mouvements puissants dig/drill : tâches réelles, commandes, sorties, décisions

Vous trouverez ci‑dessous des tâches pratiques à réaliser en incidents réels. Chaque tâche inclut : une commande, ce que signifie la sortie, et la décision suivante. Utilisez dig si vous l’avez ; utilisez drill lorsque vous voulez un traçage intégré et une perspective légèrement différente. J’utilise les deux parce que les systèmes de production se moquent de vos préférences.

Tâche 1 : identifier le résolveur que vous interrogez réellement (vérification « qui a répondu »)

cr0x@server:~$ dig example.com A +comments

; <<>> DiG 9.18.24 <<>> example.com A +comments
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14067
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            300     IN      A       93.184.216.34

;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Dec 31 10:12:44 UTC 2025
;; MSG SIZE  rcvd: 56

Signification : La ligne SERVER vous indique qui a répondu. Ici il s’agit de 127.0.0.53, le stub systemd-resolved, pas votre résolveur d’entreprise ni un résolveur public.

Décision : Si vous déboguez « pourquoi mon portable se comporte différemment », interrogez directement le résolveur en amont réel (tâche suivante) et inspectez séparément la configuration du résolveur local.

Tâche 2 : interroger un résolveur récursif spécifique pour comparer les comportements

cr0x@server:~$ dig @1.1.1.1 example.com A +noall +answer +comments

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50289
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
example.com.            300     IN      A       93.184.216.34

Signification : Vous avez interrogé directement le résolveur Cloudflare. Si cela diffère de la réponse locale, vous êtes probablement face à du split-horizon, du filtrage ou à des états de cache différents.

Décision : Comparez 2–3 résolveurs (votre résolveur d’entreprise, un public). L’accord entre résolveurs suggère que l’autoritatif est cohérent ; la divergence indique des vues/politiques/caches différents.

Tâche 3 : vérifier les TTL pour prévoir « combien de temps avant que les utilisateurs voient la correction »

cr0x@server:~$ dig @8.8.8.8 api.corp.example A +noall +answer

api.corp.example.       17      IN      A       203.0.113.10

Signification : Le TTL est de 17 secondes. C’est la durée restante de vie en cache dans ce résolveur à ce moment précis, pas nécessairement le TTL configuré dans la zone.

Décision : Si le TTL est bas, les corrections se propageront rapidement. Si le TTL est élevé, vous attendez, ou vous contournez (liste d’acceptation IP temporaire, enregistrement parallèle, ou changer le résolveur client si nécessaire). Ne promettez pas une récupération instantanée avec un TTL de 12 heures, sauf si vous appréciez les appels inconfortables.

Tâche 4 : interroger directement les serveurs autoritatifs pour contourner le cache récursif

cr0x@server:~$ dig ns1.dns-provider.example api.corp.example A +norecurse +noall +answer +comments

api.corp.example.       300     IN      A       203.0.113.10

Signification : +norecurse indique au serveur de ne pas faire de récursion. S’il répond quand même, vous touchez un serveur autoritatif pour cette zone (ou un résolveur qui vous ignore, mais les serveurs autoritatifs réputés respectent cela).

Décision : Si l’autoritatif répond correctement mais que les résolveurs sont erronés, cessez de modifier aveuglément les fichiers de zone et commencez à penser caches, DNSSEC ou mismatch de délégation.

Tâche 5 : tracer la chaîne de délégation de bout en bout (trouver où la chaîne casse)

cr0x@server:~$ dig +trace www.example.org A

; <<>> DiG 9.18.24 <<>> +trace www.example.org A
;; Received 811 bytes from 127.0.0.53#53(127.0.0.53) in 1 ms

org.                    86400   IN      NS      a0.org.afilias-nst.info.
org.                    86400   IN      NS      a2.org.afilias-nst.info.
...
example.org.            172800  IN      NS      ns1.dns-provider.example.
example.org.            172800  IN      NS      ns2.dns-provider.example.
...
www.example.org.        300     IN      A       198.51.100.44

Signification : +trace parcourt racine → TLD → autoritatif. S’il échoue au niveau du TLD, votre registrar/délégation parent est cassé. S’il échoue au niveau de l’autoritatif, vos serveurs autoritatifs ne répondent pas correctement.

Décision : Corrigez la couche où le trace s’arrête. Ne touchez pas au code applicatif. Le DNS se fiche de votre pipeline de déploiement.

Tâche 6 : utiliser drill pour tracer et voir plus clairement les indices DS/DNSSEC

cr0x@server:~$ drill -TD www.example.org

;; Number of trusted keys: 1
;; Chasing: www.example.org. A
www.example.org.        300     IN      A       198.51.100.44
;; Chase successful

Signification : drill -T trace ; -D fournit des détails liés à DNSSEC. Un « chase successful » est une vérification rapide que la chaîne se résout en principe.

Décision : Si drill ne peut pas chaser à cause de DNSSEC, suspectez un mismatch DS, des signatures expirées, ou une publication DNSKEY cassée.

Tâche 7 : diagnostiquer SERVFAIL en vérifiant explicitement la validation DNSSEC

cr0x@server:~$ dig @1.1.1.1 broken-dnssec.example A +dnssec +multi

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24670
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Signification : Certains résolveurs retournent SERVFAIL quand la validation DNSSEC échoue (ou quand des recherches en amont échouent). +dnssec demande les enregistrements DNSSEC ; il n’impose pas la validation, mais il vous aide à voir si des RRSIG sont présents quand vous interrogez les autoritatifs.

Décision : Interrogez l’autoritatif directement avec +dnssec (tâche suivante). Si l’autoritatif sert des signatures cassées ou manque de DNSKEY, corrigez la signature chez le fournisseur ou retirez temporairement le DS au parent (avec précaution).

Tâche 8 : vérifier que les matériels DNSSEC autoritatifs existent (DNSKEY, RRSIG)

cr0x@server:~$ dig ns1.dns-provider.example broken-dnssec.example DNSKEY +norecurse +dnssec +noall +answer

broken-dnssec.example.  3600    IN      DNSKEY  257 3 13 ( ... )
broken-dnssec.example.  3600    IN      RRSIG   DNSKEY 13 2 3600 ( ... )

Signification : Vous vérifiez que la zone publie DNSKEY et qu’elle est signée (RRSIG). Si DNSKEY existe mais que les résolveurs font SERVFAIL, le DS au parent peut ne pas correspondre, ou les signatures peuvent être expirées.

Décision : Si DNSKEY/RRSIG manquent ou sont erronés, corrigez la signature de la zone. S’ils semblent présents, vérifiez le DS chez le parent (Tâche 9).

Tâche 9 : vérifier l’enregistrement DS au parent (la chaîne de confiance est‑elle intacte ?)

cr0x@server:~$ dig +trace broken-dnssec.example DS

; <<>> DiG 9.18.24 <<>> +trace broken-dnssec.example DS
...
example.                86400   IN      NS      a.iana-servers.net.
...
broken-dnssec.example.  86400   IN      DS      12345 13 2 ( ... )

Signification : Le DS dans le parent pointe vers le DNSKEY de la zone enfant. Si vous avez fait une rotation de clés sans mettre à jour le DS (ou supprimé la signature tout en laissant le DS), les résolveurs validants échouent.

Décision : Alignez DS et DNSKEY. Si vous êtes au milieu d’un incident et que le business a besoin d’un rétablissement immédiat, retirer le DS chez le parent peut restaurer la disponibilité (mais traitez cela comme un rollback contrôlé, avec suivi).

Tâche 10 : détecter les chaînes CNAME et où elles cassent

cr0x@server:~$ dig cdn.example.net A +noall +answer

cdn.example.net.        60      IN      CNAME   cdn.vendor.example.
cdn.vendor.example.     60      IN      CNAME   edge123.vendor.example.
edge123.vendor.example. 20      IN      A       192.0.2.80

Signification : Vous n’avez pas « un problème A », vous avez une chaîne. Une rupture n’importe où renvoie NXDOMAIN ou SERVFAIL selon les circonstances.

Décision : Si une chaîne existe, interrogez chaque étape directement. Lorsqu’un élément disparaît, corrigez cette zone/fournisseur spécifique. Envisagez aussi de réduire la profondeur des chaînes ; les longues chaînes amplifient les TTL et les modes d’échec.

Tâche 11 : différencier NXDOMAIN vs NODATA (même nom, échec différent)

cr0x@server:~$ dig nonexistent.example.com A +noall +comments

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10832
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

cr0x@server:~$ dig www.example.com TXT +noall +comments

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40420
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Signification : NXDOMAIN signifie que le nom n’existe pas. NOERROR avec zéro réponses signifie souvent que le nom existe mais pas ce type d’enregistrement (NODATA). Ils se mettent en cache différemment et impliquent des mauvaises configurations distinctes.

Décision : Si NXDOMAIN, vérifiez le contenu de la zone et la délégation. Si NODATA, vous avez probablement oublié de publier ce type d’enregistrement (ex. TXT pour une validation) ou vous l’avez publié dans une vue différente.

Tâche 12 : inspecter le TTL du cache négatif via le SOA (pourquoi NXDOMAIN persiste)

cr0x@server:~$ dig example.com SOA +noall +answer

example.com.            300     IN      SOA     ns1.dns-provider.example. hostmaster.example.com. 2025123101 7200 900 1209600 600

Signification : Le dernier champ SOA (ici 600) est couramment utilisé comme TTL de cache négatif en pratique. Si vous avez accidentellement supprimé un enregistrement puis l’avez remis, les résolveurs peuvent garder « il n’existe pas » pendant cette durée.

Décision : Si le TTL négatif est élevé, planifiez un rétablissement différé après correction du NXDOMAIN. En urgence, vous pouvez parfois atténuer en répondant avec un nom différent (nouveau label) qui n’est pas mis en cache négativement.

Tâche 13 : valider la délégation : comparer NS au parent vs NS au child

cr0x@server:~$ dig example.org NS +noall +answer

example.org.            172800  IN      NS      ns1.dns-provider.example.
example.org.            172800  IN      NS      ns2.dns-provider.example.

cr0x@server:~$ dig @ns1.dns-provider.example example.org NS +norecurse +noall +answer

example.org.            3600    IN      NS      ns1.dns-provider.example.
example.org.            3600    IN      NS      ns2.dns-provider.example.
example.org.            3600    IN      NS      ns3.dns-provider.example.

Signification : Le parent indique ns1+ns2 ; la zone enfant indique ns1+ns2+ns3. Ce mismatch n’est pas toujours fatal, mais c’est une source classique de comportements incohérents et de « certains résolveurs interrogent le mauvais serveur ».

Décision : Alignez les ensembles NS parent/child. Pendant les incidents, retirez les NS morts ou erronés des deux côtés ; les serveurs lames augmentent les timeouts et peuvent déclencher des tempêtes de requêtes des résolveurs.

Tâche 14 : détecter une délégation lame (NS listé mais pas autoritatif)

cr0x@server:~$ dig @ns3.dns-provider.example example.org SOA +norecurse +noall +comments

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 61120
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

Signification : Si un NS est listé mais refuse ou retourne SERVFAIL/REFUSED aux requêtes autoritatives, certains résolveurs perdront du temps dessus. C’est une « lame delegation » en pratique.

Décision : Retirez ce NS de la délégation (et/ou corrigez sa configuration). Les timeouts ici se traduisent par des temps de chargement lents et des échecs intermittents.

Tâche 15 : vérifier si le fallback TCP fonctionne (réponses volumineuses, DNSSEC, UDP tronqué)

cr0x@server:~$ dig @8.8.8.8 dnssec-large.example TXT +dnssec +noall +comments

;; Truncated, retrying in TCP mode.

cr0x@server:~$ dig @8.8.8.8 dnssec-large.example TXT +dnssec +tcp +noall +answer

dnssec-large.example.   300     IN      TXT     "v=some-long-value..."

Signification : Si l’UDP est tronqué, les résolveurs retentent en TCP. Si TCP/53 est bloqué quelque part (pare‑feu, groupe de sécurité, règles proxy d’entreprise), vous obtenez des échecs mystérieux qui corrèlent avec la taille des réponses.

Décision : Assurez‑vous que TCP/53 est autorisé entre résolveurs et serveurs autoritatifs (et des clients vers les résolveurs si applicable). Ne « sécurisez » pas en bloquant TCP/53 sans comprendre DNSSEC et les tailles de réponse modernes.

Tâche 16 : tester le DNS split-horizon en interrogeant résolveurs internes vs externes

cr0x@server:~$ dig @10.0.0.53 app.internal.example A +noall +answer

app.internal.example.   30      IN      A       10.10.20.15

cr0x@server:~$ dig @1.1.1.1 app.internal.example A +noall +comments

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5904
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Signification : Le résolveur interne répond avec une adresse RFC1918 ; le résolveur public retourne NXDOMAIN. C’est un split-horizon intentionnel — jusqu’à ce que ce ne le soit pas. Si des clients VPN utilisent DoH public, ils ne verront pas les enregistrements internes.

Décision : Décidez la politique : soit imposer l’utilisation du résolveur interne sur les appareils gérés (et désactiver DoH non géré), soit publier des équivalents publics. Ne faites pas comme si le split-horizon était invisible ; il affecte le comportement des applications.

Tâche 17 : vérifier le DNS inverse (PTR) pour le mail, le logging et « pourquoi ce fournisseur nous bloque »

cr0x@server:~$ dig -x 203.0.113.10 +noall +answer

10.113.0.203.in-addr.arpa. 3600 IN PTR mailout.example.com.

Signification : Le DNS inverse existe et pointe vers un nom d’hôte. Beaucoup de systèmes (notamment mail) l’utilisent comme signal d’identité faible.

Décision : Si le PTR manque ou est erroné, corrigez‑le avec le propriétaire de l’IP (souvent votre fournisseur cloud). Assurez‑vous aussi d’avoir une résolution avant‑après cohérente lorsque cela est nécessaire (PTR → nom → même IP).

Tâche 18 : mesurer la latence et repérer rapidement les timeouts

cr0x@server:~$ dig @9.9.9.9 www.example.com A +stats +tries=1 +time=2

; <<>> DiG 9.18.24 <<>> @9.9.9.9 www.example.com A +stats +tries=1 +time=2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31869
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
www.example.com.        60      IN      A       198.51.100.44
;; Query time: 187 msec
;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP)
;; WHEN: Wed Dec 31 10:20:12 UTC 2025
;; MSG SIZE  rcvd: 59

Signification : Vous obtenez le temps de requête en millisecondes. Un pic ici peut venir d’un chemin réseau, d’une surcharge du résolveur, de timeouts en amont dus à une délégation lame, ou d’un filtrage de paquets.

Décision : Si les temps de requête sont élevés, comparez les résolveurs et interrogez directement les autoritatifs. Si l’autoritatif est rapide mais le récursif lent, le résolveur est le goulot. Si l’autoritatif est lent/injoignable, corrigez cette couche.

Blague n°2 : Si vous faites du DNS à 3 h du matin, souvenez‑vous : les enregistrements sont immuables jusqu’à ce que vous arrêtiez de taper.

Trois mini-récits d’entreprise depuis les tranchées DNS

Incident n°1 : La panne causée par une mauvaise hypothèse

Entreprise : SaaS de taille moyenne, clients globaux, deux régions cloud. Un nouveau point de service a été lancé derrière un CDN. L’équipe a ajouté un CNAME et est passée à autre chose. Tout le monde a testé depuis des portables. Tout fonctionnait.

L’incident a commencé par « certains clients n’atteignent pas l’API ». Les symptômes étaient clairement répartis par géographie. Dans une région c’était OK ; dans une autre cela time‑outait. Les métriques applicatives semblaient normales, parce que le trafic n’arrivait jamais.

L’hypothèse erronée : « si le DNS public se résout, il se résout partout ». En réalité, un sous‑ensemble de clients d’entreprise utilisait des résolveurs récursifs qui continuaient d’interroger un ancien nameserver autoritatif du précédent fournisseur DNS — parce que la délégation chez le parent avait été mise à jour, mais un NS ancien restait listé pendant des semaines durant une migration partielle. Certains résolveurs avaient mis en cache l’ancienne délégation et continuaient d’essayer le serveur mort. Ils finissaient par réussir après des retries… parfois. Intermittent, lent et exaspérant.

Le débogage s’est fait en traçant depuis le réseau défaillant. dig +trace montrait que le parent annonçait un ensemble NS qui incluait un serveur qui ne servait plus la zone. Interroger ce serveur directement retournait REFUSED. L’équipe « ça marche pour moi » avait des résolveurs qui n’avaient pas heuristiquement frappé le NS lame.

La correction fut ennuyeuse : aligner les enregistrements NS chez le parent et l’enfant ; retirer le NS mort ; réduire les TTL NS pendant la fenêtre de migration ; et valider depuis plusieurs résolveurs avant de déclarer victoire. Le postmortem traitait plus du processus : les migrations ont besoin d’une checklist et d’une validation « terminé lorsque la délégation correspond ».

Incident n°2 : L’optimisation qui s’est retournée contre eux

Autre société, posture sécurité plus forte. Ils ont décidé que le DNS devait être « rapide » et ont réduit agressivement les TTL pour la plupart des enregistrements — 30 secondes partout. Logique : bascule et rollback rapides, moins de risque.

Puis ils ont introduit une dépendance à un fournisseur d’authentification externe avec une longue chaîne CNAME et DNSSEC. Les jours normaux, tout allait bien. Les mauvais jours, leurs résolveurs récursifs étaient saturés. Le TTL bas signifiait des manques constants de cache. Les résolveurs devaient re‑parcourir la chaîne sans cesse, récupérer DNSKEY/RRSIG et parfois retomber sur TCP quand les réponses étaient volumineuses.

Le premier symptôme fut une latence de connexion élevée, pas une panne totale. Le deuxième symptôme fut des SERVFAIL « aléatoires », parce que les résolveurs subissaient une charge et time‑outaient en amont. Le troisième symptôme fut une équipe infra convaincue que « c’est le fournisseur d’auth » tandis que le fournisseur d’auth disait qu’il était sain et que ce sont vos résolveurs qui peinaient.

La solution : arrêter de considérer le TTL comme un bouton de performance qu’on peut baisser sans conséquences. Ils ont remonté les TTL pour les enregistrements stables, gardé des TTL bas uniquement pour quelques noms de basculement, et ajouté de la capacité résolveur. Ils ont aussi arrêté de bloquer TCP/53 en sortie « parce que l’UDP suffit ». Ce n’était pas le cas.

Leçon : un TTL bas n’est pas un repas gratuit. C’est une facture récurrente que vous payez en charge résolveur et en amplification des dépendances en amont, surtout avec DNSSEC et des chaînes.

Incident n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Encore une orga, encore un jour. Ils géraient leur propre DNS autoritatif via un fournisseur managé et avaient une habitude qui ressemblait à de la paperasserie : avant chaque changement, ils capturaient des sorties « avant » pour SOA, NS et les enregistrements affectés depuis les deux serveurs autoritatifs et deux résolveurs publics. Ils conservaient les extraits dans le ticket de changement.

Un changement du vendredi a introduit un souci subtil : un ingénieur a ajouté un enregistrement AAAA pointant vers une nouvelle adresse IPv6 pour un service qui n’était pas réellement joignable depuis tous les réseaux. Le service était dual‑stack dans une région et IPv4 seulement dans une autre. Les utilisateurs sur des réseaux préférant IPv6 obtenaient des timeouts. Les utilisateurs IPv4 seulement étaient corrects. Le monitoring, majoritairement IPv4, restait au vert.

Parce qu’ils avaient des snapshots « avant », ils ont rapidement prouvé que le seul changement DNS était le AAAA. Ils ont reproduit en interrogeant séparément A et AAAA et en testant la connectivité. Le DNS était « correct », mais le déploiement ne l’était pas. L’atténuation la plus rapide fut de retirer le AAAA (ou de configurer correctement l’IPv6), pas de tripoter les résolveurs.

La pratique ennuyeuse — capturer des sorties dig de référence et vérifier A/AAAA séparément — a transformé une spirale de blâme inter‑équipes en une correction de 30 minutes. Le rapport d’incident fut court. C’est le rêve.

Erreurs courantes : symptôme → cause racine → correction

• Symptôme : « Certains utilisateurs obtiennent NXDOMAIN pour un enregistrement qui existe maintenant. »

  Cause racine : Cache négatif après suppression ou faute de frappe récente ; le TTL négatif SOA est long ; certains résolveurs ont mis en cache NXDOMAIN.

  Correction : Vérifiez le SOA (TTL négatif), attendez, ou changez temporairement le libellé ; gardez le TTL négatif raisonnable pour les zones qui changent souvent.

• Symptôme : « Ça marche sur le DNS public, échoue sur le VPN d’entreprise. »

  Cause racine : Vues split-horizon, RPZ/filtering, ou résolveur interne renvoyant des IP privées injoignables depuis le réseau client.

  Correction : Interrogez les deux résolveurs directement ; alignez les vues ou imposez l’utilisation du bon résolveur ; évitez de renvoyer des adresses non routables aux clients nomades.

• Symptôme : « SERVFAIL sur résolveurs validants, NOERROR sur non‑validants. »

  Cause racine : Mismatch DS/DNSKEY DNSSEC, signatures expirées, DNSKEY manquant sur certains noeuds autoritatifs.

  Correction : Validez le DS via trace ; corrigez le signing ou le DS ; assurez que tous les noeuds autoritatifs servent un matériel DNSSEC cohérent.

• Symptôme : « DNS intermittent lent ; parfois 2–5 secondes. »

  Cause racine : Délégation lame ou NS mort dans les ensembles parent/enfant causant des retries ; le résolveur parcourt la liste NS.

  Correction : Comparez les NS parent et enfant ; interrogez chaque NS pour SOA avec +norecurse ; retirez les NS morts ; réduisez les TTL NS pendant la transition.

• Symptôme : « L’enregistrement A paraît correct, mais les clients voient encore l’ancienne IP. »

  Cause racine : TTL encore élevé dans les caches ; caches stub locaux ; navigateurs avec DoH ; cache applicatif.

  Correction : Vérifiez le TTL depuis le résolveur affecté ; interrogez l’autoritatif ; videz le cache approprié (systemd-resolved, nscd, unbound) si vous le contrôlez ; sinon attendez ou faites un déploiement chevauchant.

• Symptôme : « Seuls les gros enregistrements TXT échouent ; petites requêtes OK. »

  Cause racine : Problèmes de fragmentation UDP, MTU EDNS sur le chemin, ou TCP/53 bloqué pour le fallback.

  Correction : Testez avec dig +tcp ; autorisez TCP/53 ; envisagez de réduire la taille EDNS UDP sur les résolveurs ; évitez les enregistrements gigantesques si possible.

• Symptôme : « La bascule CDN n’a pas fonctionné ; une partie du trafic va encore vers l’origine. »

  Cause racine : Chaîne CNAME mise en cache à différents stades ; enregistrements obsolètes dans les résolveurs ; vues multiples ou fournisseurs autoritatifs multiples pendant la migration.

  Correction : Cartographiez la chaîne et les TTL à chaque étape ; minimisez la profondeur de la chaîne ; assurez‑vous d’une source d’autorité unique ; planifiez les cutovers avec réductions de TTL graduelles.

• Symptôme : « Le fournisseur d’email dit que notre DNS inverse est erroné. »

  Cause racine : PTR manquant, PTR pointant vers un nom qui ne résout pas en retour, ou changement d’IP sortante sans mise à jour du rDNS.

  Correction : Vérifiez avec dig -x et une résolution avant → après ; mettez à jour le PTR via le propriétaire de l’IP ; gardez le rDNS aligné avec l’identité d’envoi.

Listes de contrôle / plan étape par étape

Checklist : triage « le DNS est cassé » en 10 minutes

1. Notez précisément le nom et le type. Exemple : api.example.com AAAA, pas « le DNS de l’API ».
2. Interrogez le résolveur configuré du client. Confirmez la ligne SERVER et le statut (NOERROR/NXDOMAIN/SERVFAIL/timeout).
3. Interrogez deux résolveurs récursifs connus. S’ils divergent, vous avez des vues/politiques/caches différents.
4. Interrogez directement les serveurs autoritatifs. Si l’autoritatif est correct mais que le récursif est faux, cessez de changer les données de zone aveuglément.
5. Lancez +trace sur le nom problématique. Notez exactement quelle étape échoue.
6. Vérifiez les TTL (positifs et négatifs). Décidez si vous pouvez attendre ou si vous avez besoin d’un contournement.
7. Vérifiez A et AAAA séparément. Les surprises dual‑stack sont courantes et pénibles.
8. Si SERVFAIL, suspectez DNSSEC tôt. Validez la chaîne DS/DNSKEY au lieu de discuter avec les équipes applicatives.
9. Si lent/intermittent, suspectez la délégation/santé des NS. Testez chaque NS avec des requêtes SOA.
10. Enregistrez les preuves. Collez les sorties dig dans le document d’incident. Les discussions DNS s’éteignent vite quand vous montrez la chaîne.

Checklist : changement DNS planifié (pour ne pas créer la panne de la semaine prochaine)

1. Décidez du modèle de propagation. Réduction de TTL 24–48 heures avant cutover pour les noms à fort trafic est normale. Faites‑le délibérément.
2. Capturez des snapshots « avant » : SOA, NS, enregistrements cibles, et toute chaîne CNAME depuis les autoritatifs et au moins un résolveur récursif.
3. Faites une modification à la fois. Regrouper NS + DNSSEC + bascule de service est la recette du weekend.
4. Validez depuis plusieurs réseaux/résolveurs. Surtout si vous gérez du split-horizon ou des clients d’entreprise.
5. Gardez le rollback simple. Sachez vers quoi vous restaurerez les enregistrements, et comprenez que des caches existeront encore.
6. Après le changement, vérifiez la cohérence de la délégation. NS parent vs NS child doivent correspondre, et tous les NS doivent répondre de façon autoritative.

Vidage de cache (uniquement quand vous contrôlez la machine)

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

cr0x@server:~$ sudo resolvectl flush-caches

Signification : Sur les systèmes systemd‑resolved, cela vide le cache local. Cela ne résoudra pas les caches en amont sur des résolveurs récursifs que vous ne contrôlez pas.

Décision : Videz les caches locaux seulement pour valider une hypothèse ou pendant des tests contrôlés. En production, vous concevez généralement autour des caches plutôt que de les combattre.

FAQ

1) Quelle est la différence pratique entre dig et drill ?

dig (outils BIND) est ubiquitaire et adapté aux scripts. drill (de ldns) offre un bon comportement de traçage et des fonctionnalités de chase DNSSEC. En incident, utilisez ce qui est installé en premier — et gardez l’autre à portée quand vous avez besoin d’un second avis.

2) Quand dois‑je utiliser +trace ?

Quand vous suspectez des problèmes de délégation, des erreurs de registrar, des NS/glue incorrects, ou quand vous devez prouver où la chaîne casse. C’est aussi le moyen le plus rapide d’arrêter les débats « notre fournisseur DNS est en panne » quand la délégation parentale est le vrai souci.

3) Pourquoi un résolveur retourne une IP et un autre retourne NXDOMAIN ?

Causes courantes : vues split-horizon, RPZ/filtering, caches obsolètes (y compris caches négatifs), ou interrogation de noms différents à cause des suffixes de recherche. Interrogez directement les deux résolveurs et comparez les sections status, ANSWER et AUTHORITY.

4) Que signifie réellement SERVFAIL ?

Cela signifie « le résolveur n’a pas pu compléter la requête avec succès ». Cela peut venir de timeouts en amont, d’une échec de validation DNSSEC, d’une délégation lame, ou d’une surcharge du résolveur. SERVFAIL est un symptôme, pas un diagnostic — tracez et interrogez directement les autoritatifs.

5) Pourquoi je vois des enregistrements corrects sur l’autoritatif mais les clients obtiennent encore l’ancienne réponse ?

Des caches. Les résolveurs récursifs mettent en cache les réponses jusqu’à l’expiration du TTL. Les clients peuvent aussi mettre en cache. Votre « correction » est juste mais pas encore visible. Lisez les TTL depuis le résolveur que vos clients utilisent réellement et planifiez les changements selon les fenêtres TTL.

6) Comment prouver que DNSSEC est le problème sans outils spécialisés ?

Vérifiez si les résolveurs validants font SERVFAIL tandis que les résolveurs non‑validants (ou les requêtes directes vers l’autoritatif) renvoient des données. Inspectez ensuite DNSKEY/RRSIG sur les serveurs autoritatifs et le DS dans le parent via dig +trace DS. Cette combinaison suffit généralement à étayer le diagnostic.

7) Dois‑je toujours publier des enregistrements AAAA si j’ai IPv6 quelque part ?

Non. Publiez des AAAA quand le service est réellement et de manière fiable atteignable en IPv6 pour les utilisateurs qui en recevront l’avantage. Les déploiements IPv6 partiels créent des échecs lents qui semblent être des « instabilités applicatives » parce que les clients tentent souvent v6 en premier.

8) Qu’est‑ce qu’une « lame delegation » en termes pratiques ?

Un NS listé pour votre zone qui ne la sert pas réellement de façon autoritative (ou qui refuse/renvoie SERVFAIL). Les résolveurs perdent du temps dessus. Vous obtenez lenteurs intermittentes, retries, et parfois des échecs. Corrigez en retirant/réparant le serveur et en alignant les NS parent/enfant.

9) Pourquoi un enregistrement TXT de vérification apparaît pour moi mais pas pour le fournisseur ?

Soit vous interrogez des résolveurs différents avec des caches différents, soit vous l’avez publié dans la mauvaise zone/vue, soit vous avez créé NODATA (nom existe mais pas de TXT à ce nom) au lieu de l’enregistrement voulu. Demandez au fournisseur quel résolveur il utilise, puis interrogez ce résolveur directement.

10) Flusher les caches est‑ce une bonne réponse d’incident ?

Seulement si vous contrôlez le cache et que vous le faites pour valider une hypothèse. Vous ne pouvez pas vider les résolveurs du monde entier. La vraie compétence est de comprendre les TTL et de planifier des bascules sûres avec chevauchement.

Prochaines étapes que vous pouvez faire aujourd’hui

1. Adoptez l’habitude « preuves DNS ». Pendant les incidents, collez les sorties dig/drill montrant SERVER, le statut, le TTL et les réponses autoritatives. Ça raccourcit les réunions.
2. Standardisez une comparaison de résolveurs.Choisissez deux résolveurs publics et votre résolveur d’entreprise, et conservez un petit jeu de commandes pour les comparer rapidement.
3. Connaissez votre délégation.Pour les zones critiques, vérifiez périodiquement que NS parent correspond à NS child et que chaque NS répond de façon autoritative.
4. Révisez la stratégie TTL.TTL bas uniquement là où vous avez besoin d’un pilotage rapide ; des TTL raisonnables ailleurs pour réduire la charge sur les dépendances.
5. Rendez TCP/53 non négociable pour l’infrastructure DNS.Le DNS moderne (surtout avec DNSSEC) en a besoin quand l’UDP tronque.
6. Entraînez un rollback DNSSEC contrôlé.Pas pendant un incident. Sachez comment vous retireriez un DS et comment le rétablir en toute sécurité.

Le DNS n’est pas magique. C’est de la paperasserie avec des pertes de paquets. Utilisez les commandes ci‑dessous, localisez où la vérité diverge, et votre « mystère » deviendra une correction.