Erreurs de TTL DNS qui hantent les migrations — Comment définir le TTL comme un pro

TTL n’est pas « propagation » : ce qui se passe réellement

Le TTL (time to live) est le nombre de secondes pendant lesquelles une réponse DNS est autorisée à rester en cache. Ce n’est pas le temps qu’il faut pour que « l’internet » prenne connaissance de votre changement. L’expression « propagation DNS » est du marketing pour ceux qui vendent des noms de domaine et des aspirines.

Voici le flux réel en production :

• DNS autoritatif héberge la vérité pour une zone (vos enregistrements, votre SOA, votre jeu de NS).
• Résolveurs récursifs (résolveurs des FAI, résolveurs d’entreprise, résolveurs publics) récupèrent et mettent en cache les réponses des serveurs autoritatifs.
• Résolveurs stub sur les machines interrogent un résolveur récursif. Ils peuvent aussi mettre en cache, selon le système d’exploitation, les bibliothèques et les démons locaux.
• Mise en cache au niveau applicatif existe aussi. Java, Go, Envoy, navigateurs, CDN en périphérie et des SDK mystères mettent parfois en cache le DNS d’une manière que vous n’avez pas demandée.

Quand vous modifiez un enregistrement au niveau autoritatif, rien ne pousse ce changement vers l’extérieur. Le monde apprend la nouvelle réponse uniquement quand les caches expirent et que les résolveurs demandent à nouveau. Le TTL est la feuille d’autorisation qui indique aux caches à quel point ils peuvent être paresseux.

Une chose de plus : le TTL est par jeu d’enregistrements dans la réponse. Cela inclut les réponses négatives (NXDOMAIN), qui sont aussi mises en cache. Les gens oublient cela, puis se demandent pourquoi un nouvel hôte « n’existe pas » pendant une heure.

Blague n°1 : « La propagation DNS » est comme « on reviendra vers vous » dans les e-mails d’entreprise : ça veut dire « pas selon votre calendrier ».

Faits intéressants et courte histoire (à utiliser en réunion)

1. Le DNS a remplacé HOSTS.TXT parce qu’un fichier centralisé ne pouvait pas monter en charge. Le TTL existe parce que la mise en cache est la seule façon pour un système de nommage global de survivre.
2. Le TTL est présent dans le DNS depuis les premiers RFC comme mécanisme central de contrôle du comportement de cache. Ce n’est pas un simple réglage optionnel ; c’est un contrat.
3. La mise en cache négative a été standardisée plus tard, après que les opérateurs aient réalisé que demander sans cesse « ce nom existe-t-il ? » surchargeait les résolveurs lors des incidents et attaques.
4. L’enregistrement SOA a deux concepts de « minimum » historiquement : des sémantiques anciennes vs l’utilisation moderne pour le TTL de mise en cache négative. La confusion ici provoque encore des douleurs lors des migrations.
5. Les résolveurs sont autorisés à plafonner les TTL (minimum et maximum) pour des raisons de politique ou de performance. Votre TTL à 30 secondes peut devenir 300 secondes sur certains réseaux.
6. Certaines plateformes ignorent le TTL en pratique parce qu’elles verrouillent les réponses DNS ou les mettent en cache agressivement. Ce n’est pas que le DNS soit cassé ; c’est le comportement des applications.
7. Les CDN et les répartiteurs de charge globaux s’appuient souvent sur le DNS précisément parce que le TTL permet un déplacement de trafic « eventual » contrôlé. Bien utilisé, c’est fiable et prévisible.
8. Les TTL bas étaient historiquement déconseillés quand les serveurs autoritatifs étaient plus faibles et la bande passante coûteuse. Aujourd’hui c’est moins une question de coût que de discipline opérationnelle.
9. EDNS et les fonctions modernes des résolveurs ont amélioré la performance et la robustesse, mais n’ont pas éliminé la mise en cache. La mise en cache reste le point central.

Un modèle mental du TTL qui tient dans les réseaux réels

Si vous ne retenez qu’un seul modèle, utilisez celui-ci :

Temps observé pour la bascule = max(couches de cache) + vos propres erreurs.

Couche 1 : mise en cache du résolveur récursif

C’est la grosse. Vos utilisateurs n’interrogent pas vos serveurs autoritatifs directement ; ils interrogent un résolveur. Ce résolveur obéit typiquement au TTL, mais peut le plafonner. Si le résolveur a mis en cache l’ancienne réponse il y a cinq minutes avec un TTL d’une heure, vous pouvez changer l’enregistrement autant que vous voulez — ces utilisateurs resteront collés à l’ancienne réponse pendant jusqu’à 55 minutes supplémentaires.

