Changement de serveurs DNS non pris en compte ?

Vérifier qu’un changement de serveurs DNS est bien pris en compte

Trois étapes, toutes sur cette page. La vérification lit le DNS public en HTTPS depuis votre navigateur — elle ne touche jamais à votre compte chez le bureau d’enregistrement, et il n’y a rien à installer ni à créer.

1. Saisissez le domaine. Tapez le domaine, un nom d’hôte ou une URL et lancez la vérification. La page lit la fiche du registre en RDAP — celle de l’Afnic pour un .fr — et interroge en parallèle dns.google et cloudflare-dns pour NS, SOA, A, AAAA, MX et TXT : la réponse actuelle du registre à côté de deux caches indépendants.
2. Lisez d’abord la ligne de délégation. Elle a trois états. NOERROR avec des serveurs de noms : la délégation est intacte et vous attendez des caches. NXDOMAIN : la zone parente n’a aucune délégation pour vous, et attendre n’y changera rien. SERVFAIL : la délégation existe, mais les serveurs derrière elle ne servent pas la zone.
3. Comparez ensuite le registre et les résolveurs. Si le registre affiche déjà vos nouveaux serveurs et qu’un résolveur renvoie encore les anciens, ce résolveur garde une copie en cache — c’est la propagation, et elle se termine d’elle-même. Si le registre lui-même affiche encore l’ancienne liste, rien n’est en route : le changement n’est jamais arrivé au registre. Pour les extensions sans RDAP lisible par un navigateur (.de, .eu, .es, .it…), comparez plutôt les deux résolveurs.

Trois réponses, pas deux : NOERROR, NXDOMAIN, SERVFAIL

Presque tout ce qu’on lit sur le sujet ne connaît que deux cas : ça marche, ou « ça propage encore ». C’est pour cela qu’on attend trois jours quelque chose qui ne se serait jamais réparé seul. Une requête NS sur votre domaine a trois réponses, pas deux : NOERROR avec des enregistrements NS = la délégation est en place et vous attendez l’expiration des caches ; NXDOMAIN = la zone parente ne contient aucune délégation pour votre domaine ; SERVFAIL = la délégation existe mais aucun serveur faisant autorité n’a répondu.

Pour départager les deux premiers cas, l’outil lit aussi le SOA. Une zone saine répond avec le sien : la chaîne racine → extension → vos serveurs s’est résolue de bout en bout. Un domaine sans délégation répond NXDOMAIN avec le SOA de la zone parente dans la section authority : c’est le registre qui vous dit qu’il n’a rien pour vous. Dans un navigateur, les deux donnent la même page qui ne charge pas ; ce ne sont pas du tout les mêmes problèmes.

Ce que « propagation DNS » veut vraiment dire

Il n’y a pas de propagation : rien n’est copié de serveur en serveur. Dès que le registre publie la nouvelle délégation, les serveurs faisant autorité donnent la nouvelle réponse ; ce sont les résolveurs qui ont déjà posé la question qui gardent l’ancienne, jusqu’à l’expiration de son TTL. Le plafond n’est donc pas « 24 à 48 heures » : c’est le TTL des anciens enregistrements, plus le TTL NS de la zone parente — 48 heures pour un .com, une heure pour un .fr. L’outil affiche le TTL restant de chaque copie, c’est-à-dire le compte à rebours. Deux résolveurs qui divergent, c’est la propagation. Deux résolveurs d’accord sur une réponse que vous n’avez pas configurée, ce n’en est pas.

La ligne REGISTRE, en tête des résultats, tranche sans déduction. RDAP, le successeur de WHOIS, renvoie en HTTPS les serveurs que le registre détient maintenant, et la RFC 7480 recommande d’ouvrir ces données publiques aux navigateurs : si le registre affiche déjà vos nouveaux serveurs, vous attendez des caches ; s’il affiche encore les anciens, le changement n’est jamais arrivé. Pour un .fr, c’est l’Afnic qui répond — comme pour le .re, le .paris ou le .bzh. Le .de, le .eu, le .es et le .it n’offrent pas de RDAP lisible depuis un navigateur : la page le dit au lieu de deviner.

