DNS : votre domaine fonctionne… jusqu’à ce qu’il cesse — le piège de la délégation expliqué

Délégation : ce que cela signifie réellement sur le fil

On parle du DNS comme s’il s’agissait d’une base de données que vous mettez à jour et que tout le monde voit magiquement la nouvelle vérité.
En pratique, c’est une chasse au trésor. Un résolveur récursif démarre à la racine, descend vers le TLD,
passe par la zone parente de votre domaine, et n’apprend les serveurs autoritatifs de votre domaine qu’ensuite.
Cette étape « apprendre où aller » est la délégation.

La délégation n’est pas votre fichier de zone. La délégation, c’est l’ensemble NS publié par la zone parente pour votre domaine,
plus les éventuels enregistrements glue (A/AAAA chez le parent) nécessaires pour atteindre ces serveurs de noms.
Votre fichier de zone peut être impeccable, et Internet peut quand même se diriger vers la mauvaise porte.

Le parent et l’enfant : deux sources de vérité qui doivent s’accorder

Pour example.com, le parent est .com. Le parent publie :

• Des enregistrements NS au point de délégation : quels serveurs autoritatifs doivent être interrogés.
• Des enregistrements glue (parfois) : adresses IP pour les serveurs de noms qui sont à l’intérieur de la zone déléguée (in-bailiwick).
• Un enregistrement DS (si DNSSEC) : le lien de chaîne de confiance vers le DNSKEY de la zone enfant.

La zone enfant (votre fichier de zone sur vos serveurs autoritatifs) publie :

• Son propre ensemble NS : ce qu’elle affirme être ses serveurs de noms autoritatifs.
• Tout le reste : A/AAAA, MX, TXT, CNAME, etc.
• Les enregistrements DNSKEY (si DNSSEC), et les signatures (RRSIG).

Si l’ensemble NS du parent et celui de l’enfant ne concordent pas, vous pouvez vous retrouver en situation de « délégation scindée » :
certains résolveurs suivent une voie, d’autres une autre, et les caches figent la divergence.
Si le glue est incorrect, vous pouvez avoir un nom NS correct pointant vers une IP injoignable. Si le DS est erroné,
vous pouvez subir des échecs sévères (SERVFAIL) même si les enregistrements sont présents.

Vérité sèche : la délégation est un système distribué. Les systèmes distribués ne « propagent » pas, ils
convergent — parfois lentement, parfois jamais, à moins que vous ne corrigiez l’incohérence.

Pourquoi la délégation échoue en production (même quand votre zone est parfaite)

1) L’interface du registrar n’est pas le DNS

L’interface de votre registrar est un plan de contrôle. La délégation réelle vit dans la zone parente du registre.
Beaucoup de registrars font ce qu’il faut. Certains le font finalement. D’autres le font après que vous ayez cliqué « enregistrer » deux fois
et attendu un job en arrière-plan qui tourne sur un serveur redémarré la dernière fois pendant une réunion budgétaire.

Pire : les registrars acceptent parfois des états invalides (comme l’absence de glue pour des noms NS in-bailiwick),
ou ils normalisent et réordonnent les enregistrements d’une manière qui surprend l’automatisation.

2) Les enregistrements glue : l’annuaire « juste assez » qui peut devenir obsolète

Le glue existe pour briser la dépendance circulaire. Si votre domaine est example.com et qu’un de vos
serveurs de noms est ns1.example.com, un résolveur ne peut pas résoudre ns1.example.com
sans d’abord pouvoir résoudre example.com. C’est la récursion qui se mord la queue.
Le glue, c’est le parent qui fournit directement l’IP.

Le glue est aussi un piège : les gens changent les IP des serveurs de noms et oublient le glue au parent. La zone enfant est mise à jour,
mais les résolveurs continuent d’utiliser l’ancien glue. Ou pire : seuls certains résolveurs le font — parce que les caches diffèrent, et
certains résolveurs sont plus agressifs pour effectuer des recherches « aidantes ».

3) DNSSEC : la délégation échoue en mode fermé

DNSSEC ajoute de l’intégrité, et ça en vaut la peine. Mais DNSSEC rend les erreurs plus bruyantes. Un enregistrement DS obsolète dans le
parent qui ne correspond plus au KSK de l’enfant signifie que les validateurs rejettent vos réponses. Les résolveurs non-validants peuvent encore fonctionner.
C’est votre classique panne « ça marche chez moi » avec une conclusion cryptographique.

4) Mise en cache négative : votre correction est correcte, mais Internet est toujours fâché

Les résolveurs mettent en cache le non aussi volontiers que le oui. Si un résolveur a demandé
A www.example.com et a reçu NXDOMAIN, il peut mettre ce résultat en cache pendant le TTL négatif (depuis le SOA).
Cela signifie que vous pouvez corriger un enregistrement et avoir quand même des clients jurant que c’est cassé pendant des minutes à des heures.