Couche 2 : résolveur stub et cache au niveau hôte

Sur Linux vous pouvez avoir systemd-resolved, nscd, dnsmasq, ou rien. Sur macOS il y a le comportement de mDNSResponder. Sur Windows il y a un service Client DNS. Certains honorent le TTL, d’autres ont une logique additionnelle, et certaines applications les contournent.

Couche 3 : mise en cache applicative et runtime

Les navigateurs peuvent mettre en cache le DNS, mais votre pile client HTTP aussi. La JVM avait historiquement des valeurs par défaut « mettre en cache pour toujours » dans certains modes. Certains maillages de services ou sidecars mettent en cache de façon agressive pour la performance. Et certaines équipes ont leur propre bibliothèque de cache DNS parce qu’elles ont été alertées pour la latence des résolveurs. Devinez quoi : maintenant vous recevez des alertes pendant les migrations.

Couche 4 : réutilisation de connexion et sessions longue durée

Même si le DNS se met à jour instantanément, le trafic peut ne pas bouger parce que les clients gardent des connexions TCP existantes ouvertes. HTTP/2, gRPC, WebSockets, pools de bases de données — tout cela est conçu pour être collant. Le DNS n’affecte que les nouvelles connexions (sauf si vous forcez le drainage/fermeture). Pendant une migration, la durée des connexions peut compter plus que le TTL.

Pourquoi « définir le TTL à 60 secondes » ne signifie pas automatiquement « bascule en 60 secondes »

Parce que l’enregistrement peut déjà être en cache avec un TTL plus élevé, parce qu’il existe une mise en cache négative, parce que les résolveurs plafonnent, parce que les caches applicatifs existent, et parce que les connexions sont réutilisées.

Le TTL n’est pas un chronomètre. C’est un âge maximum à partir du moment de la mise en cache. Si vous avez besoin de prévisibilité, planifiez à rebours : baissez le TTL bien en avance pour que les caches se rafraîchissent avec le nouveau petit TTL avant la fenêtre de bascule.

Une citation à garder pour les conversations sur la fiabilité :

« L’espoir n’est pas une stratégie. » — idée paraphrasée attribuée à de nombreux ingénieurs fiabilité et responsables SRE

Comment définir le TTL comme un pro (pré-bascule, bascule, post-bascule)

Étape 0 : décidez ce que « bascule » signifie dans votre système

La bascule DNS n’est qu’un levier. Avant de toucher aux TTL, décidez :

• Déplacez-vous tout le trafic ou seulement un sous-ensemble ?
• Avez-vous besoin d’un retour arrière rapide (minutes) ou des heures sont acceptables ?
• Les clients sont-ils internes (résolveurs d’entreprise que vous contrôlez) ou externes (le zoo du chaos) ?
• Les services sont-ils stateful (bases de données) ou stateless (web/API) ?
• Avez-vous un second plan de contrôle (pondérations de load balancer, config CDN, discovery) qui pourrait être mieux que le DNS ?

Le DNS est excellent pour les mouvements de trafic grossiers et le basculement quand vous pouvez tolérer des fenêtres de cache. C’est un mauvais outil pour un routage seconde-par-seconde. Si vous le traitez comme un répartiteur de charge, il vous rappellera qui commande.

Pré-bascule : baisser les TTL tôt, pas « juste avant »

La démarche pro consiste à baisser les TTL au moins une période complète de l’ancien TTL avant la bascule. Idéalement deux. Parce que le monde peut avoir mis en cache l’enregistrement à n’importe quel moment pendant la fenêtre de l’ancien TTL.

Exemple : votre TTL actuel est 3600 secondes (1 heure). Vous voulez une fenêtre de bascule de 60 secondes. Baissez le TTL à 60 au moins 1 heure avant la bascule — et de préférence plus tôt. Cela donne aux caches le temps de se rafraîchir et de commencer à respecter le nouveau petit TTL.

Choisissez des valeurs de TTL sensées (et ne jouez pas les malins)

Voici un point de départ volontariste qui fonctionne pour la plupart des migrations :