Le .fr en chiffres : ce que fait l’Afnic, et en combien de temps

Sur un .fr, la part du délai qui revient au registre se mesure, et elle est courte. Vérifié le 26 septembre 2026, dans les documents de l’Afnic et sur ses serveurs :

• La mise à jour est immédiate. Le guide des procédures de l’Afnic (édition de janvier 2024) lui donne une durée « immédiate ou <15 minutes » : Whois tout de suite, DNS « lors de la prochaine mise à jour de la zone DNS ». Tant qu’elle est en cours, aucune autre opération n’est possible sur le domaine.
• La zone fr. est republiée toutes les cinq minutes environ. L’Afnic écrivait « toutes les dix minutes » en 2021 ; relevé toutes les vingt à trente secondes, le numéro de série du SOA de fr. a changé vers 9 h 34, 9 h 39, 9 h 44, 9 h 49, 9 h 54, 10 h 00 et 10 h 05 UTC, chaque fois dans la même fenêtre de relevé sur d.nic.fr et g.ext.nic.fr.
• La délégation vit une heure dans les caches : TTL de 3600 secondes sur les NS servis par d.nic.fr, contre 172800 (48 heures) pour un .com.
• Le cache négatif dure dix minutes : les NXDOMAIN de fr. portent un SOA de TTL 600 et de minimum 600.
• La fiche se lit depuis un navigateur. L’IANA renvoie le .fr vers rdap.nic.fr, qui répond avec access-control-allow-origin: *, même sur un 404. L’outil y lit les serveurs, les statuts et le DS éventuel ; un .fr non signé n’a pas de bloc DNSSEC dans sa fiche, donc pas de ligne DNSSEC.

Bilan : quelques minutes de publication, puis, pour les caches qui tiennent la délégation publiée par fr., une heure au plus. Au-delà, ce sont les TTL de l’ancienne zone et des résolveurs : pour un changement d’hébergement, l’Afnic prévient que « plusieurs jours » peuvent être nécessaires, notamment à cause des caches DNS des fournisseurs d’accès, et parle d’une dizaine d’heures en moyenne pour ses domaines. Et si la fiche montre encore les anciens serveurs, le changement n’est pas arrivé à l’Afnic. Son guide liste les refus : transfert en cours, autre mise à jour en cours, période de rédemption, procédure Syreli ou PARL Expert, titulaire en « gel » ou en « blocage » — regardez les statuts affichés à côté.

On lit encore que l’Afnic rejette un changement de serveurs quand son « zonecheck » échoue. En 2006, elle présentait bien à l’ICANN un ZoneCheck lancé avant chaque délégation et à chaque changement de serveurs ; son guide des procédures de janvier 2024 et son guide d’intégration technique de décembre 2024 n’en parlent pas. Dans tous les cas, l’ordre sûr est le même : créez la zone chez le nouvel hébergeur, testez-la, puis changez la délégation. Zonemaster, que l’Afnic développe avec la fondation suédoise de l’Internet, sait tester un domaine « non délégué » — vos nouveaux serveurs avant la bascule.

OVHcloud, Gandi, IONOS, o2switch, LWS : où se change la délégation, et quel délai chacun annonce

Chaque hébergeur annonce son plafond, et aucun ne dit la même chose (documentations consultées le 26 septembre 2026) :

Ce sont des marges, pas des mesures : aucune ne vient du registre. Un cas ressemble à une panne sans en être une. Chez OVHcloud, si DNSSEC est actif, les serveurs ne changent qu’après la désactivation de DNSSEC — 24 heures, selon sa documentation. Pendant ce temps, la fiche de l’Afnic garde les anciens serveurs, et l’outil le montre en première ligne. Côté OVHcloud, d’après le guide d’o2switch, un changement en cours se lit ainsi : les anciens serveurs « En suppression », les nouveaux « En cours ». Si la fiche n’a pas bougé une fois ces délais passés, ouvrez un ticket.