5) Anycast, load balancers et topologies NS « astucieuses »

De nombreux fournisseurs DNS autoritatifs utilisent l’anycast, ce qui est excellent quand c’est bien fait. Mais si vous gérez vos propres NS et les placez derrière un
load balancer qui effectue des vérifications de santé en TCP/53 alors que vos clients utilisent majoritairement UDP/53, vous vous exposez à un incident.

6) Incohérences dans la zone enfant : serials, NOTIFY et masters cachés

La délégation peut être correcte, mais vos serveurs autoritatifs peuvent être en désaccord. Vous avez mis à jour le primaire, un secondaire est obsolète,
et votre ensemble NS envoie des résolveurs vers les deux. Certains utilisateurs obtiennent la nouvelle réponse, d’autres l’ancienne, et tout le monde blâme « la propagation ».
Le terme correct est « vous avez une autorité incohérente ».

Blague n°1 : la propagation DNS est comme les commérages de bureau — tout le monde finit par l’entendre, mais pas dans le même ordre, et rarement avec le sens d’origine intact.

Faits et histoire qui expliquent les bizarreries d’aujourd’hui

• 1983 : Le DNS (RFC 882/883, ensuite remplacé) a été conçu pour remplacer un unique fichier HOSTS.TXT — la délégation était la fonctionnalité d’évolutivité.
• Les serveurs racine ne sont pas « un seul serveur » : il y a 13 lettres racines logiques, mais chacune est anycastée sur de nombreux sites dans le monde.
• Le glue est volontairement limité : les zones parentes fournissent du glue uniquement pour les serveurs in-bailiwick afin d’éviter de devenir un annuaire d’adresses généraliste.
• Le bailiwick checking existe pour la sécurité : les résolveurs traitent le glue différemment selon qu’il est dans l’autorité qu’ils interrogent.
• Le DNS a été conçu pour UDP : le fallback TCP existe, mais de nombreux réseaux gèrent encore mal TCP/53, rendant les réponses volumineuses (DNSSEC !) fragiles.
• EDNS(0) a changé la donne : il permet des charges UDP plus grandes, mais les middleboxes suppriment parfois les UDP fragmentés, provoquant des échecs « aléatoires ».
• DNSSEC (années 1990–2000) : ajoute signatures et clés ; le point de délégation utilise DS pour relier la confiance parent-enfant.
• Le TTL n’est pas une promesse : c’est un indice ; certains résolveurs plafonnent les TTL ou appliquent des politiques locales, donc la convergence est plus chaotique que votre feuille de calcul.
• NXDOMAIN peut être réécrit « aidamment » : certains fournisseurs utilisaient historiquement du wildcarding au niveau du TLD ou du résolveur ; votre débogage peut se heurter à des mensonges.

Une vérité opérationnelle a survécu à toutes les évolutions du DNS : le chemin compte autant que les données.
La délégation, c’est le chemin.

Mode opératoire de diagnostic rapide (premier/deuxième/troisième)

Quand un domaine « fonctionne en partie », votre travail est de trouver où la résolution diverge. Ne commencez pas par
regarder votre fichier de zone. Commencez par prouver ce qu’on dit au monde.

Premier : déterminer s’il s’agit de délégation, d’autorité ou de validation

1. Vérifier avec trace : Le résolveur trouve-t-il le bon ensemble NS depuis le parent ?
   Si non, c’est la délégation (registrar/registry/glue/DS).
2. Interroger chaque serveur autoritatif directement : Tous les serveurs autoritatifs répondent-ils de la même façon ?
   Si non, c’est une cohérence de zone/transfert/déploiement.
3. Vérifier DNSSEC et les codes de réponse : SERVFAIL chez les résolveurs validants mais succès chez les non-validants suggère un problème de chaîne DNSSEC.

Deuxième : rechercher des motifs « certaines réseaux seulement »

• Fonctionne sur un FAI, échoue sur un autre : probablement différences de cache ou différences de validation DNSSEC.
• Fonctionne en IPv4 mais pas en IPv6 : problèmes AAAA, glue v6 cassé, ou autoritatif v6 injoignable.
• Fonctionne depuis votre laptop, échoue depuis une région de monitoring : différences de routage anycast ou règles de pare-feu géographiques.

Troisième : décider si vous pouvez atténuer rapidement

• Atténuation temporaire : réajouter un NS fonctionnel dans la délégation parent ; réduire le rayon d’impact.
• Correction : corriger glue/DS/NS et attendre la vidange des caches ; communiquer la fenêtre de récupération attendue.
• Si DNSSEC est cassé : réparer DS/clés rapidement ou retirer DS (coordonné), mais ne le faites pas à moitié.