• Opérations normales (état stable) : 300–900 secondes pour la plupart des enregistrements A/AAAA ; 900–3600 pour les enregistrements qui changent rarement.
• Fenêtre de migration : 30–120 secondes pour les noms spécifiques que vous basculerez.
• Post-bascule : remontez à 300–900 une fois stable ; ne laissez pas tout à 30 secondes indéfiniment sauf si vous avez budgété la charge de requêtes et audité les résolveurs.

Oui, des TTL à 30 secondes sont possibles. Non, ce n’est pas gratuit. Vous payez en charge sur les résolveurs, en QPS autoritatif, et en complexité opérationnelle si votre fournisseur DNS a une mauvaise journée.

Bascule : changez le bon enregistrement au bon endroit

La plupart des migrations échouent parce que quelqu’un a changé un enregistrement, pas le bon enregistrement.

• Si vous avez une chaîne (CNAME vers un autre CNAME vers A/AAAA), vous devez comprendre le TTL à chaque saut.
• Si vous avez du DNS à horizon partagé (split-horizon), vous devez changer les vues interne et externe intentionnellement.
• Si vous utilisez du DNS managé plus une zone de remplacement interne, sachez qui gagne pour quels clients.

De plus : si vous utilisez un enregistrement apex (example.com) et faites des astuces ressemblant à des CNAME, soyez extrêmement prudent. Le comportement spécifique du fournisseur peut changer les TTL réellement apparents dans les réponses.

Planification du rollback : le TTL est le bouton d’ampleur

Le timing du rollback est aussi contrôlé par les caches. Si vous basculez et que c’est mauvais, revenir en arrière n’est pas « instantané », même si vous êtes rapide. Si vous voulez un rollback rapide, il fallait des TTL bas avant la bascule, et il faut considérer la réutilisation des connexions. Sinon, le rollback n’est qu’une seconde migration, elle aussi soumise à la mise en cache.

Post-bascule : remontez les TTL, puis surveillez les retardataires

Après stabilisation, augmentez les TTL pour réduire la charge de requêtes et l’agitation opérationnelle. Mais ne vous précipitez pas. Gardez des TTL bas assez longtemps pour permettre un rollback pendant que le nouvel environnement se stabilise.

Et surveillez les clients retardataires. Il y en a toujours quelques-uns : appareils embarqués, vieilles JVM, proxys d’entreprise, et bibliothèques « utiles » qui verrouillent le DNS.

Blague n°2 : Mettre des TTL à 5 secondes donne l’impression de puissance jusqu’à ce que la facture DNS arrive comme un bilan de performance.

Tâches pratiques : 12+ vérifications et décisions pilotées par commandes

Voici les tâches que j’exécute réellement pendant une migration. Chacune a : commande, ce que signifie la sortie, et la décision à prendre.

Task 1: Verify what the world sees (authoritative answer via +trace)

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

; <<>> DiG 9.18.24 <<>> +trace www.example.com A
;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms

www.example.com.      60      IN      A       203.0.113.42
;; Received 56 bytes from 198.51.100.53#53(ns1.example.net) in 22 ms

Meaning: The final answer shows TTL=60 at the authoritative source (as observed through trace). That’s the “truth” being served now.

Decision: If TTL here is not what you expect, stop. Fix the authoritative zone first. Don’t debug clients yet.

Task 2: Check the recursive resolver you actually use

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

www.example.com.      47      IN      A       203.0.113.42

Meaning: Cloudflare’s resolver has cached the record and will keep it for 47 more seconds.

Decision: If the TTL remaining is huge, your earlier TTL-lowering didn’t “take” in time, or the resolver clamped it. Adjust expectations and rollback strategy.

Task 3: Compare multiple resolvers to detect clamping or stale caches

cr0x@server:~$ for r in 1.1.1.1 8.8.8.8 9.9.9.9; do dig @$r www.example.com A +noall +answer +ttlid; done

www.example.com.      52      IN      A       203.0.113.42
www.example.com.      300     IN      A       203.0.113.42
www.example.com.      58      IN      A       203.0.113.42

Meaning: One resolver is effectively using 300 seconds. That could be a clamp, or it cached before TTL was lowered.

Decision: If external user experience matters, plan for the worst observed caching. Your “60-second” cutover is not globally 60 seconds.

Task 4: Inspect CNAME chains and TTL at each hop

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

www.example.com.      60      IN      CNAME   app-lb.example.net.

cr0x@server:~$ dig app-lb.example.net A +noall +answer +ttlid

app-lb.example.net.   300     IN      A       198.51.100.77

Meaning: Even if the CNAME TTL is 60, the A record it points to may have TTL 300 and be cached independently.

