Surveillance DNS : Alertez avant que les utilisateurs ne s’en aperçoivent (Vérifications simples et efficaces)

Ce que vous surveillez réellement (et pourquoi le DNS vous trompe)

La surveillance DNS semble être une chose. En production, c’est au moins quatre :
DNS autoritatif (votre zone est servie correctement),
résolution récursive (les utilisateurs peuvent réellement la résoudre),
exactitude des enregistrements (les réponses pointent au bon endroit),
et sécurité des changements (vous ne le cassez pas pendant les mises à jour).

Le plus grand piège est de penser que « le DNS est en ligne » est un booléen. Le DNS est un système distribué, mis en cache et dépendant du temps. Il peut être « en ligne » dans un pays et « hors service » dans un autre.
Il peut être « en ligne » pour l’enregistrement exact que vous avez testé et « hors service » pour l’enregistrement que vos clients mobiles utilisent réellement. Il peut être « en ligne » pour des clients avec un cache chaud et « hors service »
pour de nouveaux résolveurs. Et il peut être « en ligne » jusqu’à l’expiration du TTL, puis devenir très hors service, très vite.

Les quatre couches qui échouent différemment

• Noms de serveurs autoritatifs : votre jeu de NS répond aux requêtes pour votre zone. Les échecs apparaissent sous forme de SERVFAIL, de délais d’attente, de mauvaises réponses, de délégations « lame », d’erreurs DNSSEC.
• Couche de délégation (registrar + zone parente) : la zone parente pointe vers vos enregistrements NS et glue. Les échecs se manifestent par une résolution intermittente ou un NXDOMAIN total selon le cache.
• Résolveurs récursifs : ce que la plupart des utilisateurs frappent réellement (résolveurs des FAI, résolveurs publics, résolveurs d’entreprise). Les échecs apparaissent comme des ralentissements, des réponses obsolètes ou des pics de SERVFAIL.
• Comportement client : les applications font leur propre mise en cache, certaines ignorent les TTL, d’autres préfèrent IPv6, certaines lancent A et AAAA différemment. Les échecs se manifestent sous forme d’incidents « ça marche sur mon laptop ».

Surveillez au minimum deux perspectives : la correction autoritative et l’expérience récursive utilisateur. Si vous n’en faites qu’une,
vos alertes seront soit tardives (autoritatif uniquement) soit vagues (récursif uniquement).

Une seule citation, parce que c’est opérationnellement vrai : « L’espoir n’est pas une stratégie. » — Vince Lombardi.
Les ingénieurs ne l’ont pas inventée, mais nous en faisons assurément notre credo.

Blague n°1 : le DNS, c’est comme un groupe de discussion—un mauvais participant (enregistrement NS) et soudain personne ne vous trouve, mais c’est toujours votre faute.

Faits DNS intéressants qui comptent dans les incidents

Certaines « anecdotes » deviennent très pratiques quand vous diagnosez une panne étrange. Voici des faits concrets qui reviennent souvent dans les postmortems.

1. Le DNS a été spécifié au début des années 1980 pour remplacer le modèle centralisé HOSTS.TXT. C’est pourquoi il est décentralisé et basé sur le cache, et pourquoi le débogage est intrinsèquement distribué.
2. UDP reste le transport par défaut pour la plupart des requêtes DNS car il est peu coûteux et rapide. Cela signifie aussi que la perte de paquets, la fragmentation et les problèmes MTU peuvent ressembler à un « DNS hors service ».
3. EDNS(0) existe parce que les payloads DNS classiques étaient trop petits. Il permet aux résolveurs d’annoncer des tailles UDP plus grandes, ce qui interagit avec des pare-feu qui détestent le « DNS volumineux ».
4. Le fallback TCP n’est pas optionnel dans la vraie vie. La troncation (TC=1) force TCP ; si votre réseau bloque TCP/53, certaines réponses échoueront de façon intermittente.
5. Le caching négatif existe. Les réponses NXDOMAIN peuvent être mises en cache selon le TTL négatif du SOA. Une mauvaise configuration brève peut vous hanter plus longtemps que vous ne le méritez.
6. Le TTL est consultatif, pas une loi morale. De nombreux résolveurs et clients plafonnent les TTL (min/max), et certaines applications cachent plus longtemps qu’elles ne devraient.
7. Les enregistrements glue existent parce que les nameservers ont aussi des noms. Si vos NS sont dans la zone qu’ils servent, le glue dans la zone parente empêche une dépendance circulaire.
8. DNSSEC concerne l’authenticité, pas la disponibilité. Quand ça casse (mauvais DS, signatures expirées), ça échoue souvent « durement » pour les résolveurs validants et ressemble à une panne aléatoire.
9. L’infrastructure racine et TLD est conçue pour la résilience (anycast, distribution massive). La plupart des pannes DNS sont auto-infligées au niveau de la délégation ou de la zone.

