Document généré automatiquement depuis /home/jerome/pub/docs/04-dns-bascule.md sur kimsufi3, le 11 September 2026 à 14:03. Toute modification faite ici sera écrasée à la prochaine régénération : éditer le fichier source.
Relevé du 10 septembre 2026, directement auprès des serveurs faisant autorité.
Le paysage réel : deux hébergeurs, pas un
| Domaine | DNS | TTL actuel | TTL minimum | Scriptable ? |
|---|---|---|---|---|
| chabod.eu | LWS (ns1.lws-hosting.biz) |
voir ci-dessous | 900 s (15 min) | non — panel uniquement |
| kopains.fr | OVH (ns105.ovh.net) |
600 s | 60 s | oui, API OVH |
| bunzenthal.lu | OVH (ns16.ovh.net) |
3600 s | 60 s | oui, API OVH |
| chabod.lu | OVH (dns10.ovh.net) |
60 s | 60 s | oui, API OVH |
La contrainte des 15 minutes ne concerne donc que chabod.eu. Les trois autres domaines sont déjà chez OVH, où la bascule peut être scriptée.
✅ Fait le 10/09/2026 — TTL abaissés à 300 s
Abaissés par import d’un fichier de zone dans le panel LWS, ce qui a permis de descendre à 300 s alors que l’interface annonce 900 s comme minimum.
L’interface LWS affiche encore 24 h : elle se trompe. Seule compte la réponse des serveurs faisant autorité, vérifiable par
dig +noall +answer kimsufi4.chabod.eu A @ns1.lws-hosting.biz.
| Enregistrement | Avant | Après | Vérifié |
|---|---|---|---|
kimsufi4.chabod.eu |
86 400 s | 300 s | ns1, ns2, et les résolveurs publics |
mail.chabod.eu |
21 600 s | 300 s | idem |
chabod.eu |
7 200 s | 300 s | idem |
kopains.fr (OVH) |
600 s | 600 s | suffisant |
chabod.lu (OVH) |
60 s | 60 s | suffisant |
bunzenthal.lu (OVH) |
3 600 s | 600 s | fait le 10/09 |
Google (8.8.8.8), Cloudflare (1.1.1.1) et Quad9 (9.9.9.9) renvoient tous 300 s, en 30 à 40 ms. La propagation est effective ; les caches encore porteurs de l’ancien TTL de 24 h se seront alignés au plus tard le 11/09/2026.
Anomalie relevée : deux serveurs de noms sur quatre refusent la zone
ns3.lwsdns.com (91.216.107.20) et ns4.lwsdns.com (91.107.253.2) répondent REFUSED pour chabod.eu, alors qu’ils sont déclarés dans la zone. Seuls ns1 et ns2 la servent. C’est l’anomalie déjà notée dans traefik-migration/README.md.
Impact pratique faible : les résolveurs apprennent vite quels serveurs répondent et privilégient ns1/ns2 — d’où les 40 ms mesurées. Mais la zone n’a en réalité que deux serveurs au lieu de quatre, donc moins de redondance qu’annoncé. À signaler à LWS sans urgence.
Urgent : le TTL de kimsufi4.chabod.eu était à 24 heures
| Enregistrement | TTL actuel | Couvre |
|---|---|---|
kimsufi4.chabod.eu |
86 400 s — 24 h | cloud, music, note, films, git, ha, autoconfig |
mail.chabod.eu |
21 600 s — 6 h | — |
chabod.eu |
7 200 s — 2 h | — |
kopains.fr |
600 s — 10 min | www.kopains.fr |
bunzenthal.lu |
3 600 s — 1 h | www.bunzenthal.lu |
chabod.lu |
60 s — 1 min | felix, tim |
Une bascule faite aujourd’hui mettrait jusqu’à 24 heures à être visible partout, pas 30 minutes. L’enregistrement pivot est le pire des six.
Le piège : abaisser un TTL ne prend effet qu’après son expiration
Un résolveur qui a déjà kimsufi4.chabod.eu en cache le garde 24 h, quelle que soit la nouvelle valeur publiée entre-temps. Il faut donc abaisser les TTL au moins 24 h avant toute bascule, test compris.
Fait le 10/09/2026. C’était le geste le plus rentable du projet.
Plafond de propagation : 10 minutes
Les six enregistrements sont abaissés. Le TTL le plus long est celui de kopains.fr et bunzenthal.lu (600 s) : c’est le plafond de propagation d’une bascule. Les noms les plus critiques — mail, cloud, ha, git, note, music, films, tous dépendants du pivot kimsufi4.chabod.eu — sont à 5 minutes.
Un délai de grâce reste à respecter. L’ancien TTL de
kimsufi4.chabod.euétait de 24 h : les résolveurs qui l’avaient encore en cache au moment du changement le conservent jusqu’à 24 h. Tous les caches seront alignés au plus tard le 11/09/2026. Aucune bascule, test compris, avant cette date.
Pas besoin de toucher aux CNAME
Point subtil, qui évite du travail inutile. Les CNAME ont des TTL très variés (note 813 s, music et films 21 600 s, cloud et ha ~7 100 s), mais ils n’entrent pas en jeu dans la bascule : ils continueront de pointer vers kimsufi4.chabod.eu, ce qui reste correct.
Un résolveur ayant en cache cloud.chabod.eu CNAME kimsufi4.chabod.eu refera de toute façon la requête A sur kimsufi4.chabod.eu dès que ce TTL expire, et obtiendra la nouvelle adresse. Seuls les 6 enregistrements A comptent.
RTO réaliste avec un TTL de 300 s
| Étape | Durée |
|---|---|
| Décision et lancement | 2 min |
| Restauration des dumps + démarrage des stacks sur k3 (Atom) | 10-15 min |
| Modification des 6 enregistrements | 3 min |
| Propagation DNS | jusqu’à 5 min |
| Total | ~20-25 min |
L’objectif de 30 minutes est dépassé. Le facteur dominant n’est plus le DNS mais le démarrage des conteneurs sur l’Atom — c’est désormais là qu’il faut chercher du temps si l’on veut descendre plus bas.
Le mail est le cas le plus favorable
Un serveur distant qui ne joint pas mail.chabod.eu réessaie pendant plusieurs jours — c’est le fonctionnement normal de SMTP. Un courrier retardé de 15 min n’est pas perdu, et il n’y a pas de rejet définitif sur un simple délai. Le RTO du mail est donc bien moins critique que celui du web.
Option devenue peu utile : rapatrier chabod.eu chez OVH
Tes trois autres domaines y sont déjà. OVH offre un TTL minimum de 60 s et une API DNS qui rendrait la bascule scriptable de bout en bout — ce que tu souhaitais au départ et que LWS ne permet pas.
Gain désormais marginal sur le RTO, puisque LWS sert déjà du 300 s. Il resterait l’automatisation (plus de manipulation manuelle) et la correction de l’anomalie ns3/ns4.
Coût : le transfert d’une zone qui porte du courrier (MX, SPF, DKIM, DMARC, autoconfig, autodiscover) est une opération délicate, à mener à part et au calme. Ce n’est pas un prérequis du projet, mais c’est le seul levier qui fasse réellement descendre le RTO.
Le MX secondaire LWS — tranché le 10/09/2026
chabod.eu a un MX 50 91.216.107.237 = mail18.lwspanel.com. La question restait ouverte depuis le début du projet ; la reponse est oui, LWS reprend le courrier quand k4 est injoignable.
Conséquence majeure : aucun courrier n’est perdu pendant une panne. Le seul point que INVENTAIRE-CRITICITE.md mesure en minutes — la réception du courrier — est donc déjà couvert par un tiers, indépendamment de ce projet.
La nuance qui reste à vérifier
« Repris dans le webmail LWS » n’est pas « spoolé puis relayé » :
| Comportement | Conséquence |
|---|---|
| spool + relais | livré à mail.chabod.eu au retour, tout arrive dans SOGo, transparent |
| livraison dans un webmail LWS | boîte séparée, jamais livrée à mailcow |
Si c’est le second cas — ce que la formulation suggère — alors après une panne le courrier vit à deux endroits qui ne se réconcilient pas. Rien n’est perdu, mais il faut aller le chercher, et il n’apparaîtra jamais dans l’IMAP.
À vérifier une fois, au calme : couper mailcow quelques minutes, s’envoyer un message, et regarder où il atterrit — et s’il finit par arriver dans SOGo.
Ce que cela change pour le projet
- Le RPO du courrier est sauvé par LWS : la bascule d’urgence n’a plus à courir après les minutes pour éviter une perte.
- Le RTO reste pertinent : les messages ne sont pas dans la boîte habituelle de l’utilisateur, et l’émission depuis
chabod.eureste indisponible. - La bascule planifiée (dist-upgrade) n’est pas concernée : elle vise le RPO 0 et un arrêt propre, pas le rattrapage d’une panne.
Autrement dit : le mode urgence devient moins urgent, le mode planifié reste la raison d’être du dispositif.
Leave a Reply