Decision: During migrations, lower TTLs consistently across the chain, or change the record at the right level (often the CNAME target).

Task 5: Confirm AAAA behavior (IPv6 can surprise you)

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

www.example.com.      60      IN      AAAA    2001:db8:10::42

Meaning: Clients preferring IPv6 will use this path. If you only updated A, half your traffic may ignore you.

Decision: Treat A and AAAA as a pair. Migrate both, or intentionally disable one (with full awareness of impact).

Task 6: Check negative caching (NXDOMAIN) before creating new names

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

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

Meaning: No answer section; the authority section shows SOA with a minimum/negative caching TTL behavior (commonly 300 here).

Decision: If you’re about to create a brand-new name during cutover, check and tune negative caching in advance. Otherwise “it doesn’t exist” can persist.

Task 7: Verify authoritative NS set and delegation correctness

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

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

Meaning: These are the authoritative servers clients should reach (after delegation).

Decision: If you’re migrating DNS providers, mismatched NS sets or partial delegation will create “some users see old, some new” chaos for days.

Task 8: Check SOA serial and whether secondaries picked up changes

cr0x@server:~$ dig @ns1.example.net example.com SOA +noall +answer
example.com.          900     IN      SOA     ns1.example.net. hostmaster.example.com. 2025123102 3600 600 1209600 300

cr0x@server:~$ dig @ns2.example.net example.com SOA +noall +answer
example.com.          900     IN      SOA     ns1.example.net. hostmaster.example.com. 2025123101 3600 600 1209600 300

Meaning: ns2 is behind (serial differs). Your “change” isn’t globally served yet.

Decision: Fix zone transfer/propagation between authoritative servers before cutover. Otherwise resolvers will get different answers depending on which NS they hit.

Task 9: Observe TTL from a specific client host (system resolver path)

cr0x@server:~$ resolvectl query www.example.com

www.example.com: 203.0.113.42                    -- link: eth0
                 (A) --> 47s

Meaning: systemd-resolved shows remaining TTL in its cache for that host.

Decision: If the host cache is sticky or wrong, you may need to flush local caches for critical systems (or restart a service) as part of cutover.

Task 10: Identify which resolver a host is using (you’d be amazed)

cr0x@server:~$ cat /etc/resolv.conf
nameserver 10.0.0.53
search corp.example
options timeout:1 attempts:2

Meaning: This host uses a corporate resolver, not public DNS. Your external tests might be irrelevant.

Decision: Run cutover validation against the resolvers your clients actually use. If you don’t know them, you don’t have a plan.

Task 11: Confirm the resolver’s cache status (BIND example)

cr0x@server:~$ sudo rndc dumpdb -cache
cr0x@server:~$ sudo grep -n "www.example.com" /var/cache/bind/named_dump.db | head
12451:www.example.com. 47 IN A 203.0.113.42

Meaning: The local recursive resolver has the record cached with 47 seconds remaining.

Decision: If the resolver cache is stale during cutover and you control it, consider flushing the specific name (not the entire cache unless you enjoy self-inflicted outages).

Task 12: Measure whether users are stuck on old IPs via logs

cr0x@server:~$ sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
  912 203.0.113.10
  301 198.51.100.77
  118 203.0.113.11

Meaning: Requests are arriving at multiple frontends/IPs. If 198.51.100.77 is the “old” endpoint, some clients haven’t moved.

Decision: Keep the old endpoint healthy until the tail dies down, or actively drain/redirect. Don’t turn it off “because DNS.”

Task 13: Validate that the new endpoint answers correctly (don’t trust DNS yet)

cr0x@server:~$ curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" --resolve www.example.com:443:203.0.113.42 https://www.example.com/healthz
200 203.0.113.42

Meaning: You forced the connection to the new IP while keeping the hostname for TLS/SNI. Health is good.

Decision: If this fails, do not cut DNS. Fix the new endpoint first. DNS is not a test tool; it’s a steering wheel.

Task 14: Check for long-lived connections that ignore DNS changes

cr0x@server:~$ ss -antp | grep ':443' | head
ESTAB 0 0 203.0.113.42:443 198.51.100.25:52144 users:(("nginx",pid=2210,fd=44))
ESTAB 0 0 203.0.113.42:443 198.51.100.25:52145 users:(("nginx",pid=2210,fd=45))

Meaning: Active sessions exist. If you change DNS, existing clients may keep talking to the old endpoint until these connections close.