SLI et conception d’alertes qui ne vous font pas perdre la vie

Le but n’est pas de produire des graphiques. Le but est de détecter précocement les échecs de résolution impactant les utilisateurs, et d’orienter l’alerte vers une personne capable d’agir.
Cela signifie que vous avez besoin d’indicateurs qui représentent l’échec et la latence aux endroits qui correspondent à la réalité.

Choisissez des SLI qui correspondent à la douleur utilisateur

• Taux de succès récursif : pourcentage de requêtes qui retournent une chaîne A/AAAA/CNAME valide dans un délai depuis plusieurs points de vue.
• Latence récursive : p50/p95 du temps de requête vers les résolveurs récursifs (ou les vôtres). Les pics précèdent souvent les pannes.
• Disponibilité autoritative : taux de succès et latence lors de la requête directe à chaque NS autoritatif.
• Exactitude des réponses : les enregistrements retournés correspondent aux cibles attendues (plages IP, CNAMEs, hôtes MX) et aux limites de TTL attendues.
• Distribution des RCODE : pics de SERVFAIL, NXDOMAIN, REFUSED sont des signaux précoces.

Règles d’alerte que l’on peut aimer

Un ensemble pratique :

• Page sur échec impactant les utilisateurs : récursif succès < 99.5% pendant 5 minutes sur au moins deux régions, pour les noms critiques.
• Ticket sur augmentation de latence : récursif p95 > 250 ms pendant 15 minutes, ou augmentation soudaine de 3× la valeur de base.
• Page sur erreurs autoritatives : tout NS autoritatif en timeout > 20% sur 5 minutes, ou détection d’un mismatch SOA/NS.
• Ticket sur dérive d’exactitude : changements d’IP/CNAME inattendus, TTL hors politique, AAAA manquant là où requis, signature DNSSEC proche de l’expiration.

Gardez une petite allowlist de « noms qui comptent » : login, api, www, mail, et ce que votre application mobile hardcode. Surveillez-les sérieusement.
Ensuite surveillez la santé de la zone (SOA/NS/DNSKEY) comme si c’était vous qui alliez devoir vous lever si ça casse. Parce que c’est le cas.

Contrôles DNS simples et efficaces (avec commandes réelles)

Vous n’avez pas besoin d’une plateforme sophistiquée pour commencer. Vous avez besoin de commandes répétables, de sorties attendues et de décisions explicites.
Ci-dessous se trouvent des tâches pratiques que vous pouvez exécuter depuis un hôte Linux avec dig, delv et des outils basiques.
Les commandes sont volontairement franches. Elles doivent fonctionner quand votre cerveau tourne au ralenti.

Task 1: Confirmer que la résolution récursive fonctionne (baseline)

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

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

;; QUESTION SECTION:
;www.example.com.                IN      A

;; ANSWER SECTION:
www.example.com.         60      IN      A       203.0.113.10

;; Query time: 23 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Dec 31 12:00:00 UTC 2025
;; MSG SIZE  rcvd: 59

Ce que cela signifie : Vous avez obtenu NOERROR, un enregistrement A, et un temps de requête. C’est la base « la plupart des choses vont bien ».
Décision : Si cela échoue, arrêtez de deviner. Vous avez un problème de chemin résolveur, pas un problème applicatif.

Task 2: Forcer un résolveur récursif public connu (comparer les chemins)

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

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4011
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
www.example.com.         60      IN      A       203.0.113.10
;; Query time: 19 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

Ce que cela signifie : Si le résolveur local échoue mais qu’un résolveur public fonctionne, votre stub resolver local, DNS d’entreprise ou chemin réseau est cassé.
Décision : Orientez vers l’équipe qui gère l’infrastructure du résolveur/VPN/edge.

Task 3: Interroger chaque nameserver autoritatif directement (le DNS autoritatif est-il vivant ?)

cr0x@server:~$ dig +norecurse @ns1.example.net example.com SOA

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1209
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 3600 600 1209600 300
;; Query time: 14 msec

