Migration DNS PYCON.FR

Pour un nom de domaine, l'outil interroge 19 résolveurs publics répartis dans neuf pays et affiche, pour chacun, les serveurs de noms (NS) renvoyés, le numéro de série du SOA et le TTL restant. Deux lignes identiques signifient deux points de vue identiques sur la zone ; une ligne différente signale une propagation en cours, un cache, ou une divergence entre serveurs.

Le SOA porte un compteur que le serveur primaire incrémente à chaque modification de la zone. Il sert aux serveurs secondaires : chacun compare son numéro au sien et transfère la zone s'il est en retard. Un numéro qui ne bouge pas signifie donc « rien à propager », même si le fichier de zone a changé. Le format courant est AAAAMMJJnn — pour aujourd'hui, le premier changement du jour donnerait 2026110601. Un serveur qui incrémente sans rien changer (SOA-EDIT automatique) est normal ; un serveur qui change la zone sans incrémenter ne la propagera jamais.

Le TTL (Time To Live) est la durée, en secondes, pendant laquelle un résolveur a le droit de garder la réponse en cache. Le chiffre affiché est le temps restant : il diminue à chaque seconde, voir 3600 puis 3540 n'est pas une erreur. Conséquence directe : après une modification, le pire cas est un TTL complet. 300 s rendent une bascule presque instantanée, 86400 s (24 h) la rendent longue.

Le résolveur n'a pas répondu dans le délai (2 à 3 s), a refusé la requête, ou filtre les adresses inconnues. Les grands résolveurs publics limitent les requêtes NS et SOA venues de datacenters, et certains ne répondent qu'à leurs propres clients. Ce n'est pas un diagnostic sur votre domaine : recoupez avec les autres lignes et avec un dig lancé depuis votre poste.

Chaque test lance plusieurs dizaines de requêtes vers des résolveurs tiers. La limite, appliquée par adresse IP, évite que l'outil ne devienne une source de charge — pour ces opérateurs comme pour ce serveur. Elle s'applique aussi au chargement des lignes, avec un budget plus large puisqu'un affichage en consomme dix-neuf.

Cinq étapes, dans cet ordre : 1. relever la zone actuelle, tous les noms (A, AAAA, MX, TXT, CNAME, sous-domaines) ; 2. 24 à 48 h à l'avance, baisser à 300 s le TTL des seuls noms qui vont changer ; 3. préparer le nouveau serveur — site, certificat, journaux — et le tester sans toucher au DNS : curl --resolve exemple.fr:443:203.0.113.10 https://exemple.fr/ ou une ligne dans le fichier hosts ; 4. changer l'enregistrement, puis vérifier sur les serveurs autoritatifs ; 5. après 24 à 48 h sans incident, remonter le TTL. L'étape 3 est celle qu'on saute : un certificat manquant ou une base non restaurée ne se découvrent pas après la bascule.

Oui, et c'est le seul réglage qui donne de la marge. Mais le baisser au moment de la bascule ne sert à rien : les résolveurs qui ont déjà la réponse gardent l'ancienne valeur jusqu'à son expiration. Il faut l'avoir fait au moins un TTL avant — 24 h pour un TTL de 86400, une heure pour 3600. Si on a oublié, il faut attendre : aucun changement d'enregistrement ne raccourcit un cache déjà distribué.

Les MX sont indépendants du site. Si le courrier reste chez le même fournisseur, n'y touchez pas. Pour le déplacer : relever tous les TXT (SPF de l'apex, sélecteurs DKIM *._domainkey, DMARC _dmarc), les recréer à l'identique chez le nouveau, envoyer des messages de test dans les deux sens, puis changer les MX. Un SPF ou un DKIM oublié ne se voit pas tout de suite : les messages partent, puis sont rejetés quelques jours plus tard.

Non. www, mail, ftp, blog, _dmarc, *._domainkey, et un éventuel joker : chaque nom est un enregistrement indépendant, à déplacer pour son propre compte. Un sous-domaine oublié donne la situation la plus déroutante — le site principal fonctionne, le service annexe est mort.