Decision: Plan draining and connection lifetime controls (keepalive timeouts, graceful shutdown) alongside TTL changes.

Task 15: Confirm DNSSEC status if you’re changing providers

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

www.example.com.      60      IN      A       203.0.113.42

Meaning: If you see the AD flag in some resolver contexts, validation succeeded. If validation fails after changes, clients may treat answers as bogus.

Decision: During provider migrations, manage DS records and signing carefully. DNSSEC failures look like random outages with “but DNS looks fine for me” sprinkled on top.

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

Quand le trafic ne bouge pas et que la fenêtre de migration fond, vous avez besoin d’un ordre de triage qui fonctionne.

Premier : la vérité autoritative est-elle correcte ?

• Exécutez dig +trace pour le nom exact et le type (A, AAAA, CNAME).
• Vérifiez le TTL, les cibles, et que la réponse correspond à la destination prévue.
• Vérifiez le serial SOA sur tous les serveurs autoritatifs si vous en avez plusieurs.

Si l’autoritatif est incorrect, arrêtez. Corrigez la zone. Tout le reste n’est que bruit.

Deuxième : les résolveurs retournent-ils des réponses obsolètes ?

• Interrogez les résolveurs que vos clients utilisent (résolveurs d’entreprise, résolveurs publics, résolveurs régionaux).
• Comparez le TTL restant et les IP retournées.
• Recherchez des plafonnements (TTL étonnamment élevé) ou un comportement split (certains résolveurs anciens, d’autres nouveaux).

Si les résolveurs sont obsolètes, vous attendez les caches à moins que vous ne contrôliez les résolveurs et puissiez les vider sélectivement.

Troisième : le trafic est-il bloqué pour des raisons non liées au DNS ?

• Vérifiez si les clients gardent des connexions existantes vers les anciens endpoints.
• Vérifiez le comportement de cache DNS côté client dans les runtimes applicatifs (JVM, sidecars, proxys).
• Vérifiez les LB/checks de santé : peut-être que le DNS a basculé mais le nouveau backend est malsain et la logique de bascule renvoie en arrière.

Si le DNS est correct mais le trafic ne bouge toujours pas, vous traitez la durée de vie des connexions, le cache applicatif, ou le routage en amont — pas le TTL DNS.

Trois mini-récits d’entreprise (anonymisés, douloureusement plausibles)

1) L’incident causé par une fausse hypothèse

Ils migraient un portail client d’un colo vers un load balancer cloud. Le plan disait : « Baisser le TTL à 60 secondes la veille, puis basculer l’enregistrement A à minuit. » Propre et civilisé.

L’ingénieur de garde a baissé le TTL — sur le mauvais enregistrement. Il y avait une jolie chaîne CNAME : portal.example.com CNAME vers portal.edge.example.net, et celui-ci avait l’enregistrement A pointant vers l’ancien VIP. Ils ont baissé le TTL sur portal.example.com, mais laissé portal.edge.example.net à 3600.

À minuit ils ont modifié l’A cible, mais les caches autour du monde détenaient encore l’ancien A pendant jusqu’à une heure. Certains clients atteignaient le nouveau portail, d’autres l’ancien, et les sessions sautaient selon le résolveur obtenu. Le support l’a vu comme des « déconnexions aléatoires ». L’ingénierie l’a vu comme « impossible à reproduire ». Tout le monde avait tort au même moment.

Le postmortem ne disait pas « le DNS est instable ». Le DNS a fait exactement ce qu’on lui avait demandé. L’échec venait de l’hypothèse que le nom visible contrôlait le comportement de cache. Les chaînes CNAME sont de petites machines à remonter le TTL. Si vous ne les cartographiez pas, elles vous cartographieront.

2) L’optimisation qui s’est retournée contre eux

Une autre entreprise gérait une API à fort trafic et a jugé que la latence DNS coûtait trop cher. Ils ont introduit un cache DNS en processus dans leur bibliothèque cliente avec un TTL minimum de 10 minutes. L’objectif : réduire le QPS vers les résolveurs et améliorer le p99.

Ça a marché. Les graphes de résolveurs ont baissé. La latence s’est un peu améliorée. Tout le monde l’a oublié parce que le tableau de bord était vert et personne n’aime lire les RFC en bonne période.

Puis est venue une migration régionale. Ils avaient prévu un basculement progressif via une configuration pondérée derrière un CNAME. Sur le papier, un TTL à 60 secondes leur donnait un contrôle rapide. En réalité, de gros clients exécutant la librairie cliente gardaient les anciennes réponses pendant 10 minutes d’affilée, et la bascule s’est comportée comme une marche obstinée.