Ce que cela signifie : Le drapeau aa indique que le serveur est autoritatif et répond. Le serial SOA est visible.
Décision : Si un NS time out ou renvoie des serial différents des autres, vous avez probablement des problèmes de propagation/transfert de zone ou un nœud anycast mort.

Task 4: Vérifier que tous les NS sont d’accord sur le serial SOA (contrôle de cohérence)

cr0x@server:~$ for ns in ns1.example.net ns2.example.net ns3.example.net; do echo "== $ns =="; dig +norecurse +time=2 +tries=1 @$ns example.com SOA +short; done
== ns1.example.net ==
ns1.example.net. hostmaster.example.com. 2025123101 3600 600 1209600 300
== ns2.example.net ==
ns1.example.net. hostmaster.example.com. 2025123101 3600 600 1209600 300
== ns3.example.net ==
ns1.example.net. hostmaster.example.com. 2025123009 3600 600 1209600 300

Ce que cela signifie : ns3 est en retard (serial plus ancien). Cela peut provoquer des réponses différentes selon le NS interrogé.
Décision : Traitez-le comme un incident d’exactitude. Corrigez la distribution/transfert de zone ou votre pipeline de déploiement ; ne vous contentez pas de dire « ça va se propager ».

Task 5: Valider la délégation depuis la zone parente (attraper délégation lame et problèmes de glue)

cr0x@server:~$ dig +trace example.com NS

; <<>> DiG 9.18.24 <<>> +trace example.com NS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21044
...
example.com. 172800 IN NS ns1.example.net.
example.com. 172800 IN NS ns2.example.net.
example.com. 172800 IN NS ns3.example.net.
;; Received 117 bytes from a.gtld-servers.net#53(a.gtld-servers.net) in 28 ms

Ce que cela signifie : Vous pouvez voir la chaîne de délégation. Si elle s’arrête, boucle ou pointe vers le mauvais jeu de NS, votre délégation chez le registrar/la zone parente est incorrecte.
Décision : Si l’ensemble NS de la zone parente est mauvais, modifier votre fichier de zone ne servira à rien. Corrigez la délégation chez le registrar/fournisseur DNS.

Task 6: Vérifier les chaînes CNAME et les réponses « ont l’air correctes mais ne le sont pas »

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

www.example.com. 60 IN CNAME www.example.cdn-provider.net.
www.example.cdn-provider.net. 20 IN A 198.51.100.77

Ce que cela signifie : Le nom visible par l’utilisateur dépend du DNS d’un autre domaine. Si ce fournisseur rencontre des problèmes, vous les héritez.
Décision : Surveillez à la fois le nom vanity et la cible du fournisseur. Alertez sur l’un ou l’autre en cas d’échec, car les utilisateurs se moquent de la responsabilité.

Task 7: Mesurer explicitement le temps de requête (SLI latence depuis le shell)

cr0x@server:~$ dig @1.1.1.1 www.example.com A +stats +time=2 +tries=1 | tail -n 5
;; ANSWER SECTION:
www.example.com.         60      IN      A       203.0.113.10

;; Query time: 312 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

Ce que cela signifie : 312 ms est élevé pour beaucoup de régions. Cela peut être transitoire, ou lié à une perte de paquets forçant des retries ailleurs.
Décision : Si le p95 augmente, n’attendez pas les SERVFAIL. Commencez à vérifier le MTU du chemin, les changements de pare-feu, la charge du résolveur et le comportement EDNS.

Task 8: Détecter la troncation et les problèmes de fallback TCP

cr0x@server:~$ dig @8.8.8.8 DNSKEY example.com +dnssec +time=2 +tries=1

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6512
;; flags: qr rd ra tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: Message truncated

Ce que cela signifie : Le drapeau tc indique une troncation ; le résolveur réessaiera en TCP. Si TCP/53 est bloqué, les résolveurs validants peuvent échouer sévèrement.
Décision : Testez explicitement le TCP et ouvrez TCP/53 là où c’est nécessaire (surtout pour les réponses lourdes DNSSEC).

Task 9: Tester explicitement DNS sur TCP (prouver que le pare-feu ne l’ingère pas)

cr0x@server:~$ dig +tcp @8.8.8.8 DNSKEY example.com +dnssec +time=2 +tries=1 +stats | tail -n 6
;; ANSWER SECTION:
example.com.  1800 IN DNSKEY 257 3 13 rX9W...snip...
example.com.  1800 IN DNSKEY 256 3 13 dE2Q...snip...

;; Query time: 41 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (TCP)