Idée paraphrasée (attribuée) : Werner Vogels a longtemps poussé l’idée que vous devriez « concevoir pour la panne » comme état normal, pas comme exception.

Tâches pratiques : commandes, sorties attendues et ce que vous décidez

Ci‑dessous des tâches pratiques que vous pouvez lancer depuis une machine Linux. Chacune inclut ce que la sortie vous dit
et la décision que vous en tirez. Ce ne sont pas des commandes pour s’amuser ; ce sont celles que vous utilisez à 2 h du matin
quand Slack est en feu.

Task 1: Confirm the parent delegation NS set (with trace)

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

; <<>> DiG 9.18.24 <<>> +trace example.com NS
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
;; Received 811 bytes from 127.0.0.53#53(127.0.0.53) in 1 ms

com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
;; Received 1171 bytes from 198.41.0.4#53(a.root-servers.net) in 18 ms

example.com.		172800	IN	NS	ns1.dns-host.net.
example.com.		172800	IN	NS	ns2.dns-host.net.
;; Received 212 bytes from 192.5.6.30#53(a.gtld-servers.net) in 22 ms

Ce que cela signifie : Cela montre ce que la zone parente publie comme ensemble NS de délégation.
Le TTL ici est le TTL du parent, pas celui de votre zone.

Décision : Si ces noms NS ne sont pas ceux que vous attendez, cessez de blâmer vos serveurs autoritatifs.
Corrigez la délégation chez le registrar/registry. S’ils sont corrects, passez à la vérification du glue et de la cohérence de la zone enfant.

Task 2: Check for glue at the parent (in-bailiwick case)

cr0x@server:~$ dig @a.gtld-servers.net example.com NS +norecurse +authority +additional

; <<>> DiG 9.18.24 <<>> @a.gtld-servers.net example.com NS +norecurse +authority +additional
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; AUTHORITY SECTION:
example.com.	172800	IN	NS	ns1.example.com.
example.com.	172800	IN	NS	ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.	172800	IN	A	203.0.113.10
ns2.example.com.	172800	IN	A	203.0.113.11

Ce que cela signifie : Le parent fournit des enregistrements glue A pour ns1.example.com/ns2.example.com.
Si les IP sont incorrectes, les résolveurs peuvent ne jamais atteindre vos serveurs autoritatifs.

Décision : Si le glue est erroné, mettez à jour les objets hôtes / glue chez le registrar. Mettre à jour la zone enfant ne le corrigera pas.

Task 3: Verify the child zone’s NS set matches the parent delegation

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

example.com.	3600	IN	NS	ns1.example.com.
example.com.	3600	IN	NS	ns2.example.com.

Ce que cela signifie : C’est ce que la zone enfant affirme être autoritatif. Le TTL provient de votre zone.

Décision : Si l’ensemble NS de l’enfant diffère de celui du parent, corrigez-le. Ne laissez pas d’NS « en surnombre » dans l’enfant ou le parent par habitude.
La cohérence compte plus que l’optimisme.

Task 4: Query every authoritative nameserver directly for the problem record

cr0x@server:~$ for ns in ns1.example.com ns2.example.com; do echo "== $ns =="; dig @"$ns" www.example.com A +noall +answer; done
== ns1.example.com ==
www.example.com.	300	IN	A	198.51.100.20
== ns2.example.com ==
www.example.com.	300	IN	A	198.51.100.21

Ce que cela signifie : Vos serveurs autoritatifs sont en désaccord. Ce n’est pas de la propagation ; c’est de l’incohérence.

Décision : Corrigez la distribution de la zone (AXFR/IXFR, push API, pipeline master caché), puis revérifiez. Ne passez pas à « attendre ».

Task 5: Check SOA serials across authoritative servers

cr0x@server:~$ for ns in ns1.example.com ns2.example.com; do dig @"$ns" example.com SOA +noall +answer; done
example.com.	3600	IN	SOA	ns1.example.com. hostmaster.example.com. 2026020401 7200 3600 1209600 300
example.com.	3600	IN	SOA	ns1.example.com. hostmaster.example.com. 2026020304 7200 3600 1209600 300

Ce que cela signifie : Des serials différents signifient que tous les serveurs n’ont pas la même version de zone.

Décision : Analysez les transferts/mises à jour. Si vous ne pouvez pas réparer rapidement l’autoritatif obsolète, retirez-le de la délégation jusqu’à ce qu’il soit sain.

Task 6: Check DNSSEC DS record at the parent

cr0x@server:~$ dig @a.gtld-servers.net example.com DS +noall +answer

example.com.	86400	IN	DS	12345 13 2 4C2B9D3C8B4E9B0F0F3E2C2B2D1A9A0D0B2A6F9E6E7C0A1B2C3D4E5F6789