Pire : le rollback n’était pas réel. Quand une partie des requêtes a commencé à échouer dans la nouvelle région, ils ont « rollbacké » le DNS, mais le cache a continué d’envoyer du trafic vers la région cassée pendant des minutes. Les ingénieurs ont commencé à douter de leurs propres outils. L’entreprise a commencé à douter de l’ingénierie. C’est ainsi que l’on brûle de la crédibilité, pas seulement de la disponibilité.

La solution n’était pas « ne jamais mettre en cache le DNS ». La solution était de respecter le TTL et de rendre le comportement de cache observable et configurable. Les optimisations de performance qui outrepent les contrats reviennent toujours vous hanter pendant les migrations.

3) La pratique ennuyeuse mais correcte qui a sauvé la situation

Une équipe d’entreprise avait un rituel. Avant toute migration majeure, ils faisaient un exercice de préparation DNS 48 heures avant. Pas une réunion — un exercice. Ils vérifiaient les TTL actuels, les abaissaient via un changement contrôlé, puis validaient depuis plusieurs points de vue (résolveurs d’entreprise, résolveurs publics et quelques régions cloud).

Ils avaient aussi une politique : pas de « nouveau nom » créé pendant la fenêtre de migration. Si un nouvel hôte était nécessaire, il était créé une semaine avant, interrogé régulièrement, et surveillé spécifiquement pour éliminer la mise en cache négative et les comportements résolveur bizarres.

La nuit de la migration, ils ont quand même eu un accroc : un secondaire autoritatif ne remontait pas les mises à jour correctement à cause d’une règle de pare-feu qui avait été « temporairement » modifiée lors d’un autre projet. L’exercice l’avait détecté deux jours plus tôt. Ils l’ont réparé pendant les heures ouvrées avec du temps devant eux.

La bascule s’est déroulée sans incident. Pas parce qu’ils étaient des génies. Parce qu’ils avaient rendu le DNS ennuyeux volontairement. Les meilleures migrations ressemblent à rien ; c’est exactement l’objectif.

Erreurs courantes : symptôme → cause racine → correctif

1) « Nous avons changé le DNS mais certains utilisateurs atteignent encore l’ancien site pendant des heures »

Symptôme : Trafic mixte vers les anciens et nouveaux endpoints longtemps après la bascule.

Cause racine : L’ancien TTL était élevé et vous l’avez baissé trop tard ; ou des résolveurs ont mis en cache avant le changement de TTL ; ou un résolveur a plafonné le TTL à la hausse.

Correctif : Baissez le TTL au moins une période complète de l’ancien TTL avant la bascule (idéalement deux). Validez le TTL sur plusieurs résolveurs. Prévoyez de garder l’ancien endpoint en vie pour la queue.

2) « Les utilisateurs internes voient le nouveau, les externes voient l’ancien »

Symptôme : Les employés signalent le succès ; les clients signalent des échecs (ou vice versa).

Cause racine : DNS à horizon partagé, zones de remplacement internes, ou résolveurs différents avec des états de cache différents.

Correctif : Documentez quels résolveurs et quelles zones servent quels clients. Testez la bascule depuis l’intérieur et l’extérieur. Mettez à jour les deux vues intentionnellement.

3) « Le nom dit NXDOMAIN, puis plus tard ça marche »

Symptôme : Les noms nouvellement créés semblent cassés de manière intermittente.

Cause racine : Mise en cache négative de NXDOMAIN due au TTL négatif du SOA ; ou le nom a été interrogé avant d’exister et a été mis en cache comme « n’existe pas ».

Correctif : Pré-créez les noms bien avant la fenêtre ; gardez le TTL négatif raisonnable ; vérifiez les paramètres SOA ; évitez d’introduire de nouveaux noms pendant la bascule.

4) « Nous avons baissé le TTL mais les clients ne le respectent toujours pas »

Symptôme : Certains clients restent sur une IP bien au-delà du TTL.

Cause racine : Mise en cache applicative/runtime (paramètres JVM, caches personnalisés, sidecars), ou connexions longue durée.

Correctif : Auditez le comportement DNS des clients. Configurez les caches pour qu’ils respectent le TTL. Définissez des durées maximales de connexion, drenez les connexions, et planifiez la persistance des sessions séparément du DNS.