Ce que cela signifie : Le TCP fonctionne ; la troncation est survivable. Si le TCP échoue, vous verrez des timeouts.
Décision : Si l’UDP marche mais le TCP échoue, corrigez le réseau. Si les deux échouent, corrigez le DNS ou le routage.

Task 10: Vérifier le comportement du cache négatif (NXDOMAIN qui colle)

cr0x@server:~$ dig +noall +authority does-not-exist.example.com A

example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 3600 600 1209600 300

Ce que cela signifie : Les réponses NXDOMAIN incluent le SOA de la zone ; le dernier champ (ici 300) est le TTL de cache négatif.
Décision : Si vous avez accidentellement supprimé un enregistrement puis l’avez remis, attendez-vous à ce que certains clients continuent d’échouer jusqu’à l’expiration du TTL négatif. Planifiez les changements en conséquence.

Task 11: Valider DNSSEC avec un outil validant (séparer « DNS en ligne » de « DNS valide »)

cr0x@server:~$ delv @1.1.1.1 example.com A

; fully validated
example.com. 300 IN A 203.0.113.20

Ce que cela signifie : « fully validated » indique que la chaîne DNSSEC valide depuis les ancres de confiance.
Décision : Si la validation échoue, traitez-le comme une haute sévérité pour les utilisateurs derrière des résolveurs validants (nombreuses entreprises). Corrigez vite DS/DNSKEY/RRSIG.

Task 12: Repérer des TTL trop bas (charge auto-infligée et jitter)

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

api.example.com. 5 IN A 203.0.113.44

Ce que cela signifie : Un TTL de 5 secondes est effectivement « s’il-vous-plaît, DDoSsez mes serveurs autoritatifs avec du trafic légitime ».
Décision : Remontez le TTL à quelque chose de raisonnable pour des endpoints stables (souvent 60–300 secondes pour les frontaux dynamiques, plus pour les statiques). N’utilisez un TTL faible qu’avec un plan.

Task 13: Vérifier le comportement multi-enregistrements (A et AAAA peuvent échouer indépendamment)

cr0x@server:~$ dig www.example.com A AAAA +noall +answer

www.example.com. 60 IN A 203.0.113.10
www.example.com. 60 IN AAAA 2001:db8:abcd::10

Ce que cela signifie : Le dual-stack est en place. Si AAAA est erroné ou pointe vers un chemin cassé, certains clients préféreront IPv6 et échoueront « aléatoirement ».
Décision : Surveillez séparément l’exactitude et la reachabilité des A et AAAA. Si vous ne pouvez pas opérer IPv6 correctement, ne publiez pas d’AAAA « pour plus tard ».

Task 14: Vérifier les surprises de split-horizon (réponses internes vs externes)

cr0x@server:~$ dig @10.0.0.53 www.example.com A +noall +answer
www.example.com. 60 IN A 10.20.30.40

Ce que cela signifie : Le résolveur interne retourne une IP privée. Cela peut être correct (routage interne) ou désastreux (fuite de réponses privées vers le public).
Décision : Confirmez que les vues sont intentionnelles. Ajoutez de la surveillance depuis l’intérieur et l’extérieur du réseau pour assurer que chaque audience obtient la réponse prévue.

Task 15: Confirmer l’identité du serveur autoritatif (êtes-vous connecté à la bonne machine ?)

cr0x@server:~$ dig +norecurse @ns1.example.net version.bind TXT chaos +short
"ns1-anycast-pop3"

Ce que cela signifie : Si activé, cela peut aider à identifier quel POP anycast vous sert. Tous les fournisseurs ne l’autorisent pas, et c’est acceptable.
Décision : Utilisez-le pour corréler des erreurs à un POP ou backend spécifique. S’il est désactivé, n’insistez pas ; fiez-vous à la latence, traceroutes et aux outils du fournisseur.

Task 16: Capturer RCODEs et timeouts à grande échelle (transformer des contrôles ponctuels en métriques)

cr0x@server:~$ for i in $(seq 1 20); do dig @1.1.1.1 +time=1 +tries=1 www.example.com A +noall +comments; done | egrep "status:|Query time:"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34325
;; Query time: 18 msec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2462
;; Query time: 21 msec
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 991
;; Query time: 1001 msec

Ce que cela signifie : Un SERVFAIL dans un petit échantillon est déjà suspect. Si vous voyez des SERVFAIL intermittents avec ~1s de timing, vous rencontrez des timeouts et des retries.
Décision : Traitez les erreurs intermittentes comme réelles. Elles deviennent des pannes sous charge ou lorsque les caches expirent.