Ce que cela signifie : Le parent indique que la zone enfant doit valider avec ce digest DS.

Décision : Si vous avez récemment fait une rotation de clés ou changé de fournisseur DNS, vérifiez que le DS correspond au KSK actuel. Sinon, corrigez le DS ou vous continuerez d’avoir des échecs de validation.

Task 7: Confirm DNSKEY at the child (and that it exists where you think)

cr0x@server:~$ dig @ns1.example.com example.com DNSKEY +noall +answer | head -n 3
example.com.	3600	IN	DNSKEY	257 3 13 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
example.com.	3600	IN	DNSKEY	256 3 13 yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy=

Ce que cela signifie : Présence des enregistrements KSK (257) et ZSK (256). Cela ne prouve pas la correction, mais l’absence est un crater fumant.

Décision : Si DNSKEY est absent mais que DS existe au parent, attendez-vous à SERVFAIL pour les validateurs. Publiez DNSKEY/signez la zone ou retirez DS.

Task 8: Validate as a resolver would (check AD flag via a validating resolver)

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

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40251
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1
www.example.com.	300	IN	A	198.51.100.20

Ce que cela signifie : Le drapeau ad indique que le résolveur considère la réponse comme authentifiée (validation DNSSEC).

Décision : Si vous obtenez SERVFAIL ici mais que vos réponses autoritatives semblent correctes, il s’agit probablement d’un
décalage DS/DNSKEY/RRSIG ou d’une chaîne cassée.

Task 9: Compare behavior across resolvers (spot “some networks only”)

cr0x@server:~$ for r in 1.1.1.1 8.8.8.8 9.9.9.9; do echo "== $r =="; dig @"$r" www.example.com A +time=2 +tries=1 +noall +answer +comments; done
== 1.1.1.1 ==
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27364
www.example.com.	300	IN	A	198.51.100.20
== 8.8.8.8 ==
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58312
== 9.9.9.9 ==
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11427
www.example.com.	300	IN	A	198.51.100.20

Ce que cela signifie : Des résultats divergents suggèrent des différences de validation, des états de cache ou des problèmes d’atteignabilité vers un site anycast autoritatif.

Décision : Si seuls certains résolveurs validants échouent, suspectez des cas limites DNSSEC ou des tailles de paquets/fragmentation. Si un seul échoue, vérifiez le chemin de ce résolveur vers vos NS.

Task 10: Check for UDP truncation (TC bit) and TCP fallback

cr0x@server:~$ dig @ns1.example.com example.com DNSKEY +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61643
;; flags: qr aa; QUERY: 1, ANSWER: 0
;; WARNING: Message parser reports malformed message packet.

cr0x@server:~$ dig +tcp @ns1.example.com example.com DNSKEY +noall +answer | head -n 2
example.com.	3600	IN	DNSKEY	257 3 13 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
example.com.	3600	IN	DNSKEY	256 3 13 yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy=

Ce que cela signifie : Les réponses DNSSEC volumineuses peuvent provoquer une troncation ou des anomalies de middlebox. Le TCP qui réussit alors que l’UDP échoue est un signal d’alerte.

Décision : Assurez-vous que l’autoritatif supporte correctement EDNS, autorisez UDP fragmenté si possible, et garantissez l’atteignabilité de TCP/53. Si vous ne pouvez pas garantir l’UDP, votre déploiement DNSSEC sera fragile.

Task 11: Verify NS reachability on UDP and TCP from your vantage point

cr0x@server:~$ nc -vz -u ns1.example.com 53
Connection to ns1.example.com 53 port [udp/domain] succeeded!

cr0x@server:~$ nc -vz ns1.example.com 53
Connection to ns1.example.com 53 port [tcp/domain] succeeded!

Ce que cela signifie : Cela vérifie l’atteignabilité basique. Cela ne confirme pas le comportement DNS correct, mais exclut des filtrages évidents.

Décision : Si l’UDP échoue mais que le TCP fonctionne, attendez-vous à des résolutions intermittentes et des timeouts. Corrigez les ACL réseau/groupes de sécurité/pare-feu avant de changer les enregistrements DNS.

Task 12: Find the authoritative set as seen by a recursive resolver

cr0x@server:~$ dig @1.1.1.1 example.com NS +noall +answer
example.com.	172800	IN	NS	ns1.example.com.
example.com.	172800	IN	NS	ns2.example.com.

Ce que cela signifie : Le récursif vous dit quel ensemble NS il considère autoritatif (depuis la délégation en cache).

Décision : Si cela diffère de ce que dig +trace montre maintenant, vous regardez une ancienne délégation en cache. Vous ne pouvez pas purger le monde ; planifiez des atténuations en conséquence.