5) « Nous avons changé l’enregistrement A mais rien n’a changé »

Symptôme : La supervision et les utilisateurs continuent d’aller vers l’ancien endpoint.

Cause racine : Vous avez changé le mauvais nom/type (chaîne CNAME, enregistrement différent en cours d’utilisation), ou il y a un override interne.

Correctif : Cartographiez le chemin de résolution (dig CNAME + trace). Confirmez le nom et le type interrogés par les clients. Supprimez ou mettez à jour les overrides.

6) « Après migration de fournisseur DNS, certains utilisateurs ne peuvent plus résoudre »

Symptôme : SERVFAIL ou timeouts pour un sous-ensemble de résolveurs.

Cause racine : Mismatch de délégation, enregistrements manquants, zone partielle, ou mismatch DS/signature DNSSEC.

Correctif : Validez la délégation NS, l’exhaustivité autoritative, et la chaîne DNSSEC avant la coupure NS. Gardez l’ancien fournisseur en service pendant la période de chevauchement si possible.

7) « Le rollback n’a pas rollé back »

Symptôme : Vous revenez en arrière DNS mais le trafic continue d’atteindre la nouvelle cible cassée.

Cause racine : Les caches détiennent maintenant la nouvelle réponse ; les connexions longue durée persistent ; certains clients verrouillent le DNS.

Correctif : Traitez le rollback comme un mouvement planifié avec sa propre fenêtre de cache. Gardez le TTL bas avant la bascule et gérez le drainage/les timeouts des connexions.

Checklists / plan étape par étape

Planifiez à rebours depuis la fenêtre de bascule

1. Inventoriez les noms impliqués (exposés aux clients, internes, API, callbacks, endpoints de webhook, SAN des certificats).
2. Cartographiez la résolution : A/AAAA vs chaîne CNAME, vues split-horizon, overrides internes.
3. Enregistrez les TTL actuels pour chaque enregistrement de la chaîne. C’est votre « ancien TTL » que vous devez sur-attendre.
4. Décidez du TTL de migration (généralement 30–120 secondes) et des exigences de rollback.
5. Baissez les TTL au moins une période de l’ancien TTL avant la bascule (deux si vous voulez dormir).
6. Vérifiez sur plusieurs résolveurs que le petit TTL est bien ce qu’ils mettent en cache.
7. Validez les nouveaux endpoints en forçant la résolution (curl --resolve) et en exécutant des checks de santé.
8. Effectuez la bascule DNS à l’heure prévue. Notez le changement exact, l’heure et le serial.
9. Surveillez la queue : le trafic vers l’ancien endpoint devrait décroître sur quelques fenêtres TTL ; surveillez le taux d’erreur et les motifs régionaux.
10. Gardez le rollback viable tant que vous êtes dans la période des « inconnus inconnus ».
11. Remontez les TTL vers l’état stable une fois la période de rollback passée.
12. Postmortem du processus : ce qui vous a surpris (plafonnement, caches applicatifs, overrides internes), et intégrez-le dans le runbook suivant.

Checklist opérationnelle pour la nuit de bascule (ce que vous ferez réellement)

• Confirmez la réponse autoritative avec dig +trace juste avant le changement.
• Interrogez les résolveurs d’entreprise et publics et enregistrez le TTL restant.
• Vérifiez que les réponses A et AAAA (ou IPv6 désactivé volontairement) correspondent au plan.
• Testez le nouveau endpoint en forçant la résolution avec curl --resolve pour TLS et santé.
• Confirmez l’observabilité : logs, métriques et alerting pour les anciens et nouveaux endpoints.
• Effectuez le changement DNS ; incrémentez le serial SOA si pertinent.
• Re-vérifiez les réponses autoritatives et des résolveurs immédiatement après.
• Surveillez les erreurs clients et le trafic vers l’ancien endpoint. Ne mettez pas hors service l’ancien endpoint trop tôt.
• Si un rollback est nécessaire, exécutez-le vite, mais attendez-vous à une queue de cache — communiquez cette réalité.

Checklist politique (règles ennuyeuses qui évitent les outages « créatifs »)

• N’introduisez pas de nouveaux hostnames pendant une fenêtre de bascule.
• Ne définissez pas des TTL extrêmement bas globalement ; concentrez-les sur les enregistrements critiques pour la migration.
• Ne comptez pas sur le comportement d’un seul résolveur pour valider.
• Ne supposez pas que « TTL=60 » équivaut à « les utilisateurs bougent en 60 secondes ».
• Documentez d’où proviennent les réponses DNS (fournisseur autoritatif, vues internes, overrides).
• Auditez la mise en cache DNS et la réutilisation des connexions des applications avant les migrations.