Blague n°2 : la mise en cache DNS est le seul endroit où « ça marchait il y a cinq minutes » est une fonctionnalité de conception, pas une confession.

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

Quand le DNS brûle, la rapidité compte. Pas parce que vous êtes héroïque, mais parce que la mise en cache rend le rayon d’impact dépendant du temps. Voici l’ordre qui identifie les goulots rapidement.

Premier : Est-ce l’expérience utilisateur ou l’autoritatif ?

1. Interrogez un résolveur récursif public depuis au moins deux réseaux. S’il échoue largement, il s’agit probablement d’un problème autoritatif/délégation ou DNSSEC.
2. Interrogez vos NS autoritatifs directement avec +norecurse. Si l’autoritatif direct est OK mais que la récursion échoue, c’est un problème de l’écosystème résolveur (ou validation DNSSEC).
3. Vérifiez la distribution des RCODE : NXDOMAIN vs SERVFAIL vs timeout. Chacun pointe vers des causes différentes.

Deuxième : Identifiez la classe de défaillance

• Timeouts : chemin réseau, pare-feu, mauvais fonctionnement d’atténuation DDoS, problème de POP anycast, perte de paquets en amont.
• SERVFAIL : échec de validation DNSSEC, réponse autoritative cassée, résolveur incapable d’atteindre un NS, délégation lame, défaillance du backend.
• NXDOMAIN : enregistrement manquant, mauvaise zone déployée, faute de frappe dans le nom, cache négatif prolongeant l’impact, suffixe erroné interrogé, confusion split-horizon.
• Mauvaise réponse : zone obsolète sur un NS, fuite de vue (view leakage), automatisation défectueuse, cible CNAME changée, configuration compromise.

Troisième : Localisez où la chaîne casse

1. Exécutez +trace pour voir la délégation et où elle s’arrête.
2. Comparez le serial SOA sur tous les NS autoritatifs. Des serials incohérents expliquent les « seuls certains utilisateurs ».
3. Testez UDP et TCP (surtout pour DNSKEY/réponses volumineuses). Troncation + TCP bloqué est un classique.
4. Validez DNSSEC avec delv. Si la validation échoue, votre zone peut sembler « correcte » pour des résolveurs non validants tandis que des entreprises ne peuvent pas vous résoudre du tout.

Si vous exécutez ces étapes dans cet ordre, vous évitez deux pertes de temps communes : regarder les logs applicatifs quand la résolution de noms échoue, et débattre de la « propagation »
alors que vous avez en réalité un état autoritatif incohérent.

Trois mini-histoires d’entreprise venues des tranchées DNS

Mini-histoire 1 : La panne causée par une mauvaise hypothèse

Une société SaaS de taille moyenne a migré son site marketing vers un nouveau CDN. La demande de changement était simple : remplacer un A par un CNAME,
baisser le TTL pour le basculement, et considérer l’affaire réglée. L’ingénieur a supposé que « si le CNAME se résout pour moi, il se résout pour tout le monde ».
Cette hypothèse a fait perdre de nombreuses soirées paisibles.

La bascule semblait bien se passer depuis le réseau du bureau. Elle semblait correcte depuis un résolveur public. Mais des clients d’entreprise ont commencé à signaler des échecs :
les navigateurs restaient bloqués un moment, puis abandonnaient. Le canal d’incident se remplit de captures d’écran et de conjectures. L’application était saine ; l’origine était saine ; TLS était sain.
Le seul facteur commun était « impossible d’atteindre le site ».

Il s’est avéré que le nom cible du CDN retournait un grand ensemble d’enregistrements avec DNSSEC, provoquant la troncation. Certains réseaux d’entreprise autorisaient UDP/53 mais bloquaient TCP/53
(oui, encore). Pour ces utilisateurs, le résolveur récursif voyait TC=1, essayait TCP, se heurterait au blocage et renvoyait SERVFAIL. Les utilisateurs domestiques n’ont jamais remarqué car leurs résolveurs pouvaient utiliser TCP.