Task 13: Inspect negative caching behavior (NXDOMAIN TTL via SOA)

cr0x@server:~$ dig @ns1.example.com example.com SOA +noall +answer
example.com.	3600	IN	SOA	ns1.example.com. hostmaster.example.com. 2026020401 7200 3600 1209600 300

Ce que cela signifie : Le dernier champ (ici 300) est le TTL de mise en cache négative (comportement RFC 2308).

Décision : Si vous planifiez une bascule où des enregistrements peuvent temporairement ne pas exister, baissez-le à l’avance. Si vous venez de corriger un NXDOMAIN, attendez-vous à ce que certains résolveurs conservent le « non » pendant cette durée.

Task 14: Confirm no accidental CNAME-at-apex or illegal combinations

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

cr0x@server:~$ dig @ns1.example.com example.com A +noall +answer
example.com.	300	IN	A	198.51.100.10

Ce que cela signifie : L’apex de zone ne doit pas être un CNAME dans le DNS classique. Si vous voyez un CNAME à l’apex et aussi NS/SOA, certains résolveurs se comporteront mal.

Décision : Corrigez la structure de la zone (utilisez ALIAS/ANAME au niveau fournisseur si nécessaire) et gardez des sorties conformes aux standards sur les serveurs autoritatifs.

Trois courtes histoires d’entreprise depuis les tranchées de la délégation

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

Une entreprise SaaS de taille moyenne a décidé de « professionnaliser le DNS » en migrant l’hébergement autoritatif vers un fournisseur managé.
Le runbook de migration était propre : copier la zone, réduire les TTL, changer les NS chez le registrar, surveiller.
En staging, ça a fonctionné. L’ingénieur qui a fait le changement n’a eu aucun souci. Et pour la plupart des utilisateurs, ça a marché.

Puis des escalades commerciales ont commencé : un groupe de clients enterprise ne pouvait pas se connecter depuis un réseau d’entreprise particulier.
Le domaine de connexion se résolvait vers l’ancienne IP pour eux. Pour tout le monde ailleurs, il se résolvait vers la nouvelle.
L’équipe a effectué la danse habituelle — redémarrages, rollback de déploiements, regarder des tableaux de bord qui n’avaient aucune idée de ce que faisait le DNS.

La mauvaise hypothèse : « Si le registrar affiche les nouveaux serveurs de noms, la délégation parente est mise à jour. »
En réalité, l’UI du registrar était en avance sur la publication du registre. Certains résolveurs récursifs avaient mis en cache l’ancien ensemble NS de délégation
avec un long TTL depuis le parent, et continuaient d’interroger l’ancien fournisseur autoritatif — qui servait désormais un ancien snapshot de la zone.

La correction n’a pas été héroïque. Ils ont temporairement restauré la zone chez l’ancien fournisseur pour qu’elle corresponde aux nouvelles réponses (donc chaque chemin de délégation fonctionnait),
puis ont attendu la fenêtre TTL du parent. Une fois stabilisé, ils ont retiré l’ancien autoritatif — cette fois après avoir vérifié
avec dig +trace et des contrôles multi-résolveurs, pas des captures d’écran.

Ce qui a changé culturellement : ils ont arrêté de traiter la « propagation » comme une force mystique et ont commencé à la voir comme un état de cache avec des TTL mesurables.
Ils ont aussi ajouté une exigence ferme : avant d’arrêter l’ancien DNS, confirmer que plusieurs résolveurs dans le monde reçoivent la nouvelle délégation du parent.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une grande entreprise gérait son propre DNS autoritatif sur une paire de load balancers régionaux. Le raisonnement était familier :
« On peut garder le trafic local, réduire la latence et garder le contrôle total. » Ils ont aussi activé DNSSEC, car une revue de sécurité approchait.

Dans une semaine calme, ils ont « optimisé » les règles de firewall : autoriser UDP/53 depuis partout, autoriser TCP/53 uniquement depuis des IP résolveurs connues.
L’idée était de réduire l’exposition. Ça a même passé les tests initiaux — la plupart des requêtes sont UDP.

Puis une rotation de clés a augmenté la taille des réponses DNS et déclenché plus de troncature et de fallback TCP. Soudain, une tranche de résolveurs a commencé à expirer.
Ils n’étaient pas sur la liste d’autorisation. Ils étaient des récursifs légitimes avec des IP de sortie changeantes (résolveurs cloud, forwarders d’entreprise,
et certains FAI avec de grandes flottes). Les utilisateurs ont vu des échecs intermittents sans corrélation évidente.

Le motif des symptômes était classique et adjacent à la délégation : certains résolveurs fonctionnaient, d’autres obtenaient SERVFAIL ou des timeouts, et un nouveau essai sur un NS différent
réussissait parfois. L’équipe a perdu des heures à blâmer le fournisseur DNS — sauf que le fournisseur DNS, c’était eux.