FAQ (les questions que vous aurez cinq minutes avant la bascule)

1) Quel TTL devrions-nous utiliser pour une migration ?

Pour les noms spécifiques que vous allez inverser : 30–120 secondes pendant la fenêtre. Mais seulement après avoir baissé le TTL suffisamment tôt pour que les caches se rafraîchissent.

2) Combien de temps avant devrions-nous baisser le TTL ?

Au moins une période complète de l’ancien TTL avant la bascule ; deux si vous voulez plus de cohérence. Si l’ancien TTL est 86400, baissez-le des jours à l’avance, pas « ce soir ».

3) Pourquoi la « propagation DNS » prend-elle plus de temps que le TTL ?

Parce que l’enregistrement peut avoir été mis en cache plus tôt sous un ancien TTL, certains résolveurs plafonnent le TTL, et certaines applications mettent en cache indépendamment. Le TTL est l’âge maximum du cache à partir du moment où il a été mis en cache.

4) Devons-nous définir le TTL à 0 ?

Ne le faites pas. Beaucoup de systèmes traitent 0 de manière surprenante, et vous allez faire exploser la charge de requêtes DNS. Si vous avez besoin d’un basculement quasi-instantané, utilisez un load balancer ou un mécanisme de discovery conçu pour cela.

5) Un CNAME est-il plus sûr qu’un enregistrement A pour les migrations ?

Les CNAME sont utiles pour l’indirection, mais ils ajoutent une couche de cache. Si vous utilisez des CNAME, gérez les TTL sur toute la chaîne ou vous aurez des bascules incohérentes.

6) Peut-on « vider le cache DNS d’internet » ?

Non. Vous pouvez vider les caches que vous contrôlez (vos résolveurs, vos hôtes, vos applis), mais pas ceux des autres. Planifiez la queue et gardez l’ancien endpoint actif.

7) Pourquoi certains utilisateurs continuent-ils d’atteindre l’ancien endpoint même après l’expiration des caches ?

Connexions longue durée. Les clients peuvent réutiliser des connexions TCP pendant des minutes ou des heures. Les changements DNS n’affectent que les nouvelles connexions à moins que vous ne drainiez/fermiez les connexions.

8) Comment valider le nouveau endpoint sans changer le DNS ?

Utilisez la résolution forcée (pour HTTPS, conservez le hostname pour SNI) : curl --resolve. Ou éditez le fichier hosts d’un client contrôlé pour les tests, mais ne confondez pas ça avec le comportement réel du monde.

9) Qu’en est-il de DNSSEC pendant les migrations ?

DNSSEC fonctionne tant que vous ne changez pas les clés de signature ou de fournisseur. Un mismatch DS peut provoquer des SERVFAIL généralisés. Traitez les changements DNSSEC comme une migration distincte et soigneusement planifiée.

10) Après la bascule, quand remonte-t-on les TTL ?

Après avoir observé la stabilité et que la fenêtre de rollback est close. Couramment : gardez des TTL bas pendant quelques heures à un jour selon le risque, puis remontez à 300–900 secondes.

Conclusion : prochaines étapes pratiques

Si le TTL DNS hante vos migrations, ce n’est généralement pas parce que le DNS est capricieux. C’est parce qu’on a traité le TTL comme un réglage de dernière minute plutôt que comme un calendrier.

Faites ce qui suit :

1. Choisissez un hostname critique dans votre environnement et cartographiez sa chaîne de résolution complète (y compris AAAA).
2. Consignez les TTL actuels et décidez de votre cible de TTL pour la migration (30–120 secondes pour les noms de bascule).
3. Faites un exercice : baissez le TTL tôt, confirmez via dig +trace et plusieurs résolveurs, et mesurez la vitesse réelle de déplacement du trafic.
4. Auditez la mise en cache DNS applicative et les durées de connexion. Corrigez les cas où le DNS est « verrouillé pour toujours » avant qu’ils ne vous verrouillent à 3h du matin.
5. Écrivez le mode opératoire de diagnostic rapide dans votre runbook d’astreinte, et faites-le exécuter une fois avant la vraie nuit.

Définissez le TTL comme un pro et le DNS deviendra une partie prévisible de votre migration, pas une histoire de fantômes que vous racontez aux nouvelles recrues.