La correction n’était pas dans la pile web. C’était une correction de politique et de surveillance : tester DNS sur TCP dans les contrôles synthétiques, surveiller les taux de SERVFAIL depuis des points de vue « corporate-ish »,
et ajouter une étape de prévalidation pour « ce changement augmente-t-il la taille de réponse ou la complexité DNSSEC ». L’hypothèse est morte. La production s’est améliorée.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une autre entreprise faisait tourner son propre DNS autoritatif sur deux clusters anycastés. Quelqu’un a remarqué une part mesurable de latence sur les lookups à froid
et a décidé « d’optimiser le DNS » en fixant les TTL à 10 secondes partout. La théorie : basculement plus rapide pendant les incidents et déploiements plus rapides.
La réalité : le DNS n’est pas un système de feature flags. C’est un multiplicateur de charge.

Ça n’a pas explosé immédiatement. C’est la pire partie. Pendant quelques jours, tout semblait plus réactif pendant un rollout et le changement a été loué comme « plus dynamique ».
Puis une augmentation normale du trafic est survenue : pas un DDoS, juste une croissance normale liée à une campagne marketing. Les caches des résolveurs expiraient constamment, le volume de requêtes autoritatives a augmenté,
et les clusters anycast ont commencé à laisser tomber des paquets sous charge de pointe. Les timeouts ont augmenté, puis les retries ont augmenté, puis les retries ont créé plus de charge. Boucle de rétroaction classique.

Les utilisateurs ont vécu des échecs intermittents difficiles à reproduire. Certains avaient des réponses en cache ; d’autres étaient malchanceux. Une surveillance qui ne vérifiait qu’un seul résolveur
et un seul nom a manqué l’alerte précoce. Il a fallu trop de temps pour relier les points : « l’optimisation » rendait le DNS dépendant d’une performance autoritative parfaite.

Le rollback a été simple : restaurer des TTL raisonnables (60–300 secondes pour les front doors ; plus long si possible), et ajouter des alertes basées sur le QPS autoritatif et les taux d’erreur.
Ils ont aussi conservé un petit ensemble d’enregistrements à faible TTL pour de vrais scénarios de basculement, sous contrôle de changement. La leçon : optimisez pour la résilience, pas pour la dopamine du changement rapide.

Mini-histoire 3 : La pratique ennuyeuse qui a sauvé la mise

Une entreprise multi-divisionnaire avait l’habitude, apparemment ennuyeuse : chaque changement DNS nécessitait une « validation deux-vues » et une « validation deux-résolveurs ».
Cela signifiait vérifier les réponses internes et externes, et vérifier au moins deux résolveurs récursifs différents (un corporate, un public).
C’était documenté, imposé en revue de code, et parfois moqué comme bureaucratie.

Un vendredi, une équipe a ajouté un nouveau nom interne-only pour un service. Le changement devait atterrir uniquement dans la vue interne,
mais une variable de template a été mal réglée. L’enregistrement a été ajouté à la zone externe aussi, pointant vers une adresse RFC1918 privée.
Si cela s’était propagé largement, les utilisateurs externes auraient tenté de se connecter à une IP privée non routable—au mieux un timeout, au pire atteignant quelque chose d’inattendu sur leur réseau local.

Les précontrôles l’ont détecté en quelques minutes. La vérification externe a vu un A privé et a échoué bruyamment. Le changement a été reverté avant que les caches ne se propagent largement.
Le ticket d’incident n’est jamais devenu un incident client. L’équipe a pu profiter du week-end, ce qui est le vrai KPI SRE.

La pratique ennuyeuse n’était pas flashy. C’était juste une validation spécifique et répétable qui correspondait aux modes de défaillance connus. Elle n’a pas empêché les erreurs.
Elle a empêché les erreurs de devenir des pannes.

Erreurs courantes : symptôme → cause racine → correction

Les incidents DNS sont répétitifs. Les erreurs le sont aussi. Voici les plus courantes avec un mappage clair entre ce que vous voyez et ce qu’il faut faire.

1) Symptom: « Ça marche pour moi, cassé pour les utilisateurs »

• Cause racine : réponses en cache sur votre réseau ; certains résolveurs ont encore de vieilles données ; NS autoritatifs incohérents ; différences split-horizon.
• Correction : comparez le serial SOA sur tous les NS autoritatifs ; interrogez plusieurs résolveurs récursifs ; baissez le TTL avant les migrations planifiées, pas pendant une urgence.

2) Symptom: SERVFAIL intermittent, surtout chez les entreprises

• Cause racine : échec de validation DNSSEC (RRSIG expiré, DS incorrect), ou troncation nécessitant TCP qui est bloqué.
• Correction : exécutez delv pour valider ; testez dig +tcp ; corrigez le processus de rollover DS/DNSKEY ; assurez-vous que TCP/53 fonctionne de bout en bout.