La correction finale était peu glamour : autoriser TCP/53 de façon large, le limiter intelligemment, et le surveiller.
Si vous publiez DNSSEC, vous ne pouvez pas prétendre que TCP est optionnel. Vous pouvez réduire le risque avec des contrôles sensés, mais vous ne pouvez pas nier la réalité protocolaire.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une autre entreprise gérait plusieurs marques et domaines, et avait vécu une panne de délégation douloureuse des années auparavant.
Après cela, ils ont mis en place une règle : chaque changement DNS est validé par un job automatisé de « santé de la délégation ».
Pas d’exception. Le job s’exécutait depuis plusieurs réseaux et vérifiait NS parent, glue, DS, cohérence autoritative et résolution basique.

Un jour, une demande de changement de routine est arrivée : « Déplacer ns2 vers une nouvelle IP ; l’ancien sous‑réseau est retiré. »
L’ingénieur a mis à jour l’A de ns2.example.com dans la zone autoritative et le nouveau serveur est monté.
Localement, tout semblait en ordre.

L’automatisation a bloqué la clôture du changement. Elle a signalé : « Le glue parent pour ns2.example.com pointe toujours vers l’ancienne IP. »
L’ingénieur a soupiré, s’est connecté au registrar et a mis à jour l’objet hôte. Le TTL du glue était long, ils ont donc laissé l’ancienne IP en service jusqu’à expiration.

Le résultat a été ennuyeux, ce qui est la meilleure chose qu’on puisse dire du DNS. Les clients n’ont rien remarqué. Le retrait du sous‑réseau a eu lieu comme prévu.
L’équipe n’a pas gagné de félicitations, mais elle n’a pas non plus généré de postmortem. C’est ça le deal.

Blague n°2 : le DNS est le seul endroit où « ennuyeux » est une fonctionnalité, et « excitant » est un événement qui peut ruiner une carrière.

Erreurs courantes : symptômes → cause racine → correction

1) Symptôme : fonctionne depuis certains réseaux, échoue depuis d’autres

Cause racine : Délégation scindée (NS parent différent de NS enfant), ou caches conservant une ancienne délégation avec de longs TTLs parentaux.

Correction : Utilisez dig +trace pour confirmer la délégation parente actuelle. Rendez identiques les ensembles NS parent et enfant. Gardez l’ancien autoritatif servant des données correctes jusqu’à expiration des TTLs parentaux.

2) Symptôme : timeouts intermittents, surtout sur DNSKEY/TXT

Cause racine : Problèmes de fragmentation UDP, soucis EDNS, ou TCP/53 bloqué. DNSSEC et gros TXT aggravent le problème.

Correction : Assurez l’atteignabilité de TCP/53. Tuner l’autoritatif pour EDNS. Réduire la taille des réponses quand possible (éviter TXT gonflés, choisir des algorithmes/paramètres DNSSEC sensés).

3) Symptôme : SERVFAIL sur résolveurs validants, mais requêtes autoritatives correctes

Cause racine : Mismatch DS DNSSEC, DNSKEY manquant, signatures expirées, ou chaîne NSEC/NSEC3 incorrecte.

Correction : Comparez le DS parent avec le DNSKEY enfant. Réparez le DS ou resignez la zone ; si nécessaire en urgence, retirez le DS au parent (coordonné) pour stopper les échecs de validation.

4) Symptôme : après changement de NS, le domaine est « mort » pendant des heures

Cause racine : TTL parent élevé ; les résolveurs ont mis en cache l’ancienne délégation. Ou le nouvel autoritatif n’est pas joignable globalement.

Correction : Planifiez les migrations : réduisez les TTLs à l’avance (là où c’est possible), gardez l’ancien autoritatif en service, validez l’atteignabilité depuis plusieurs réseaux, puis retirez.

5) Symptôme : clients IPv6 uniquement échouent, IPv4 fonctionne

Cause racine : AAAA glue cassé pour NS in-bailiwick, v6 injoignable sur l’autoritatif, ou routage dual-stack incohérent.

Correction : Vérifiez les enregistrements NS AAAA et l’atteignabilité v6. Si vous ne pouvez pas supporter v6 de façon fiable pour l’autoritatif, ne publiez pas AAAA pour les NS.

6) Symptôme : réponses différentes selon le NS interrogé

Cause racine : Secondaire obsolète, transfert de zone échoué, ou multi‑fournisseurs en split‑brain sans pipeline discipliné.

Correction : Faites respecter les contrôles de serial SOA. Réparez le pipeline de transferts. Retirez les NS malsains de la délégation jusqu’à cohérence.

7) Symptôme : certains résolveurs reçoivent NXDOMAIN même après création du record