« Serveurs DNS » (OVHcloud, o2switch, LWS) et « serveurs de noms » (Gandi, IONOS, Afnic) désignent la même chose : qui héberge la zone, et ce que le registre publie. La zone DNS, elle, contient vos enregistrements ; la modifier — même en y ajoutant des NS — ne déplace pas la délégation. OVHcloud comme LWS gèrent la zone et les serveurs DNS à deux endroits différents de l’espace client, et un utilisateur du forum d’OVHcloud le résume : on passe par « Serveurs DNS », pas par « Zone DNS ».

Cache négatif : pourquoi un domaine réparé répond encore NXDOMAIN

Une fois la délégation réparée, NXDOMAIN peut continuer à revenir pendant toute la durée du TTL de cache négatif — le minimum du SOA. La RFC 2308 fixe ce souvenir au plus petit du champ minimum du SOA et du TTL du SOA lui-même : 600 secondes en fr., 900 en com., une journée à la racine. L’outil affiche cette fenêtre dès qu’il voit un NXDOMAIN.

Nous l’avons vécu. En juin 2026, quatre de nos domaines en .app ont perdu leur délégation au registre et répondu NXDOMAIN partout pendant environ quatre jours. Le bureau d’enregistrement l’a rétablie le 30 juin à 17 h 30 UTC, et pour la plus grande partie d’internet les domaines ne sont pas revenus ce soir-là : les résolveurs étaient encore dans leur fenêtre de cache négatif. Pendant tout ce temps, la zone Cloudflare restait active et le champ du bureau d’enregistrement verified ; seul le DNS public, lu depuis deux résolveurs, disait vrai. C’est pourquoi le contrôle de santé en quatre couches (en anglais) commence par le registre. Sur un .fr : réparez, laissez passer la prochaine publication de fr. puis dix minutes, et seulement ensuite concluez — sans « réparer » une deuxième fois entre-temps. Pour une autre zone, le calculateur de TTL DNS fait le calcul.

Ce qui casse vraiment après un changement de serveurs DNS

1. Le changement est resté chez le bureau d’enregistrement. Le panneau dit « enregistré », l’internet public renvoie l’ancienne liste ; chez OVHcloud, l’avancement se lit dans « Opérations en cours ». Symptôme : la ligne REGISTRE montre les anciens serveurs — pour un .fr, c’est la fiche de l’Afnic elle-même.
2. La zone n’existe pas sur les nouveaux serveurs. Symptôme : SERVFAIL sur les deux résolveurs. Créez la zone d’abord ; OVHcloud demande de vérifier qu’un serveur « est joignable et contient bien une zone DNS pour votre nom de domaine » avant de le déclarer.
3. DNSSEC est resté actif. Le DS de l’ancien fournisseur est toujours dans la zone parente, et les résolveurs qui valident rejettent le nouveau. Symptôme : SERVFAIL partout, « DS publié » dans la fiche. Retirez le DS, attendez son TTL, puis réactivez DNSSEC chez le nouveau fournisseur.
4. Les enregistrements n’ont pas été recopiés. Le contenu de l’ancienne zone « n’est pas automatiquement répliqué dans la nouvelle », rappelle OVHcloud. Symptôme : délégation au vert, aucun A ni AAAA — la cause la plus fréquente d’un site tombé après un changement « réussi ».
5. MX, SPF, DKIM et DMARC oubliés. La messagerie casse plus tard et en silence : regardez les lignes MX et TXT. Une boîte d’agent (en anglais) sur le domaine s’éteint au même moment.
6. Un ancien TTL long. Rien n’est cassé ; le TTL restant de chaque réponse est le compte à rebours.
7. Domaine suspendu, bloqué ou expiré. Symptôme : NXDOMAIN avec le SOA de la zone parente, et dans la fiche client hold (retrait demandé par le bureau d’enregistrement, par exemple après un litige commercial), server hold (pour un .fr, l’état « Blocked » de l’Afnic, par exemple après une vérification des coordonnées du titulaire qui n’a pas abouti) ou redemption period. Attendre ne fait rien.
8. Un verrou a fait refuser la mise à jour. client update prohibited et server update prohibited font rejeter toute modification. En .fr, on les trouve sous .FR Lock, le verrouillage de registre de l’Afnic (avec server transfer, delete et recover prohibited), et pendant un « gel », où le domaine fonctionne mais ne se modifie plus. Un verrou client se lève chez le bureau d’enregistrement ; sous .FR Lock, la modification se fait à la demande du titulaire, sous le contrôle de l’Afnic.
9. Les serveurs ont été saisis dans la zone, pas dans « Serveurs DNS ». Des NS ajoutés dans la zone ne changent pas la délégation. Symptôme : la fiche garde les anciens serveurs ; avec le deuxième champ rempli, l’outil vous le dit en toutes lettres.