3) Symptom: Pics de NXDOMAIN après un déploiement

• Cause racine : enregistrement supprimé/renommé ; mauvaise zone déployée ; faute de frappe ; cache négatif prolongeant l’impact.
• Correction : restaurez l’enregistrement ; confirmez l’incrément du serial SOA ; comprenez le TTL négatif dans le SOA ; surveillez le taux de NXDOMAIN par nom.

4) Symptom: Résolution lente mais sans échouer

• Cause racine : perte de paquets ; résolveurs surchargés ; connectivité amont ; problèmes de taille UDP EDNS entraînant retries/fallback.
• Correction : mesurez la latence p95 ; testez avec différents résolveurs ; vérifiez la troncation ; ajustez la taille EDNS si vous gérez des résolveurs ; corrigez la perte réseau.

5) Symptom: Seuls les utilisateurs IPv6 échouent (ou certains réseaux mobiles)

• Cause racine : enregistrement AAAA cassé ou routage IPv6 défectueux ; préférences clients pour IPv6 ; reachabilité asymétrique.
• Correction : surveillez l’AAAA séparément ; validez la reachabilité des endpoints IPv6 ; retirez l’AAAA si vous ne pouvez pas le supporter (temporairement, avec un plan).

6) Symptom: Un enregistrement spécifique échoue, tout le reste fonctionne

• Cause racine : problème du domaine cible CNAME ; enregistrement trop volumineux ; mauvais type d’enregistrement ; interactions avec des wildcards.
• Correction : surveillez et testez toute la chaîne ; gardez les jeux d’enregistrements petits ; évitez les setups wildcard sophistiqués à moins d’aimer les mystères.

7) Symptom: Certains résolveurs reçoivent REFUSED

• Cause racine : ACL sur les serveurs autoritatifs ; limitation de taux trop agressive ; géo-blocage ; vues mal configurées.
• Correction : révisez les ACL et la politique de réponse ; ajustez le RRL ; testez depuis plusieurs régions ; ne bloquez pas les résolveurs récursifs que vous ne contrôlez pas sauf obligation légale.

8) Symptom: Les changements de zone se « réversent » ou diffèrent entre NS

• Cause racine : multiples sources de vérité ; déploiements partiels ; NOTIFY/AXFR/IXFR cassés ; modifications manuelles sur un seul nœud.
• Correction : imposez une source de vérité unique ; automatisez le déploiement ; auditez les zones sur tous les NS ; alertez immédiatement sur mismatch SOA.

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

A. Construire un ensemble minimal de surveillance DNS (une après-midi, sans drame)

1. Choisissez 5–10 noms critiques : www, api, login, mail, plus les endpoints mobiles.
2. Pour chaque nom, définissez les réponses attendues : plages A/AAAA, cibles CNAME, hôtes MX, limites de TTL.
3. Exécutez des contrôles récursifs depuis au moins deux réseaux (région cloud A et B ; ou cloud + on-prem).
4. Exécutez des contrôles autoritatifs contre chaque NS directement avec +norecurse.
5. Alertez sur les échecs : timeouts, SERVFAIL, mauvaises réponses et mismatch de serial SOA.
6. Tableau de bord des RCODE et latence par nom, pas seulement agrégé sur toute la zone.

B. Rendre les changements DNS plus sûrs (le plan « ne soyez pas malin »)

1. Baissez le TTL avant les migrations planifiées (heures à un jour avant), pas en plein incident.
2. Utilisez des rollouts par paliers : validez d’abord sur un nom canary (ex. canary-api).
3. Validation deux-vues : les réponses internes et externes doivent être intentionnellement différentes, jamais par accident.
4. Validation deux-résolveurs : testez à la fois un chemin résolveur corporate et un résolveur public.
5. Discipline du serial SOA : imposez des serials monotones et alertez sur mismatch entre NS.
6. Hygiène DNSSEC : suivez l’expiration des signatures et les rollovers DS/DNSKEY avec des runbooks explicites.

C. Routage d’alerte prêt pour la production

1. Pagez l’équipe qui peut corriger : équipe fournisseur DNS, réseau ou plateforme. Si l’alerte n’est pas actionnable, c’est du bruit.
2. Incluez des commandes immédiates dans l’alerte : « Run dig +trace », « Query each NS for SOA », « Run delv ».
3. Incluez attendu vs réel dans la charge utile de l’alerte : détails de mismatch d’enregistrements, valeurs TTL, et quels résolveurs ont échoué.
4. Corrélez avec les fenêtres de changement : les incidents DNS sont souvent corrélés à des changements ; votre alerte doit montrer les pushes DNS récents.