Cause racine : TTL de mise en cache négative conservant le NXDOMAIN.

Correction : Attendre la fin du TTL négatif, ou si vous avez besoin d’une récupération plus rapide la prochaine fois, réduisez le SOA minimum/TTL négatif avant les changements planifiés.

8) Symptôme : la délégation semble correcte, mais les résolveurs continuent d’interroger d’anciens noms NS

Cause racine : Certains résolveurs ignorent les indices TTL ou les plafonnent ; d’autres font du caching agressif. De plus, les forwarders intermédiaires peuvent mettre en cache plus longtemps.

Correction : Traitez cela comme une convergence progressive. Maintenez la compatibilité, surveillez et communiquez des délais basés sur le comportement observé des résolveurs, pas sur des souhaits.

Checklists / plan étape par étape

Checklist de migration : changer de fournisseur DNS autoritatif sans se blesser

1. Inventaire de la délégation actuelle : capturez l’ensemble NS parent, le glue, le DS et les TTLs avec dig +trace et des requêtes directes au parent.
2. Réduisez les TTLs dans la zone enfant pour les enregistrements que vous prévoyez de changer (A/AAAA, CNAME) bien en amont. Ne prétendez pas que cela change les TTLs parentaux.
3. Préparez le nouveau fournisseur : importez la zone, vérifiez tous les enregistrements, vérifiez l’état DNSSEC (activé/désactivé) intentionnellement, pas par accident.
4. Test de requête directe : interrogez les nouveaux serveurs autoritatifs directement pour les noms critiques. Confirmez réponses, SOA et DNSSEC si activé.
5. Test d’atteignabilité : assurez-vous que UDP/53 et TCP/53 sont atteignables depuis Internet public. Confirmez v4/v6 si applicable.
6. Changez la délégation chez le registrar et vérifiez immédiatement avec dig +trace depuis plusieurs points de vue.
7. Fenêtre de service double : gardez l’ancien autoritatif servant les mêmes réponses jusqu’à convergence des TTLs parentaux et des caches observés.
8. Surveillez la résolution, pas seulement la disponibilité : surveillez depuis plusieurs régions et résolveurs ; alertez sur les pics NXDOMAIN/SERVFAIL.
9. Ce n’est qu’ensuite que vous retirez l’ancien autoritatif et supprimez les anciens NS de l’enfant et du parent.

Checklist d’urgence : « domaine partiellement down » suspecté de défaillance de délégation

1. Confirmez la portée du symptôme : quels réseaux/résolveurs échouent ? capturez des exemples avec IPs exactes des résolveurs.
2. Lancez un trace : confirmez ce que le parent délègue maintenant.
3. Vérifiez le glue : si NS in-bailiwick, confirmez que les adresses glue parentales sont correctes et atteignables.
4. Vérifiez la cohérence autoritative : serial SOA et enregistrements cibles sur tous les NS.
5. Vérifiez la chaîne DNSSEC : DS au parent vs DNSKEY à l’enfant ; validez avec au moins un résolveur validant connu.
6. Atténuez : si un NS est cassé, retirez‑le de la délégation parentale (et de l’ensemble NS enfant) ou réparez‑le vite ; évitez de laisser un NS mort en rotation.
7. Communiquez de façon réaliste : publiez ce que vous avez changé et la fenêtre de convergence attendue basée sur les TTLs et le comportement observé.
8. Post‑incident : ajoutez de l’automatisation pour prévenir la récurrence (vérifications de délégation, reachabilité NS, monitoring d’expiration DNSSEC).

Checklist d’hygiène opérationnelle : contrôles ennuyeux qui préviennent les pièges de délégation

• Gardez les ensembles NS parent et enfant identiques. La dérive n’est pas redondance ; c’est de la confusion.
• Maintenez au moins deux serveurs autoritatifs sur des réseaux/fournisseurs indépendants quand c’est possible.
• Surveillez depuis l’extérieur de votre réseau et en dehors de votre résolveur — les vues internes sont des mensonges réconfortants.
• Suivez les changements de glue comme des changements d’infrastructure, pas comme des « contenus DNS ».
• Pour DNSSEC : surveillez l’expiration des signatures, automatisez les rollovers prudemment, et traitez les mises à jour DS comme des changements de production avec rollback.
• Documentez le processus registrar (y compris qui a l’accès et combien de temps prennent les mises à jour).

FAQ

1) Qu’est‑ce exactement que la « délégation » en DNS ?

La délégation, c’est la zone parente qui dit aux résolveurs quels serveurs de noms sont autoritatifs pour votre domaine (enregistrements NS),
plus les IP glue quand nécessaire, et les enregistrements DS si DNSSEC est activé.