Non : un CNAME ne peut pas coexister avec les enregistrements SOA et NS de l'apex. Les hébergeurs proposent la même chose sous d'autres noms — ALIAS, ANAME, « CNAME flattening » — en résolvant la cible côté serveur pour publier une A ou une AAAA. C'est acceptable pour un site web, pas pour du courrier : les MX ne peuvent pas pointer vers un CNAME.

Six étapes : 1. créer la zone complète chez le nouveau fournisseur — tous les noms, pas seulement le site ; 2. vérifier que ses serveurs répondent pour chaque nom, avant la bascule : dig @ns1.nouveau exemple.fr A, puis MX et TXT ; 3. si DNSSEC est actif, retirer le DS chez le registraire et attendre son expiration ; 4. changer les serveurs de noms chez le registraire ; 5. contrôler les nouveaux serveurs, puis deux résolveurs publics ; 6. republier le DS de la nouvelle zone. La zone parente ne contient que les NS : tout le reste doit déjà exister ailleurs.

Le TTL des NS publiés dans la zone parente — souvent 3600 s, parfois 86400 chez certains registraires — plus la propagation. Pendant quelques heures, une partie des résolveurs interroge encore les anciens serveurs : ce n'est pas un échec, seulement un cache. C'est aussi pourquoi on garde les anciens en service pendant cette fenêtre.

Un DS publié qui ne correspond plus aux clés des nouveaux serveurs rend le domaine injoignable — SERVFAIL chez tous les résolveurs validants — alors qu'un dig en direct continue d'afficher la zone. L'ordre sûr : retirer le DS, attendre l'expiration (une heure à 24 h selon le TTL du DS), basculer, puis republier le DS de la nouvelle zone. Vérifier avec dig +dnssec sur chaque autoritatif : un secondaire peut servir la zone sans les signatures.

Oui si les serveurs de noms sont dans le domaine qu'ils servent : ns1.exemple.fr pour exemple.fr. Leurs adresses doivent être publiées dans la zone parente — ce sont les enregistrements glue —, sinon la résolution tourne en boucle. C'est le registraire qui les pose, en même temps que les NS : prévoyez-les avant de basculer.

Non. Le transfert déplace la gestion commerciale du domaine, pas la zone : les serveurs de noms restent les mêmes, sauf si vous les changez aussi. Il suppose un domaine déverrouillé, un code d'autorisation (authInfo / EPP) fourni par le registrar actuel, et l'accord du titulaire. Comptez environ cinq jours.

Oui : domaine verrouillé, code d'autorisation erroné ou expiré, adresse du titulaire non confirmée, litige en cours, ou délai de carence de 60 jours après une création ou un transfert récent — variable selon le TLD. Un transfert refusé ne fait perdre que du temps : la zone continue de répondre pendant ce temps.

Votre résolveur, celui de votre fournisseur d'accès ou votre navigateur garde l'ancienne réponse jusqu'à expiration du TTL ; le cache négatif (le minimum du SOA) joue de la même façon pour les noms qui n'existent pas. Un dig sur les serveurs autoritatifs montre la vérité immédiatement, un résolveur public peut se tromper une heure. Vider le cache local (ipconfig /flushdns, resolvectl flush-caches, dscacheutil -flushcache sous macOS) ne règle que le dernier maillon de la chaîne.

Dans l'ordre : les serveurs autoritatifs (dig @ns1 … puis @ns2 …), un ou deux résolveurs publics, puis le site lui-même avec curl --resolve — ce dernier test sépare un problème DNS d'un problème de serveur web. Cet outil donne les dix-neuf points de vue en un écran ; il ne remplace pas l'interrogation directe des autoritatifs.

Non. Gardez-le en service au moins un TTL — une semaine pour être tranquille —, en le faisant pointer vers le nouveau si possible. C'est la seule période pendant laquelle un retour arrière reste possible, et c'est aussi ce qui évite de servir une page d'erreur aux visiteurs dont le cache n'a pas encore expiré.