FAQ

1) Dois-je surveiller le DNS depuis ma VPC, depuis l’internet public, ou les deux ?

Les deux. L’interne détecte les erreurs split-horizon et les problèmes de résolveur dans votre environnement. L’externe capture ce que voient les clients. Un seul point de vue, et vous êtes surpris.

2) Quel est le contrôle DNS le plus utile en une seule action ?

Interroger chaque nameserver autoritatif pour le SOA et comparer les serials. C’est le moyen le plus rapide de détecter des déploiements partiels, des transferts cassés et les incidents « certains utilisateurs seulement ».

3) « dig depuis une seule machine » n’est-il pas suffisant ?

Non. Les pannes DNS sont souvent régionales, spécifiques au résolveur ou dépendantes du cache. Une seule machine vous donne une fausse confiance ou une fausse panique, selon son cache et son réseau.

4) Comment alerter sur des problèmes de « propagation » ?

Arrêtez d’appeler ça propagation et appelez-le pour ce que c’est : état autoritatif incohérent ou mismatch de délégation. Alertez sur le mismatch de serial SOA et sur les réponses différentes entre NS.

5) Quelle doit être la valeur basse du TTL pour des frontaux de load balancer ?

Couramment 60–300 secondes. Baissez seulement si vous avez une procédure de basculement testée et une capacité autoritative pour gérer l’augmentation de QPS. « 5 secondes partout » sent la mauvaise fiabilité.

6) Pourquoi je vois SERVFAIL quand le serveur autoritatif semble OK ?

Souvent la validation DNSSEC échoue au niveau du résolveur, ou le résolveur ne peut pas atteindre un de vos NS pour des raisons réseau. Testez avec delv et interrogez chaque NS directement.

7) Dois-je vraiment me soucier de TCP/53 ?

Oui. Les réponses DNSKEY, les TXT volumineux et DNSSEC peuvent déclencher la troncation. Si le TCP est bloqué, certains résolveurs échoueront. Surveillez les chemins UDP et TCP.

8) Comment détecter automatiquement les problèmes de « mauvaise réponse » ?

Définissez des valeurs attendues : cibles CNAME, plages IP et limites TTL. Ensuite lancez des requêtes synthétiques et différez la section answer. Alertez sur la dérive, pas seulement sur les pannes.

9) Qu’en est-il du DNS over HTTPS (DoH) et DNS over TLS (DoT) ?

Si votre base d’utilisateurs inclut des environnements qui forcent DoH/DoT, incluez au moins un contrôle synthétique via ces chemins. Sinon vous risquez de clore la victoire pendant que les navigateurs échouent.

10) Combien de noms dois-je surveiller sans être noyé par les alertes ?

Commencez par 5–10 noms critiques plus des contrôles de santé de zone. Élargissez seulement si vous pouvez expliquer quelle action chaque alerte déclenche. La surveillance n’est pas du collectionnisme.

Conclusion : prochaines étapes réalisables cette semaine

La surveillance DNS n’a pas besoin d’être complexe. Elle doit être spécifique. Surveillez les noms qui comptent, depuis plus d’un point de vue, et testez à la fois la récursion et l’autorité.
Alertez sur les modes de défaillance qui prédisent une vraie douleur : mismatch SOA, pics de SERVFAIL, timeouts, mauvaises réponses et échecs de validation DNSSEC.

Prochaines étapes pratiques :

1. Implémenter des contrôles de cohérence du serial SOA sur tous les NS autoritatifs et pagez en cas de mismatch.
2. Ajouter des contrôles récursifs depuis deux réseaux et alerter sur un taux d’échec soutenu et la latence p95.
3. Ajouter des contrôles DNS UDP+TCP pour au moins une requête lourde DNSSEC (DNSKEY) afin d’attraper la troncation/blocage TCP.
4. Définir les réponses attendues et la politique TTL pour vos noms critiques, et alerter sur la dérive.
5. Rédiger un runbook d’une page pour un diagnostic DNS rapide en utilisant le playbook ci‑dessus, et l’attacher aux alertes.

Si vous faites juste cela, vous attraperez la plupart des pannes DNS avant que vos clients ne les remarquent. Et si vous avez de la chance, avant que votre PDG ne s’en aperçoive.