2) Si j’ai corrigé mon fichier de zone, pourquoi les utilisateurs voient-ils encore l’ancien comportement ?

Parce qu’ils n’atteignent peut‑être pas votre fichier de zone. Ils suivent peut‑être une ancienne délégation en cache, utilisent un glue obsolète,
ou sont coincés par la mise en cache négative. Corriger la zone enfant ne corrige pas automatiquement le chemin vers elle.

3) Quelle est la différence entre NS parent et NS enfant ?

Les enregistrements NS du parent vivent dans la zone parente (registry). Les enregistrements NS de l’enfant vivent dans votre zone sur les serveurs autoritatifs.
Ils doivent correspondre. Quand ils ne correspondent pas, vous obtenez une résolution incohérente selon le chemin pris par le résolveur.

4) Quand ai‑je besoin d’enregistrements glue ?

Quand le nom d’un serveur de noms est à l’intérieur du domaine qu’il sert (in-bailiwick), comme ns1.example.com pour example.com.
Le parent doit fournir des A/AAAA glue pour que les résolveurs puissent atteindre le NS sans déjà résoudre la zone.

5) Un glue erroné peut‑il tout casser même si les noms NS sont corrects ?

Oui. Les résolveurs peuvent avoir les bons noms NS mais être envoyés vers la mauvaise adresse IP. Vous verrez des timeouts ou une atteignabilité incohérente.
Le glue est un point de défaillance courant lors de renumérotations d’IP et de migrations de fournisseur.

6) Pourquoi DNSSEC provoque‑t‑il SERVFAIL au lieu d’une simple « mauvaise réponse » ?

Les résolveurs validants échouent en mode fermé : si la chaîne de confiance est rompue (DS ne correspond pas au DNSKEY, signatures expirées, etc.),
ils ne renvoient pas de données potentiellement falsifiées. Ils retournent SERVFAIL car ils ne peuvent pas valider.

7) La « propagation DNS » est‑elle réelle ?

Pas dans le sens que les gens veulent dire. Il n’y a pas de poussée globale. Il y a de la mise en cache avec des TTLs, plus des politiques de résolveur,
plus un chemin de lookup en plusieurs étapes. Internet converge vers votre changement ; il ne le reçoit pas instantanément.

8) Comment prouver rapidement s’il s’agit d’une délégation ou de mes serveurs autoritatifs ?

Utilisez dig +trace pour voir ce que le parent délègue, puis interrogez chaque autoritatif directement pour le nom en échec.
Si la trace pointe vers un NS/glue/DS erroné, c’est la délégation. Si les autoritatifs sont en désaccord, c’est votre distribution.

9) Devrais‑je faire fonctionner mon propre DNS autoritatif ?

Vous pouvez, mais faites‑le avec discipline de production : réseaux diversifiés, anycast bien réalisé (ou pas du tout), TCP/53 autorisé,
surveillance du cycle de vie DNSSEC, et monitoring externe réel. Si cela vous semble être du travail, c’en est.

10) Combien de serveurs de noms devrais‑je publier ?

Deux est le minimum ; trois ou quatre peuvent améliorer la résilience, mais seulement s’ils sont vraiment indépendants et mis à jour de façon cohérente.
Publier cinq NS médiocres est pire que publier deux excellents.

Conclusion : prochaines étapes pour éviter la répétition des incidents

Les défaillances de délégation font mal parce qu’elles vous font passer pour incompétent en public alors que vos systèmes sont silencieusement sains.
La solution est de traiter la délégation DNS comme une infrastructure de production avec sa propre observabilité, son contrôle de changement et son plan de rollback.
Pas du « set and forget ». Pas du « le registrar dit que c’est bon ».

Faites‑les dans cet ordre

1. Construisez un contrôle de santé de la délégation qui lance dig +trace, vérifie NS/glue/DS parentaux, et interroge chaque autoritatif pour SOA et enregistrements critiques.
2. Forcez la cohérence de l’ensemble NS entre parent et enfant. Faites d’une dérive un incident déclenchant une page.
3. Rendez TCP/53 incontournable si vous exécutez DNSSEC ou générez de grandes réponses. Surveillez les taux de succès UDP et TCP séparément.
4. Entraînez‑vous aux migrations avec une fenêtre de service double : gardez l’ancien autoritatif servant des données correctes jusqu’à convergence des caches.
5. Consignez qui contrôle le registrar et à quelle vitesse il peut mettre à jour glue/DS. Quand vous en aurez besoin, vous n’aurez pas le temps de chercher l’accès.

Le piège de la délégation est évitable. Mais seulement si vous arrêtez de penser au DNS comme à des « enregistrements » et commencez à le penser comme un chemin de recherche distribué
avec plusieurs autorités, caches et ancres de confiance. C’est le système que vous opérez réellement.