Les mêmes vérifications depuis un terminal

La page n’est qu’un raccourci : chaque ligne se reproduit avec dig et curl, et l’outil affiche les commandes exactes pour votre domaine. Pour un .fr :

curl -s https://rdap.nic.fr/domain/votre-domaine.fr    # la fiche de l’Afnic : serveurs, statuts, DS
      dig +norecurse NS votre-domaine.fr @d.nic.fr         # la délégation publiée par fr. (TTL 3600)
      dig @8.8.8.8 NS votre-domaine.fr +short              # un cache…
      dig @1.1.1.1 NS votre-domaine.fr +short              # …et un autre : réponses différentes = propagation
      dig SOA votre-domaine.fr                             # sur un NXDOMAIN, nomme la zone qui refuse
      dig +norecurse SOA votre-domaine.fr @ns1.nouvel-hebergeur.fr   # avant la bascule : drapeau aa attendu
      curl -s -H 'accept: application/dns-json' 'https://dns.google/resolve?name=votre-domaine.fr&type=NS'

L’avant-dernière ligne est celle qu’on oublie : un serveur qui détient bien votre zone répond avec le drapeau aa ; sinon, basculer maintenant produira un SERVFAIL. dig +trace NS votre-domaine.fr montre quel maillon lâche, de la racine à vos serveurs. La dernière est exactement la requête de cette page : dans son JSON, Status est le RCODE (0 NOERROR, 2 SERVFAIL, 3 NXDOMAIN) et, sur un refus, Authority contient le SOA de la zone qui l’a émis.

Ce qu’un navigateur ne voit pas — et ce qu’ajoute la vérification complète

Un navigateur lit trois choses : ce que détient le registre (quand son RDAP est ouvert, comme pour le .fr), si la délégation se résout, et ce que répond la zone. Il ne voit ni votre compte chez le bureau d’enregistrement ni sa file d’attente, ni rien au-dessus du DNS — un proxy, un certificat pas encore émis, une liaison d’hébergement jamais créée, une origine qui renvoie 502. Tout cela ressemble à « le site est tombé après le changement de serveurs DNS », et rien de cela n’est du DNS.

clize domain check <domaine> reprend cette première couche — la même sonde DoH, dns.google d’abord, cloudflare-dns en secours, le RCODE lu en trois états — et y ajoute la zone Cloudflare, la liaison du nom d’hôte au worker du site et le contenu réellement servi : quatre couches, une commande, et un voyant vert qui veut dire joignable, pas seulement délégué. Sans argument, il passe en revue tous les domaines du compte ; la plateforme le relance toutes les 30 minutes et n’alerte qu’après deux échecs consécutifs. C’est le correctif né de la panne de juin, avec la vérification de la délégation après chaque déploiement. Pour la suite : Agent Domains, l’enregistrement de domaines par programme et la référence des commandes (en anglais) ; déployer le site est une autre commande, et une autre couche.

$ npm i -g @clize/clize && clize install
$ clize domain check votre-domaine.fr